[Editor's note: Below is an overview of DNSSEC written for a non-technical audience, however, it assumes some basic knowledge of the Domain Name System (DNS) and public-key cryptography concepts. The point is to provide enough detail to allow us to understand how chosen technology and institutional design creates Internet governance dilemmas. If there is technical blunder, my apologies – by all means let me know. Clear concepts are a baseline for productive debate. And as I said previously, see the actual specifications (RFC 4033, 4034, 4035) or other reference material, e.g., Geoff Huston's article series or Ron Aithchison's work for more detailed technical explanations. Looking forward to your comments.]
What is DNSSEC?
DNSSEC is a proposed Internet standard that modifies DNS resource records and protocols to provide security for query and response transactions made between domain name resolvers and nameservers. Specifically, the security DNSSEC provides includes:
How does DNSSEC improve Internet security?
DNSSEC is intended to protect against some DNS attacks, including spoofing attacks which use “man-in-the-middle” techniques like packet interception, transaction ID guessing and query prediction, and DNS cache poisoning techniques like name chaining and transaction ID prediction. These attacks (e.g., this 2005 attack) can be exploited to redirect resolver requests to bogus hosts, where other disruptive or criminal acts, like data phishing and malware infections can occur which threaten security. While various types of DNS attacks have increased, data which quantifies the risk and associated damage of attacks that could be prevented by DNSSEC is not widely known, leaving many questions unanswered. Importantly, DNSSEC does not address other well-known DNS vulnerabilities like distributed denial of service (DDoS) attacks. Likewise, DNSSEC provides little defense against basic phishing attacks for which success is largely dependent on end-user behavior.
How does DNSSEC work?
DNSSEC accomplishes the above by introducing public-key cryptographic signed data into the DNS using four new additional resource records:
OK, all this seems useful for improving Internet security, what's the holdup?
Despite widespread belief that remedying security vulnerabilities in the DNS would be beneficial, the development and deployment of the DNSSEC protocol has taken an extraordinary amount of time. The specification was first developed in the mid 1990s, several years after security vulnerabilities in the DNS initially became publicly known and discussed within the Internet Engineering Task Force (IETF). It was first published as a RFC in 1997. In 2001, substantial changes were proposed to the specification and it was re-written between 2001 and 2005. Finally, in March 2005, the revised specification was approved by the Internet Engineering Steering Group (IESG) and published in three separate RFCs covering requirements, additional resources, and protocol modifications. The delay in development is partially attributable to the technical and organizational complexity of the protocol, the economics associated with its implementation, and controversy over the purpose of a secure DNS.
By any measure, the DNS has been an incredibly reliable and effective globally distributed lookup directory, resolving billions of queries each day and facilitating US billions in worldwide Internet commerce in 2005. This success places a heavy burden of proof on any new proposals that add complexity by changing the underlying technology and processes. DNSSEC is not a simple protocol, it requires the development of upgraded or new software and imposes an additional computational burden on the resolver and nameserver infrastructure. The use of digital signatures introduces the need for methods and organizational security policies pertaining to key generation (e.g., algorithm, length), distribution, storage, and scheduled or emergency rollovers. These issues are particularly important for zones higher in an authentication chain.
But it is not simply a question of technical or procedural accomplishment. DNSSEC faces a classic chicken-and-egg adoption conundrum. Without a critical mass of signed zones (and particularly .com and the root), there is no need to develop security aware applications. On the other hand, without applications there is no need to deploy signed zones. Faced with this uncertainty, the larger or more critical zones (e.g., .com) are thoughtfully considering the associated costs of deployment and operation of DNSSEC which could be significant. Furthermore, the type and number of organizations affected has expanded. Originally, enterprises, universities and government agencies were largely responsible for operating their own nameservers. Today a whole industry sector has developed around managed DNS services.
Another contentious issue potentially influencing the evolution of DNSSEC is the protocol's ability to enable widespread encrypted communications, which has long been of concern to law enforcement and surveillance interests. While the protocol itself specifically does not address confidentiality of data or communications, it is recognized that the adoption of DNSSEC could create a globally accessible, authenticatable infrastructure for the secure distribution of other information. In fact, engineers working for the main US government contractor on DNSSEC were cognizant of this benefit early on, viewing it as a potential “big driver behind DNS security.” A secure DNS could contribute to resolving long-standing problems in public-key and certificate distribution, facilitating communications privacy using popular encryption systems such as SSH or PGP.
Next up: The root of the problem, creating a trust anchor(s)
 A zone is an administratively determined section or “cut” of the domain name space. For example, .com, .edu and .se are three top level domain (TLD) zones; companyA.com is a second level domain zone in the DNS. A zone is served by one or more nameservers, i.e., a host machine which maintains DNS information for zero or more zones. In addition, for each zone, there exists a single authoritative DNS nameserver which hosts the original zone data, although this nameserver is typically mirrored in several locations. For TLD zones, the primary master server which hosts the root (“.”) zone file is authoritative. It is mirrored by root zone operators around the world.