Home / Blogs

DNSSEC - Failure to Launch

DNSSEC is a mechanism where clients can verify the authenticity of the answers they receive from servers. There are two sides here. The server must supply signed answers, and the client must verify the signatures on those answers. The validation/verification side is widely implemented, but there are very few signed zones.

2012-01-10 – Comcast announces that over 17 million customers are using their dnssec validating resolvers.

2013-05-06 – Google announces that they have enabled validation by default on their public resolvers - 130 billion queries per day from 70 million unique client ip addresses.

However, if no one signs their zones, those validating resolvers don’t have many signatures to check. The full details are at http://www.five-ten-sg.com/mapper/blog/dnssec, but the view on this front is beyond dismal.

Alexa.com has a list of the top 25 global web sites and not a single one of those domains is signed. The Federal Financial Institutions Examination Council has a list of large US financial institutions holding over $10 billion in assets. There are 104 domains on that list and exactly one is signed. The Federal Procurement Data System has a list of the top US defense contractors. There are 103 domains on that list and not a single one is signed. Ddosattackprotection.org has a list of computer security blogs and resources. There are 126 domains on that list and only 5 are signed. ICANN has a list of accredited registrars. There are 1289 unique domains on that list and only 16 are signed.

Is this a chicken-and-egg situation, where everyone is waiting for some event before they will consider signing their zones? I don’t think so, since the recursive validators are already in place. So, what can be done to improve the situation?

Regarding the financial institutions, apparently the 2009 cache-poisoning attack on a Brazilian bank was not enough for them to start securing their DNS answers. In 2011 an employee of a Brazilian ISP was arrested for “changing” the DNS cache to redirect customers to phishing websites. Pressure from government financial regulators could cause the banks to start signing their zones, but I doubt that the financial regulators themselves have any understanding of this topic.

Regarding the defense contractors, it is possible that US DoD might start requiring contractor company zones to be signed; at least the parts that DoD employees might need to access.

Regarding the computer security sites, I have no idea what it would take to get them to sign their zones. Publicity might work.

Regarding the accredited registrars, ICANN has many requirements (at least on paper) for registrars. They could add a DNSSEC requirement when those registrar agreements come up for renewal.

Filed Under

Comments

Two reasons I've been reluctant to deploy:- Frank Bulk  –  Jun 23, 2015 3:49 PM

Two reasons I’ve been reluctant to deploy:
- afraid to break a zone due mistakes I will make to rolling keys
- trouble of working with registrar for each of those zones

Challenges with registrars Dan York  –  Jun 24, 2015 1:06 AM

Frank, You do list two of the common concerns I hear about DNSSEC. The good news is that we're increasingly seeing better tools that help, for instance, automate the rolling of keys and thereby minimizing some of the mistakes. And some of the DNS hosting operators have improved the user experience. For instance, with two of my domains I just basically had to check a box in a web user interface and the hosting provider takes care of it. However, you do need to consider in your operational practices that you do need to roll keys on some interval and factor that into your planning. On your second issue about registrars, this unfortunately does remain a problem. An increasingly number of registrars are supporting DNSSEC, but a good number still do not. I had to go through the annoyance of moving several domains away from a registrar that just wouldn't provide a way for me to enter in the DS record I had from my hosting operator. Hopefully the registrar situation will improve over time as: 1) more customers request the support; and 2) competitive pressures start to kick in as more registrars do support it.

A plug for python and gkg.net Carl Byington  –  Jun 24, 2015 4:52 AM

I moved all of my (and my direct customers) domains to gkg.net. They have an easily scriptable web interface. My python code that handles all the key generation and signing operations automatically uploads new DS records when required. The easy way to get started is to buy a random testing domain from gkg.net, and start signing it. When you are convinced your automation is working properly, you can start signing real production domains.

2013 Registrar Accreditation Agreement (RAA) Christof Meerwald  –  Jun 23, 2015 5:19 PM

I thought ICANN already requires DNSSEC support in the 2013 Registrar Accreditation Agreement…

But I guess the way around for registrars is to just charge and arm and a leg for DNSSEC.

2013 RAA only requires registrars to accept DS records Dan York  –  Jun 24, 2015 12:59 AM

The 2013 RAA only requires registrars to "accept DNSSEC records" from customers, and specifically to accept a DS record from a customer. Keep in mind that what we often think about as "DNSSEC support" is really two distinct and separate functions: 1. a "registrar" function of accepting a DS record and passing it up to the parent domain (typically a TLD) to create the global chain of trust; and 2. a "DNS hosting" function that for DNSSEC involves generating the keys, signing the zones, etc. Now, MANY "registrars" offer BOTH services. They will register your domain and accept the DS records and pass them up to the parent domain - AND they will host your DNS records for you and do all the DNSSEC-signing. But... they could be completely separate. You could register your domain with one registrar and host your DNS records with a different company. The 2013 RAA only requires registrars to perform this registrar function of accepting DS records and passing them up to the parent domain. The RAA does NOT require the DNS hosting side of a registrar to do DNSSEC-signing.

But the registrars are not signing their own zones Carl Byington  –  Jun 24, 2015 4:45 AM

For their customers, they might support both functions 1 and 2 outlined above. However, it would be nice if they also signed their own domains. For example, consider the gkg.net registrar, where you can purchase domains in many of the tlds. dig gkg.net ds They are one of the few that have signed their own domain.

Tools matter John Levine  –  Jun 24, 2015 3:24 AM

I’ve been waiting for years for my registrar Tucows to provide tools to handle signed zones. (Mailing DS records one at a time as support tickets doesn’t count.) They finally did a couple of weeks ago and now I’ve signed most of my domains using the ldns tools and scripts that automatically upload the DS records.

Most people who run Internet services don’t understand them very well, so people will only sign when the tools are point and click. In many ways we’re close to that now, but close isn’t good enough.

DNSSEC deployment IS happening... just unevenly... Dan York  –  Jun 24, 2015 11:38 AM

Carl,

To the points you raise, you are quite correct that DNSSEC validation IS happening. Beyond the examples you list, if you look at APNIC’s statistics on DNSSEC validation you can see that about 14% of all DNS queries globally are being validated:

http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0

If you scroll down that page you’ll see that the percentage of DNS queries being validated is actually significantly higher in many countries.

On the signing side, you are correct that the lists you cite do not have many signed domains, but there is a good bit of signing happening in other areas. If you go to this statistics site from Rick Lamb:

https://rick.eng.br/dnssecstat/

and click on the “Signed/Total” heading twice you will get a list of top-level domains sorted by the most signed (NOTE: This site only shows information from sites that provide stats in a way the site can get them. For instance, 88% of .GOV domains are signed with DNSSEC, but you have to view NIST’s statistics site to find that info. Similarly, over 50% of Norway’s .NO domains are signed with DNSSEC, but they don’t yet report their stats in a way this stats site can obtain them.)

A couple of notes from Rick’s site:

  • Over 2.4 million .NL domains are signed (44%)
  • 778,000 .BR domains are signed (21%)
  • 62% of .CZ domains are signed

But, on the opposite side, only 0.43% of .COM domains are signed.

So the good news is that DNSSEC signing is happening… just unevenly across the domain space.

This whole area of accelerating deployment is an area of discussion within the DNSSEC community and will in fact be a topic at the DNSSEC Workshop happening tomorrow at ICANN 53 in ICANN (and anyone is welcome to watch that Workshop live).

As John Levine mentioned in another comment, a key step is to automate the tools a bit more to make it simpler for registrants to enable DNSSEC.

different measures Carl Byington  –  Jun 24, 2015 6:43 PM

APNIC's statistics on DNSSEC are interesting, but it is unclear to me exactly what they are measuring. One is the percentage of queries that are arriving from validating resolvers such as Google. Geoff Huston published measurements in 2013 from some experiments. Those involved getting a wide selection of clients to make queries to names in zones that he controlled. That measures the extent of the validation infrastructure deployment. Another is the percentage of signed vs unsigned zones in some upper level like .com or .nl. But this measurement may be biased by including a large number of signed zones for vanity domains, where there are essentially no queries. This could also be biased by some large domain registrar that automatically signs all their zones. I don't know if any of them do this, but it would be possible for a registrar to generate signatures for all the domains where the customer has not changed the registrar default NS records. In that case, the registrar is responsible for the NS records. They might just take on the responsibility for the DS records as well, possibly in response to a checked-by-default checkbox associated with an increased fee. This could be sold to the customer as a security upgrade for their domain name. Another is the percentage of queries (from any source) for names in a signed zone. One could measure that by analyzing all the incoming queries to some large recursive resolvers such as Google or Comcast. I think this is the measurement of interest to see the extent of the DNSSEC signing deployment.

Your stats read out at the ICANN 53 DNSSEC measurements... Dan York  –  Jun 24, 2015 1:32 PM

Carl,

You might be pleased to know that your stats about Alexa domains, financial sites, security blogs, ICANN registrars, etc. were just read out by one of the panelists at the ICANN 53 DNSSEC Workshop.  :-)

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign

DNS

Sponsored byDNIB.com

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API