DNSSEC Has Failed (Update 26/3)

The original specification of DNSSEC is from 1997: RFC 2065. This means that it is now over 17 years ago since its initial appearance. Sure, it has a turbulent history, and has undergone some big changes. Even the ‘final’ specification (RFC 4033) is over 9 years old. Yet I am going to argue that it has failed.

 This article received way more attention than I would have expected or even hoped for. I have been made aware that the situation regarding DNS resolvers is currently better than I documented, for which I am sorry. If you install BIND or Unbound now it will come with DNSSEC validation enabled by default. The point still stands that better documentation is needed, but the ISOC and others are already working on this. See also ICANN49s DNSSEC session held just days after my post. </Update>

Secure Shell is just a little older than DNSSEC, according to Wikipedia it is from 1995. It provides an important secure mechanism for remote shells, without which we would not be able to manage the Internet as it is today. Almost no one bothers to find out how it works, most users just trust it and know how to apt-get install ssh, to generate a key, and how to install that key on a remote server. This is all comes in a neat package when you install this.

Another security mechanism in widespread use is HTTPS. This has been available since around 1994, and has gotten a refresh with TLS in 2000. Like SSH many web masters don’t really care how this work, they just know to get certificates from Certificate Authorities, put some lines into their configuration files and it works. Since last year HTTPS has gotten much more attention and many services are turning it on by default. Users have some clue about what it is, and have been told to look for the “lock”, and warnings about misconfigured certificates are getting harder to ignore as well. Again the necessary software comes with your web server and is included in users web browsers also.

Now let’s examine the situation for DNSSEC. Most DNS server software these days supports DNSSEC. Most resolving software supports DNSSEC, but none almost all (update) have enabled it by default (even though it is should be completely transparent to users). To enable DNSSEC we have a “tutorial” by Olaf Kolkman which spans a whopping sixty-nine pages. DNS engineers can get trainings, which always take multiple days.

Furthermore, there are almost no simple instructions for enabling DNSSEC, especially none that use KSKs and ZSKs, and include instructions on how to do key rollovers. The ‘easiest’ solution that I’ve heard of is to use OpenDNSSEC which is a separate daemon with a complete database backend to handle your keys and do automatic key rollovers. This is of course complete overkill for most people who just manage a few domains.

Another option is to completely switch your DNS server software to use PowerDNS. By default this already uses a database backend to manage your domains, and integrates the above solution already in the whole chain. Note that it is possible to use the BIND-mode and then you use regular zone files, and a SQLite database backend for the keys.

Still, after all these years that DNSSEC has been around it is still way too hard for common DNS engineers to configure DNSSEC properly. There are way too many details and caveats that they have to know about, and there are no easy scripts to do this, and if there are, they are certainly not included in the regular packages.

A very important and often underestimated part of security is the ease with which common engineers and users can configure and use the secure variant. For SSH we had this from the beginning. For HTTPS it took somewhat longer and we are still educating users, but we are getting there. For DNSSEC it seems that the designers have completely overlooked this part, and are now paying the price for this, adoption of DNSSEC is minimal, even after all these years. This has to change before DNSSEC can become a success.

15 comments on “DNSSEC Has Failed (Update 26/3)

  1. “I’m going to argue that it has failed”.

    Well, please argue it then.

    Please provide evidence that it – deployment – failed, not that it is hard to understand (69 pages of training books and multi-day training courses are the latter)

    I mean, it became possible to fully secure things end-to-end since 2010[1], so in about 10 years from by your length of time since theory, we should know.

    [1]: http://www.root-dnssec.org/

  2. You over-simplify the matter. Getting going with “secure” protocols seems easy. Using these protocols in a secure manner is hard and nobody does this very well. How often do you actually use an out-of-band channel to verify the fingerprint of a remote host the first time you SSH in? How often do you click away the certificate warning in a browser?

    DNS doesn’t interface with a human, when you don’t do this “trust” thing correctly and you break DNS and there’s nobody to click the warning message away.

    • User friendliness should be part of the design. It should be hard to do it wrong and easy to make it work. We have learned now that security is something that we all have to do, but this approach with dnssec is not the right one. Something has to change in order to make dnssec a success. Getting attention to this fact is one step, getting people together to fix it is the next.

  3. Absolutely agree. DNSSEC had been an abysmal failure despite the many millions the US poured into it.

    And there is a simple reason for this: the community has failed. They failed to get the spec right in 12 years. Then they failed to get the deployment going. You’re pointing out that the UX has also failed. But what do you expect from a community who worships a jack like Paul Vixie, who is loud, obnoxious, and so incompetent that he couldn’t even get a secure DNS implemented let alone DNSSEC.

    The protocol may or may not be OK, but the whole community needs a do-over.

  4. What good is the SSH security model globally without DNSSEC signed SSHFP records?

    Are you advocating a global SSH PKI? Good luck with that.

    What about > 100 trusted authorities in parallell? Any one who says it’s legit wins? Great idea! Especially when half of them are happy to give you a valid cert if you own the DNS records. Yay!

    If you’re going to criticize DNSSEC then please present what could be improved and what you would like to see instead. Nobody will force you to read that book with 100 pages, and I’d better not tell you that there are books about good old unsigned DNS well above that length…

    • In the last paragraphs i argue that we need better documentation and user experience. The weakest point in any secure solution is almost always the user. We can have real security when we make it hard for a user to do something wrong.

      We need to think about how we can do dnssec easier and explain it better than we do now.

  5. Pingback: RT @suffert: https://t.co/3x1Z9lDC4g DNSSEC Has Fa… | Infomag.nl

  6. I think it’s important to distinguish who you mean by ‘the user’.

    From my point of view the user is the average joe who uses a web browser to retrieve a website and does the look up. I agree this should be user friendly and transparent. And if OS vendors implement this in their resolvers at least the user friendly part is there since nothing changes for them.

    If you are talking about site/dns administrators I think there’s nothing wrong with spending some more time to see what you’re actually working with. An ISP can easily spend some hours on figuring out DNSSEC and how to implement this correctly. A site administrator who has 5 domains and doesn’t want to go through all the hassle of learning and setting up DNSSEC should let the DNS servers be managed by an ISP who does implement it correctly. I do think a little user-friendlyness helps but I don’t see it as a major problem in DNSSEC adoption.

  7. Jeroen,

    I was somewhat amused to read this post tonight when I am moderating sessions tomorrow at the DNSSEC Workshop at ICANN 49 in Singapore tomorrow where we will have presentations about the very real DNSSEC deployments that are happening around the world. We’ll also have some presentations related to DNSSEC measurements (particularly related to validation) and more. You’re welcome to tune in and/or read the slides at:


    As others have already critiqued details of your post, both here and in other blog posts, I won’t spend time on that because I think you and I are violently in agreement with regard to what you write: “We need to think about how we can do dnssec easier and explain it better than we do now.”

    About 3 years ago my employer, the Internet Society, created the team of which I am now part to do precisely this: look at why some protocols such as IPv6 and DNSSEC were not being widely deployed and to look at how we could help accelerate the deployment. We then started collecting material and resources and making those available in early 2012 at http://www.internetsociety.org/deploy360/dnssec/. Two years ago I wrote up a document outlining many of the issues I saw that were hindering DNSSEC deployment:


    It includes points which you made in your text as well as a number of others. The key point is that DNSSEC deployment needs to be made easier on a whole number of levels.

    Two years, later, we’re in a much better situation… but yes, MUCH more still needs to be done. The tools have gotten easier. There is now more deployment happening in many TLDs. There are more registrars supporting DNSSEC. The rise of the DANE protocol has now provided a very solid use case for why DNSSEC can provide very real deployment. And we’re seeing very large-scale deployments of DNSSEC-validating resolvers (ex. Comcast in the US, Google Public DNS, ISPs in Sweden/Czech Republic/Brazil.

    Documentation is getting better but still very much needs to be improved and simplified, which is something a number of people are working on right now. As an example, on the *validation* side, the folks at SURFnet there in NL published this document that shows how to easily configure several recursive caching resolvers to do validation:


    Even better, we’re starting to see DNSSEC validation turned on *by default* in several of the free/open source operating systems. Most recently, FreeBSD 10 shipped with unbound with, I understand, validation on by default and also with support for the SSHFP records. Fedora has also shipped with DNSSEC validation enabled for some time now.

    On the signing side, it is admittedly still a bit complex. We’ve provided some simple instructions for a few registrars that also provide DNS hosting:


    There are also a number of good tutorials out there beyond the DNSSEC HOWTO you mention:


    including a very recent one from Microsoft about how to set up DNSSEC on Windows Server 2012. Yes, more are definitely needed… and we as an industry/community need people to write these!

    Another positive sign is that we’re seeing very real efforts within the world of the IETF to address a number of the challenges with DNSSEC deployment through changes to the protocol. For instance, there is work within the DNSOP group to standardize mechanisms for communication of new keys from a client zone to a parent zone so that we can automate that updating and potentially remove one area of breakage that occurs with key rollovers. Another example is work on performing a secure transfer of a key from one registrar to another. Another is the “DNSSEC operational guidelines” that were published as RFC 6781: http://tools.ietf.org/html/rfc6781

    I guess my main point is that the need you identify is very definitely known and people are actively working to address that need. More work is definitely needed and you or anyone reading this post would be welcome to join in the effort through a number of the mailing lists and other forums frequented by folks focused on DNSSEC (see http://www.internetsociety.org/deploy360/dnssec/community/ , particularly the dnssec-coord mailing list for those wanting to advance DNSSEC deployment ). It takes time, but 2.5 years into my own work in the space I’m very pleased to see where it is now.

    In your article, you point out that the original specifications for DNSSEC happened about 17 years ago. While that may be true, the reality is that for most people there was little incentive to do much with DNSSEC until the root of DNS was signed back in 2010 bringing the full “global chain of trust” into action without the need for workarounds like DLV.

    So in reality we’re only about 4 years into the active deployment of DNSSEC. And yes, we need to make DNSSEC simpler and easier to deploy – and better documented… but that doesn’t mean it has “failed”. It only means we have more work to do!

  8. Pingback: Improving Dnsmasq | Jeroen van der Ham – 1s and 0s .nl

  9. Most resolving software supports DNSSEC, but none have enabled it by default

    BIND has DNSSEC validation enabled by default.
    The Debian Unbound package bootstraps validation with unbound-anchor and also enables it by default.

    You could argue the same way that IPv6 has failed. And yet, both IPv6 and DNSSEC are being rolled out and enabled
    transparently to the users.

  10. Pingback: Making DNSSEC More Accessible | Jeroen van der Ham – 1s and 0s .nl

Comments are closed.