Trouble Ahead – The Implementation Challenges for DNSSEC
There has been a lot of recent buzz surrounding implementation of Domain Name System Security extensions (i.e., DNSSEC). The latest example: verification and signing of DNSSEC for the .IN (India) and .ASIA top-level domains (TLDs), which are being pitched as major enhancements to global security for much of Asia.
Yet massive industry-wide confusion, continued lack of awareness for DNSSEC outside the DNS industry, a plethora of DNSSEC verification techniques and standards, and arguments over which to use, tell a different story. This also leads to some key takeaways for anyone looking at implementation today. We will take a closer look at the history and reasons for the existence of DNSSEC and some of the key implementation roadblocks in this first of a three-part series on DNSSEC deployment.
DNSSEC is supposed to protect the Domain Name System (functionally, the Internet’s phone book) from several authentication exploits, primarily cache poisoning. These attacks can allow malicious entities to intercept Internet users’ requests to access a website, e-mail, or other services, and redirect or eavesdrop on the users without their knowledge. They are invisible to the users and leave them no ability to reassert control – potentially costing organizations millions of dollars in lost reputation, recovery costs and more. DNSSEC introduces digital signatures to the DNS infrastructure and is supposed to automatically block cache poisoning by authenticating the identity of a given domain or hostname.
The technology grabbed major headlines in 2008 when security researcher Dan Kaminsky exposed a serious flaw in the DNS that allowed cyber criminals to easily launch cache poisoning attacks against DNS software used by a majority of recursive nameservers. Using such attacks, cybercriminals could impersonate websites, intercept e-mail or steal passwords to hacks into corporate networks. This thrust DNSSEC, which had been around for close to a decade, into the spotlight. Industry leaders and professionals rallied around it as a solution to potentially endless DNS cache poisoning attacks.
Unfortunately, years later, wide-spread DNSSEC adoption is still far from completion, even for critical domains and services. A recent Forrester Research survey commissioned by VeriSign found that only 43 percent of nearly 300 global network operations or IT security influencers/decision-makers had “heard of DNSSEC and know what security problems it solves.” This is despite the fact that over half admitted they had experienced some sort of “DNS attack” and over a third had been hit with what is called a DNS “man-in-the-middle” cache poisoning attack, exactly what DNSSEC defeats. So the need is there, but awareness and action lag.
The Root Signing
One of the key issues that had held up deployment is that DNSSEC relies on exchange of digital signatures and certificates for verification of trusted domains up and down the entire “chain of trust” from the root of the Internet. And until the root servers, which sit at the top of the DNS hierarchy were signed, the system did not really work very well – at least without some major band-aids that most operators were unwilling to adopt. Hence the elaborate ceremony at a high security data center in Culpeper, Virginia, this past July for signing of the root zone. So we are all ready to go now, right?
Not so fast. This really only marks the beginning of deployment. As we saw at the start of the article, .IN and .ASIA were just signed this month, with other major TLDs coming online with DNSSEC over the past few months. Some of the biggest TLDs like .COM, .NET, .UK and many others, aren’t signed yet. As a result, subdomains like www. yourcompany.com cannot be fully authenticated to the root. Or at least there is not a major benefit if they are, and there may be failures that lead to further issues – more on this in my next article.
But while delays in the signing of top-level domains have slowed DNSSEC, that’s not the hard part of deployment. In fact, all of these TLD zones should be signed by sometime early next year. And then the real challenge will be upon us: the zillions of domain names, and hostnames within the zones.
So are organizations and businesses positioning themselves to take advantage of DNSSEC? Yes and no. For example, our research shows that many .GOV domains are adopting DNSSEC, mainly driven by government mandates. But dig a little deeper and you will find that actively managing DNSSEC at many of these organizations remains a challenge, creating errors and omissions, and not fully delivering the benefits of signing.
Yet in a very real sense, this is exactly the time to plan or begin implementation if you want to be in a position to take advantage of the technology. So what are some of the major the pitfalls, and how can they be avoided?
DNS – From Simple to Complex
DNS management is well understood and fairly straightforward in the networking world. However, one of the first major pitfalls is that unlike traditional DNS management, DNSSEC implementation is complex. There are not many simple tools or straightforward “how-to” manuals available to help. This is changing, but we are still talking about “bleeding edge” technology here, and that means risk.
A case in point: The UK TLD inadvertently failed authentication for several hours this past September, because they did not complete the simple process of syncing up ZSKs (Zone Signing Keys) on all their hardware. Then Belgium accidentally did a similar thing for several hours in October due to basic operational errors – they let their DNSKEY expire and didn’t have a backup live. Both of these failures ran the risk of taking these countries domains off the Internet. Lesson one: this ain’t easy. Lesson two: if the guys that actually get paid big bucks to run DNS for entire countries are struggling, how will someone like a mid-sized bank be able to cope?
So how does it work in a nutshell? DNSSEC adds private/public key validation via four new resource record types added to the standard DNS: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC), though there are a few flavors of NSEC now. Using a chosen algorithm and tool, a private key is used to generate public keys to populate these various records. Public keys for a zone (domain/hostnames/TLDs/etc.) are stored as DNSKEY records. After signing each record with private keys, signatures are stored as RRSIG records. These records must appear in a zone’s DNS along with other sundry records for management like well-considered TTL values. During the signature process a DS record is generated that needs to be published by the parent zone to create a “chain of trust”. For a domain name, a DS record has to be added to the registry’s zone – typically by a registrar. This is not your father’s DNS system!
Larger enterprises are clearly the ones who will most benefit from DNSSEC, and also have the best resources available for implementation. But as these organizations begin to roll their own deployments, they would be wise to consider partnering with an expert consultant to help guide the process (services are offered by such companies as Afilias, Neustar and VeriSign, among others), or leverage one of the free toolkits that have begun to pop up (such as Kaminsky’s recently released Phreebird).
Hardware and DNS changes The next pitfall is fairly mundane, but of extreme importance. If you’re running your own DNS implementation, you need to properly handle the increased overhead required to run DNSSEC on your infrastructure. You also have to tighten up your DNS change management practices. DNSSEC requires larger packets, and therefore more memory and processor horsepower than standard DNS. Networking gear also has to support TCP DNS packets, a switch from the existing standard of UDP packets. These are all typical “gotchas” for implementation. In addition, all changes to zones must be accounted for with a new signing every time. These are good examples of reasons to consider outsourcing your DNS when changing over to DNSSEC.
If DNSSEC is complex and offers opportunities for failure, then logic dictates the best strategy is to set it and forget it. Yet proponents of rock-solid security recommend rollover of ZSKs every quarter, and KSK (Key Signing Key) every two years, meaning you have four to five chances for things to go wrong per year. And… your registrar and the root domain should each do the same. Now you are at about a monthly opportunity for disaster, only a few of which you control. The reason for this is the belief that “bad guys” out there will be trying to decrypt your keys, and the longer your key stays the same, the better odds they have of doing so.
Perhaps the best way to view this is through analogy. How often do you rekey the door locks on your business? Most likely, the answer is: only when there is an issue or event that warrants it. This is also the best approach to DNSSEC at this stage; organizations would be wise to roll over their signature keys whenever an event, such as the firing of an employee that knows the keys, warrants a change.
If you are worried about bad guys guessing your keys (and that’s a pure speculation problem at this point), then monitoring of your DNS queries for signs of someone trying to systematically try to “pick your lock” is advised. You should be monitoring your DNS logs for all kinds of other security reasons anyway, so this provides a good excuse for investing in that capability if you do not have it already.
Another key-related pitfall? It turns out that since the DNSSEC key-signing standards themselves are not yet finalized, and are evolving to take advantage of newer cryptography methods, many of the algorithms for generating signature keys are not fully compatible. In other words, one particular key signing technology doesn’t work with another particular DNSSEC implementation – which is a horrible thing to find out after you have just completed deployment.
While the newer standards are backwards compatible (or are supposed to be) that doesn’t help when you choose a newer method to sign, and a major ISP or key partner uses an older method to authenticate. Errors then ensue where people are not able to reach your domain since the authentication fails. Since authentication on resolution still isn’t really being done “for real” (I’ll touch on that chicken-and-egg problem in a later installment), the recommendation now is to choose one of the newer methods that provide stronger crypto and better security, as those will likely be the methods that receive wide adoption on the resolver side when those finally roll out.
Another pitfall derives from the fact that DNSSEC is still very new, and as a result, not many registrars support the technology as yet. One primary reason is the economics. With domain names selling for a few dollars per year, and the extraordinary variety and volume of domains that don’t engage in e-commerce or sensitive communications (two main security drivers), there is little incentive today for registrars to absorb the costs and administrative overhead required to support DNSSEC. DNS providers are much more likely to be in front of the curve on DNSSEC, but options are limited.
However, there is a silver lining: hunting for a new registrar or DNS provider also provides the opportunity to select one that offers two-factor authentication and additional domain locking services. And if you are not doing multi-factor authentication for domain management already, you are missing one of the single biggest security holes around. Additional information on this can be found in the recently published report from ICANN’s Security and Stability Advisory Committee.
Assuming your registry supports DNSSEC, you are still not out of the woods. When you sign your own DNSSEC records for your domain, you still need your registry to publish the “DS Record” in THEIR zone for your domain. This is what ensures the “chain of trust” from the root on down to individual hosts – higher authorities validate your records from their perspectives. That is all well and good, but not all registries support all signing methods. Thus you need to ensure that the signing method you want to use is supported by the registry (and of course the registrar) for your domain’s TLD.
Are we having fun yet?
The final takeaway from all of this? If there is opportunity for DNSSEC deployment to break your connectivity, you’d better be absolutely sure to verify that your DNS records are publishing properly. The U.S. government recently went through this exercise and, much to its chagrin, found that many of its records were wrong.
Fortunately, there are a number of free tools and websites that make it easy to check the status and accuracy of DNS records, including the following:
Is DNSSEC Worth It?
With all of the implementation headaches for DNSSEC, that begs the question… is it worth it? The short answer is: yes, no and maybe – all of which we will explore in the next two articles in the series on DNSSEC.