Why you need to deploy DNSSec now

The Domain Name System — the distributed network of servers that reconciles the domain names in URLs and email addresses to numerical IP addresses — is behind every successful Internet transaction. Unfortunately, due to a longstanding vulnerability, it’s also behind some of the Internet’s most dangerous hacks — despite the fact that a fix, DNSSec (Domain Name System Security Extensions), has been available for years.

In this week’s New Tech Forum, Cricket Liu, chief infrastructure officer at Infoblox, explains how DNSSec thwarts DNS spoofing or cache poisoning attacks, why adoption of DNSSec has taken so long, and why we can’t afford to wait any longer. — Paul Venezia

All about DNSSec — and why you need it

DNSSec, short for the Domain Name System Security extensions, is critical for trustworthy communications and transaction on the Internet. It fixes cache poisoning, a long-standing, potentially crippling vulnerability in the Domain Name System.

How long-standing are we talking about? Steve Bellovin first described the possibility of cache poisoning in a paper he wrote in 1990 — almost a quarter of a century ago. How critical? Well, suffice it to say that if we can’t successfully address the threat of cache poisoning, we can’t do anything safely over the Internet because every nontrivial Internet transaction is mediated by DNS.

But the adoption of DNSSec, after showing some initial promise in 2010 and 2011, seems to be stuck. The DNS community did some very hard work, signing most top-level zones, including the root zone, the .com, .net, and .org zones, and many country-code top-level zones. But adoption among their subzones is paltry.

Consider that .com, the largest top-level zone, boasts more than 100,000 signed subzones — out of over 100 million. Some country-code top-level zones boast higher percentages of adoption, but many are nearly as pathetic as the gTLDs. What’s the problem?

How DNSSec works

Before discussing the reasons why the adoption of DNSSec has been so slow, we need to take a look at how DNSSec works and how it prevents cache poisoning.

Cache poisoning, of course, is inducing a name server to cache bogus resource records. Those records might map the domain name of a popular website — say, www.ebay.com — to the IP address of a Web server under the control of nefarious evildoers.

That Web server may serve content that’s indistinguishable from eBay’s real content; in fact, the Web server may just proxy content from the real www.ebay.com. Unwitting users may enter valuable information at the impostor website, where it’s recorded and used to break in to those users’ accounts, run up charges, and so on.

DNSSec addresses cache poisoning by allowing the administrators of zones to digitally sign their zone data, in much the same way that you might sign an important email message.

For example, Infoblox’s administrator has signed the infoblox.com zone. Name servers that receive infoblox.comdata in response can then validate that data using the digital signatures that automatically accompany the responses. If the data validates, the name server can be sure of its authenticity and integrity.

In the case of infoblox.com, this would mean that the name server that performed the validation could be certain that the A record for www.infoblox.com was signed by the duly authorized administrator of the infoblox.com zone, and that it wasn’t modified after it was signed. If a nefarious person tried to inject a bogus A record for www.infoblox.cominto a name server’s cache, they couldn’t forge the accompanying signature and the name server would reject the A record after it failed validation.

So how does signing work in the context of DNS? Unfortunately, a complete description of how the DNS Security Extensions work would (and did) require a substantial portion of a book. But simply dissecting a signature actually tells a lot of the story of DNSSec. For example, here are the MX records for infoblox.com and their signature, encoded in what’s called an RRSIG record:

infoblox.com.  900  IN  MX  10 mx1.infoblox.com. infoblox.com.  900  IN  MX  10 mx2.infoblox.com. infoblox.com.  900  IN  RRSIG  MX 5 2 900 20140510002819 20140505234505 18165 infoblox.com. BGECQe+go9k4MxyTkbN6l8WCzj8DhxGoIMhQOB3iaZ2+u1Y6blKK1/Sp +vyQXDfDIPEN77NGrN3QhzIrRC6xQX+wmHhcOYrhg2r28L7UfQnvYQYm j6sXxlCyPbMlykDiBpTkslcE9GAVAM9LkOxrxIGmalfgibHwtAOIsq2S wsw=

Let’s start dissecting the RRSIG record just to the right of its type field, RRSIG. The next field is MX, which tells us the type of records this signature pertains to, and together with the first field of the record, infoblox.com, identifies the particular records signed (namely, the two MX records immediately preceding).

Why does the signature only pertain to infoblox.com’s MX records and not, say, its A records? Because a name server can look up just MX records, so those need a separate signature. Infoblox.com’s A records have their own, separate RRSIG record. And why sign infoblox.com’s two MX records together rather than individually? Because there’s actually no way to send a DNS query that would return just one of the two, so they’re always returned together and therefore might as well be signed together.

The next field, containing a 5, identifies the cryptographic protocol used to produce the digital signature. DNSSec uses public key cryptography to digitally sign DNS data, but it supports different flavors of public key cryptography, including RSA, DSA, and Diffie-Hellman.

We’ll ignore the next two fields and move on to the two timestamps in the format YYYYMMDDHHMMSS. The first is the signature’s expiration time, and the second is the signature’s “inception time” (the time the signature was generated). The signature, as you might guess, is only valid between those two times.

The next two fields are called Key Tag and Signer’s Name. Together, they identify the private key that was used to generate this signature. To find the corresponding public key, which would enable a name server to validate the signature, you can look up DNSKEY records attached to the Signer’s Name. If there are multiple DNSKEY records — and there often are — you can determine which is the right one by looking at the Key Tag.

The gargantuan final field (everything from “BGECQe” to “wsw=”) is the digital signature itself. The signature is actually binary, but here it’s encoded in a format called base 64. Base 64 encodes binary data as ASCII; it’s used here because RRSIG records often appear in zone data files or output in which binary data would be illegible.

It’s remarkably easy to go from this analysis to a basic understanding of how signing and validation works:

• In signing, a zone’s private key is used to compute a digital signature for each set of resource records of the same type and attached to the same domain name (called an RRset for short). The signatures are then added to the zone in the form of RRSIG records.
• In validation, a name server receives an RRset as an answer, accompanied by an RRSIG record. It retrieves the DNSKEY records specified by the Signer’s Name field, chooses the correct key by matching the Key Tag, then attempts to validate the signature in the RRSIG record using that public key. If the validation succeeds, the records in the answer are good; otherwise, they’re bogus.

There’s much more to DNSSec, of course: the chain of trust, proving non-existence (which sounds more like a topic for a late-night college philosophical discussion), and more. But for a discussion of why deployment has taken so long, this is enough background.

Human factors and DNSSec Now let’s talk about implementations. One of the first implementations of DNSSec, included in BIND 8 in 1999, was nearly unusable. Signing a zone for the first time was a Byzantine affair, requiring multiple command-line tools — dnssec-keygen, dnssec-signzone, and so on — each of which understood between a half-dozen and a dozen command-line options and option arguments. You ran these, they created files, you appended these files to existing zone data files, you ran other tools.

I remember documenting how to use these tools to sign a zone for the first time in the fourth edition of my first book, “DNS and BIND.” The process required 12 steps and more than 20 pages to describe. When I was done, I honestly thought, “No one in their right mind is ever going to do this.”

When you wanted to re-sign a zone — which you had to do any time you modified it, or even if you hadn’t modified it but the signatures were nearing expiration — you had to run a command-line tool to sign it again. And the command-line tool regenerated all of the signatures in the zone, even if you’d only modified one record.

This made for frustrating, error-prone administration. Back in 2009, federal agencies scrambled to meet a Sept. 31 deadline set by the Office of Management and Budget to sign Internet-facing subzones of .gov, and many of them made it. But 30 days later, much of their zone data began to fail validation. What happened? Most administrators never bothered to automate the re-signing process and their signatures expired after the 30-day default lifetime had passed.

This wasn’t laziness, or at least not entirely. Take it from someone who’s spent 20-plus years teaching DNS and BIND administration: Even without DNSSec, it’s not easy. The syntax of named.conf files and zone data files is unforgiving, and the name servers that read them equally so. Add DNSSec on top and it can get downright diabolical. And in this day and age, who has the luxury of concentrating solely on DNS, like I did when I ran hp.com? Everyone’s struggling to keep their firewalls running or to get their access points upgraded or what-have-you.

The good news is that the Internet Systems Consortium and vendors including Infoblox have expended a lot of effort simplifying and automating these processes. Now you can sign a zone with a single click (OK, a few clicks) in a GUI or with rndc signzone, and the zone’s maintenance is taken care of for you. But maybe too many administrators were scarred by the horribly manual process in those early days.

There’s another human factor that delayed adoption of DNSSec, both by some implementers of name servers and some DNS administrators: uncertainty. The first RFC describing DNSSec, RFC 2065, was published in January 1997. Attempts to implement this specification led to a revised version of DNSSec, described in RFC 2535, published in March 1999. But experience demonstrated that this version, too, was impractical to manage on a network as large as the Internet. This led to additional changes to DNSSec, published in March 2005 as RFCs 4033 through 4035.

But even these modifications weren’t enough. Privacy advocates argued that DNSSec-signed zones were vulnerable to having their contents revealed through what’s become known as a “pseudo zone transfer,” and certain registries (the organizations that run top-level zones such as .com) argued that adding signatures to every set of NS records in their zones would be overly burdensome. And so RFC 5155, which introduced yet another new DNSSec record type, NSEC3, was published in March 2008.

The details of the history aren’t as important as the fact that DNSSec changed a lot from 1997 to 2008 (so there will be no test), making it a moving target for name server implementers and DNS administrators. Some of them, understandably, opted to defer adding DNSSec support to their name servers or signing their zones until the dust settled.

But now it’s 2014, the dust has (mostly) settled, and there’s support for DNSSec in every major name server implementation, from BIND to the Microsoft DNS Server to newcomers like NSD and Unbound. So it’s time to get moving.

Motivation, overhead, and the future of DNSSec What will it take to motivate network administrators to widely adopt DNSSec? I’ve mentioned the OMB mandate that required federal agencies responsible for subzones of .gov to sign them. That directive certainly spurred deployment under .gov, but it’s an anomaly: Most top-level zones impose no similar requirement, partly because they lack any authority to do so.

There is one organization, however, that is in a surprisingly strong position to influence the uptake of DNSSec: the PCI Security Standards Council, responsible for the development of the PCI Data Security Standard and other standards governing the payment card industry. Longstanding rumors say the organization is considering requiring companies whose websites accept payment cards to use DNSSec to sign their zones in order to achieve PCI DSS compliance. Given how pervasive acceptance of credit cards is on major websites, such a requirement would have vast reach.

Some top-level zones have had good success using a carrot approach, in contrast to the OMB’s stick. SIDN, for example, which manages the Netherlands’ top-level .nl zone, offered a discount to registrars registering signed zones, and in a span of a few weeks vaulted to the position of the zone with the largest number of signed subzones on the Internet.

There’s one last stick that may yet induce reluctant DNS administrators to deploy DNSSec: lawsuits, or the threat of them. While successful cache poisoning attacks are, by their nature, difficult to detect (the poisoned records tend to magically disappear from caches after their TTL expires), such attacks do occur. In my opinion, it’s just a matter of time before a resident of some lawsuit-happy country (read: the United States) falls victim to a cache poisoning attack and has their bank account drained. When the victim’s personal injury lawyers go looking for deep-pocketed parties with a share of the blame, they’ll doubtless be thrilled to learn that the company whose website their client tried to visit doesn’t use DNSSec to sign their zones, nor does their client’s ISP bother to validate DNSSec data.

The overhead of DNSSec is also sometimes cited as an impediment to adoption. From the example RRSIG record you saw earlier in this article, it should be obvious that zones get larger when you sign them. Not only does signing add one RRSIG record per RRset (or even more, when you’re rolling over from one key pair to another), but those records are also much larger than most “normal” (non-DNSSec) records. Signing a zone typically increases the size of the zone by a factor of four to seven. That has a direct impact on how much memory the authoritative name servers for that zone need, as well as how much memory recursive name servers caching data from that zone need (since they’ll also cache the signatures, public keys, and so on). The traffic exchanged between recursive and authoritative name servers increases, too.

If you already know something about DNSSec, you might think these increases wouldn’t affect a recursive name server not configured to perform validation because it wouldn’t set the DO (DNSSec OK) bit in queries to authoritative name servers. However, modern BIND name servers set the DO bit by default, so they receive DNSSec records whether or not they intend to use them for validation. Why bother? Well, those name servers can’t be sure that downstream name servers using them as forwarders aren’t doing validation. Those downstream name servers would need those DNSSec records. So your BIND name server’s cache will bloat with DNSSec records regardless.

CPU utilization on recursive name servers that perform validation rises with increased DNSSec deployment, too. Validating a single RRSIG record requires a cryptographic hash operation and an asymmetric decryption operation; that’s a whole lot more computation than is needed to pull an unsigned DNS response off the wire and unmarshal it into cache. But it’s even worse than that, because resolving a single query may entail following multiple referrals, each of which comprises records that may need validation. And if your name server doesn’t already know the DNSKEY record that contains the public key needed to perform validation, it’ll need to send another query to find it — then it’ll have to validate the DNSKEY record!

Of course, this article is about the slow deployment of DNSSec. At least until hordes of DNS administrators read this, you won’t have to worry about your recursive name servers consuming too many CPU cycles validating signed data, or the amount of memory taken up by all those DNSSec records. Unless you happen to live in the Netherlands.

With all of these factors at work, the slow deployment of DNSSec should come as no surprise. But most of the big impediments to DNSSec’s adoption — the moving target of the standard, the difficulty in administering a signed zone using early tools — aren’t issues anymore. And the overhead of running DNSSec, while very real, will be introduced gradually as more zones are signed.

That leaves only the motivation to do it. A few of you may work for organizations or in countries where there’s a concrete incentive to deploy DNSSec, but most of you have no such carrot. Absent inclusion in a compliance regime such as PCI DSS or the threat of a lawsuit, deploying DNSSec is strictly optional for you. But widespread adoption of DNSSec is an absolute requirement if we want to continue to use the Internet for anything non-trivial. I hope you’ll consider this my carrot to you.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

This article, “Why you need to deploy DNSSec now,” was originally published at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.