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 3
Page 3 of 3

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.


Copyright © 2014 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3