The first cache poisoning attack against DNS infrastructure occurred way back in July 1997, when Eugene Kashpureff injected a bogus address for the InterNICs web site into the caches of name servers around the world. Users who tried to reach www.internic.net were instead directed to a web site under Kashpureff’s control. Mercifully, given the enormous potential for damage and loss, Kashpureff didn’t attempt to profit from his exploit: He used it to point out the monopoly control the InterNIC had over registration under the com, net and org zones.
The vulnerability Kashpureff exploited was quickly patched, but it was the beginning of a long cycle of identifying vulnerabilities to cache poisoning in name servers and rolling out new name server software. As recently as 2007, Amit Klein discovered flaws in the BIND name server that made cache poisoning simple, if not trivial.
Then, just over one year ago, Dan Kaminsky discovered a cache-poisoning vulnerability not in any particular name server implementation, but inherent in the design of DNS. This was a vulnerability that couldn’t simply be patched: It would require systemic changes to DNS to address. Without these changes, we could reduce the risk to cache poisoning but not eliminate it.
The consequences of a successful cache-poisoning attack are so dire that describing them inevitably sounds like hyperbole: A hacker who poisons the cache of a recursive name server can redirect users of that name server to web sites that appear identical to those run by their banks, insurers, or governments, where their logins, passwords, and financial information is recorded for later reuse. He can reroute email through hostile mail servers, where that mail is surreptitiously modified for his gain, or simply copied and stored, with neither sender nor recipient aware. Virtually every non-trivial transaction that takes place on the Internet relies on DNS, so in a real sense, widespread vulnerability to cache poisoning means the end of trust on the Internet.
Thankfully, the Internet Engineering Task Force was aware of shortcomings in DNS’s security (though not the Kaminsky vulnerability in particular) and had been working on the DNS Security Extensions since the mid-1990s. These extensions, called DNSSEC for short, use public key cryptography to enable DNS administrators to digitally sign their zone data. Name servers that retrieve this data can use public keys like the signatures, stored in zone datato validate the signatures. With DNSSEC validation, cache poisoning is nearly impossible.
Unfortunately, for a variety of reasons, DNSSEC has been slow to catch on. There was a substantial rewrite to the original specifications, and another, less extensive update recently. Consequently, implementers had to wait for finalization of the specs and administrators hesitated in deploying DNSSEC. Some aspects of the management of DNSSEC-signed zones have taken time to formalize and document. Understanding of DNSSEC even among DNS administrators remains limited. And the benefit of signing a zone is diminished by the lack of signed parent zones and the paucity of name servers configured to validate signed responses.
In just the last few months, however, many of these issues have been addressed. The DNSSEC specifications have been finalized and several good, interoperable name server implementations support DNSSEC, including BIND, NSDand Unbound. Management tasks such as key rollover have been more clearly documented and, in the case of some commercial tools(like Infobloxs), automated. And many registries have announced plans to sign their top-level zones, or have already signed them. This includes .gov and .org(which are signed) and .com, .net, .edu, and the root zone (which have announced plans).
The US Federal government, in particular, has acted aggressively, requiring GSA to sign .gov earlier this year and other government agencies that run Internet-facing …. Further, FISMA requirements that take effect in 2010 will require signing internal zones as well, and probably appl[y] to the civilian side of the DoD, according to Scott Rose, co-author of NISTsSecure Domain Name System Deployment Guide, SP800-81.
The main items left on the DNSSEC implementation checklist,then, are for DNS administrators to learn DNSSEC and to begin assembling or acquiring the tools that will help them manage signed zones. To this end, I recommend the following:
- NISTs Secure Domain Name System Deployment Guide
- Chapter 11 of my book, DNS and BIND, on DNS security
- My best practices architecture for DNSSEC
