A Best Practices Architecture for DNSSEC by Cricket Liu
White Paper
DNSSEC, Cricket Liu The Domain Name System is the Internet’s standard naming service. DNS is responsible for mapping domain names to addresses, addresses to domain names, and a good deal more. Virtually all non-trivial Internet applications—and this includes applications that run over TCP/IP-based corporate internets such as Web browsing, email, CRM, ERP, Active Directory, and others —rely on DNS. Without DNS, work on the Internet stops, just as surely as it does in the event of a cable cut or routing problem.

Unfortunately, DNS is now an old protocol. It dates to the early 1980s, when the Internet was in its infancy. And while DNS has been tremendously successful at accommodating the exponential growth of the Internet, it was not designed to operate in an environment as hostile as the Internet of today. Consequently, DNS lacks critical security features, such as authentication and integrity checking.

That DNS wasn’t designed with security in mind is evident from the maladies that have afflicted it. Since 1997, when Eugene Kashpureff capitalized on a weakness in the implementation of the BIND name server to poison the caches of name servers around the Internet, we’ve seen an accelerating cycle: New vulnerabilities are found, new patches are released. The two latest vulnerabilities were found in the last two years, within 12 months of each other: In 2007, Amit Klein of Trusteer analyzed the source code of the then-current version of the BIND name server and discovered grave deficiencies in its randomization routines. Those routines are critical to making DNS messages difficult to spoof. And famously, in 2008, Dan Kaminsky developed a technique that could poison the caches of name servers in seconds—even name servers with enhanced randomization routines, patched against Klein’s vulnerability.