I first became familiar with DNSSEC around 2002 when it was a feature of the Bind9 server, which I was using to setup a new authoritative DNS platform for customers of the ISP I was working for. I looked at it briefly, decided it was too complex and not worth investigating. A couple of years later a domain of a customer got poisoned in another ISPs network. And while the DNS service we provided was working properly, the customers impression was we hadn’t protected them.

That incident made me rethink my opinion on DNSSEC which could have prevented the cache poisoning. Even a couple of years later DNSSEC was still extremely complex, but I was able to educate myself and managed to setup a signed domain; and using their key as trust anchor, did secure resolution. The whole process was a lot different from the DNS administration we used to have: setup a server, load a zone, and forget about it. Here’s what I had to do:

• Generate keys (best practice is to have at least two)
• Sign zones

The real work comes from housekeeping, because in cryptography everything has a limited lifetime. The biggest challenge is a lot of stuff has to be done repeatedly:

• Whenever something changed zones it had to be re-signed
• After some time keys expire, so new keys must be generated
• Zones then had to be re-signed
• Transition the zone from using one key to the other key

The last topic alone fills half of the DNSSEC operational RFC which in the most current version is 67 pages long. Also note, this did not cover the effort to manage trust anchors for caching servers, which is substantial when you don’t have a signed root. So deploying DNSSEC was possible, but it was a long way from being usable even for an experienced DNS admin.

To make DNSSEC easier there were two main problems that had to be solved:

Most people are aware DNS is a hierarchical system so cryptographically protecting DNS data introduces significant complexity. With DNSSEC, signatures have to start at the root, and then propagate down to the TLD and so on. It has always been possible to deploy DNSSEC without a signed root but everyone quickly figured out it was very cumbersome for operators of recursive name servers. This is a major reason why DNSSEC wasn’t adopted earlier. It was most definitely lacking “ease of use”!

DNS admins and customers/users care about DNS data, they are not interested in the actual wire representation and signatures. Yet all the tools (if you could call them that!) required them to understand everything.

The first problem was solved on the 15th of July 2010 with the root being signed. Today 77 TLDs are signed and delegated from the root including the biggest gTLD and ccTLD (.com and .de respectively).

The second problem was actually solved even earlier. While working at an ISP I concluded DNSSEC could do some good things, but it needed work. Based on a lot of detailed discussions and feedback a group of engineers at Nominum came up with a great solution. I first got access to it in 2009 and was pleasantly surprised to see it removed all the configuration complexity (I’ll cover the details in another blog post) Full disclosure: I joined the company about a year later.

With major hurdles for DNSSEC deployment removed, there is no reason not to start deploying it now. Of course rollouts have to be planned, but if you start to setup DNSSEC for your test/lab environment you’ll see how easy it is with the right tools.