Home / Blogs

Getting On Board With DNSSEC - A Personal Recount

Ralf Weber

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.

By Ralf Weber, Senior Infrastructure Architect at Nominum
Related topics: Cybersecurity, DNS, DNS Security

If you are pressed for time ...

... this is for you. 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

Share your comments

94 TLDS signed with DNSSEC Dan York  –  Apr 23, 2012 8:51 AM PDT


I very much agree with you that automation is needed for more domain name holders to sign their domains.  Some registrars make it very easy (and fully automated) but with many it is still a bit of a process.

One note about your article, though. Per the latest ICANN TLD DNSSEC report there are now 94 TLDs that are signed - http://stats.research.icann.org/dns/tld_report/


Time flies Ralf Weber  –  Apr 24, 2012 11:36 PM PDT


I did only count TLDs that had DS records in the root zone, which are currently 86. I did originally write this article, which also appeared on my companies website, some time ago when the number of domains that had a DS was 77. But I'm pleased to see that it has increase significantly since then.

Also registrars are just one piece in the puzzle to get people to DNSSEC albeit an important one. But we also need DNS operators of recursive and authoritative services to support DNSSEC in order to get widespread adoption.

So long

Ralf,Thanks for the explanation!I definitely agree that Dan York  –  Apr 25, 2012 8:49 AM PDT


Thanks for the explanation!

I definitely agree that registrars are only one part of the DNSSEC deployment puzzle. Last month I actually presented on this very topic at the SATIN 2012 conference in the UK.  My paper on challenges and opportunities for DNSSEC deployment is available here:


It hits the topic of DNS operators as well.


To post comments, please login or create an account.



New TLDs

Sponsored byAfilias

DNS Security

Sponsored byAfilias

Domain Names

Sponsored byVerisign


Sponsored byVerisign

IP Addressing

Sponsored byAvenue4 LLC