Why you need to deploy DNSSec now

Putting off updating your DNS servers to DNSSec? Do you really want to risk cache poisoning? DNS luminary Cricket Liu tells about the risks and why you can't wait

1 2 3 Page 2
Page 2 of 3

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.

Related:
1 2 3 Page 2
Page 2 of 3