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.