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. _

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.