DNSSEC - pros and cons

DNSSEC is the best thing that has happened since the invention of sliced bread!
But why are only about 3% of all domains DNSSEC enabled? And why is the adoption rate so slow?
This is our take on the challenges we face as we slowly adopt one of the most important security additions of our time.

DNSSEC was first introduced in 1997. Since the DNS protocol never was designed with security in mind (like most of the early Internet protocols) the DNS Security Extensions was a very welcome add-on to counter some very real security concerns that had plagued the DNS infrastructure. Due to the DNS very prominent role in all Internet host to host communication it has been a prime target for every hacker. Although the goal is rarely the DNS itself but by controlling or being able to manipulate the DNS data, either from its source or by injecting bogus data into caching resolvers, the hackers can route traffic through his own infrastructure to collect data valuable for mounting extensive attacks to the targets infrastructure.

The DNS Security Extensions provide a way for validating DNS query responses and thus negate cache poisoning attacks.

But the development of DNSSEC has taken time. Form the introduction in 1997 it took 13 years and several iterations to reach acceptable global adoption of the top domain levels. DNSSEC uses public key encryption to sign zones and its resource record sets. The public key used to sign the zone is presented at the parent level. The function is very similar to a PKI/CA infrastructure but with only one top level. The root domain were signed in July 2010 which marked a milestone for DNSSEC which enabled a trust chain throughout the domain name tree. So far, so good! Then what?

Despite its 20+ year history and a huge demand for security the public adoption of DNSSEC (at the second domain level) has been and still is painfully slow! Recent numbers show that more than 90% of the top level domains are signed but only just about 10 million domains at the second level are signed. This is less than 3% of the current 363.5 million registered domains!

So, why is the adoption rate so low?

There are plenty of reasons for this. The most relevant ones are listed below, starting at the top of the food chain working our way down:

• TLD deployment status

The Internet Society lists 6 stages of DNSSEC Deployment for top-level domains (TLDs)

1. 1. Experimental - Internal experimentation announced or observed
   2. Announced - Public commitment to deploy
   3. Partial - Zone is signed but not in operation (no DS in root)
   4. DS in Root - Zone is signed and its DS has been published
   5. Operational - Accepting signed delegations and DS in root
   6. DS Automation - Automation of updates of DNSSEC keys

The majority of the TLD operators are at stage 4 and 5 while only 3 of them have reached stage 6. To reach stage 6 is a very important milestone and one which make DNSSEC operations at the second level so much easier.

Reaching stage 6 should be prioritised for every TLD operator!

Most DNS vendors have solved automatic key rollovers which takes a serious load off the shoulders of DNS administrators save one, the keys (or its fingerprints) must manually be uploaded to the first the registrar, then the old keys must be removed manually. This is not only cumbersome, but the possibility for mistakes are huge and the consequences of those mistakes are monstrous! But as long as you take your time and work methodically this is very doable.

Automation here is really the key!

• Difficulty level

DNSSEC introduce a new set of resource record types: DNSKEY, DS, RRSIG, NSEC/NSEC3 and NSEC3PARAM which will take some time to get used to. Concepts like KSK and ZSK (Key and Zone signing keys) were introduced and key management were usually something DNS operators rarely came in contact with. The learning curve is quite steep, but once you get the hang of it it becomes easier.

Today, depending on which DNS software being used, the deployment of DNSSEC is usually a fairly smooth process and most vendors have decent documentation. There are of course exceptions. If you operate your own name servers you still have to consider the key management issue. A HSM (Hardware Security Module) is preferable and most software have PKCS-11 interfaces. Even though you can store the secret key on a server hard drive it is not recommended. The downside is that most HSM's are quite expensive and possibly not available to you. An open source initiative called SoftHSM that emulate a HSM is available for free and could be a viable option.

There are also a few timers concerning automated key rollovers that need a bit of understanding to get correct like key expiration versus zone expiration. But the real difficulty appears once you have to troubleshoot DNSSEC problems. I will not go into details here but a DNSSEC operator really have to do his homework and get the necessary knowledge. Like most things in life, there is no substitute for knowledge.

Many DNS/Cloud providers provide DNSSEC for free (or for a small fee) and since they operate the DNS servers you don't need to concern yourself with the nitty-gritty stuff.

All in all, the difficulty level, or rather presumed difficulty level, is one thing that has slowed down DNSSEC implementations.

• Misconception

The most common misconception of DNSSEC is that it encrypts and secure DNS traffic. It Doesn't! DNSSEC provide a way, by means of public key cryptography, for a resolver to validate the authenticity of a query response. No more. No less. As simple as that!