Securing the Root: What is DNSSEC, what's the controversy?

[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:

  • Integrity verification: a DNS resolver can determine that information received from a nameserver has not been tampered with in transit
  • Source authentication: a DNS resolver can determine that the information received originated from an authoritative nameserver
  • Authenticated denial of existence: a DNS resolver can verify that a particular query is unresolvable because no DNS record actually exists on the authoritative nameserver
  • 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:

  • A DNSSEC-enabled nameserver for a particular zone[1] will store a Signature Resource Record (RRSIG) for the various sets of records it hosts. For example, it will contain the signed set of A records (RRSIG(A)), which point domain names to unique IP addresses. The RRSIG is a digital signature created by taking a hash of a zone's particular resource record set which is then encrypted using the private portion of a zone administrator's cryptographic key set.
  • The corresponding public portion of this key set is stored in the DNSKEY Resource Record. When receiving a signed DNS response from a nameserver, a DNSSEC-aware resolver will decipher the appropriate RRSIG set using the zone's DNSKEY. It will compare the now exposed resource record set hash against a generated hash of the nameservers unsigned resource record set, and thus be able to confirm or deny the integrity and origin authenticity of various information types.
  • How does a resolver know the authentic DNSKEY for a particular zone? The Delegation Signer (DS) Resource Record is served by the parent zone and creates an authenticable delegation point between parent and child zones. To validate a child zone's DNSKEY, a resolver retrieves the associated DS, RRSIG(DS) and DNSKEY of the parent zone. The DS is validated against the deciphered RRSIG(DS), and then the DS data is used to authenticate the DNSKEY of the child zone. In a sense, the signed DS acts like a certificate which binds a child zone to its DNSKEY and is authoritatively served from the parent zone. A series of these delegation relationships forms an authentication chain, which form a path a resolver can follow right from the DNS root's key (aka a trust anchor). [OK, well if parent zones vouch for child zones' DNSKEYs, who vouches for the root's key? Ah, now were starting to see the policy issues…]
  • Finally, the Next Secure (NSEC) Resource Record chains signed records together, allowing a resolver to traverse a zone file and determine if a particular host name does not exist in the DNS.
  • 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)

    [1] 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.


    One comment

    1. Anonymous

      Over on the DNSSEC deployment list (http://mail.shinkuro.com:8100/Lists/dnssec-deployment/Message/702.html?Language=), Dan Mahoney posted:

      “So I (a .org user) was once again looking at pir.org to find out where they stand on DNSSEC, and it looks like it's going to be a long, uphill battle.
      On http://pir.org/Strengthening/DNSSec.aspx, Paragraph 7,
      Quote:
      In addition, the implementation challenges for DNSSEC are not trivial. Success depends on sufficient interest, capital outlay and the integration of DNSSEC support in DNS resolvers all over the world. After all, if a zone is signed and is available only to applications that can recognize and authenticate the signature, any application that attempted to access the domain or Web site without the ability to perform this authentication would fail. All legacy applications (i.e., Windows 95, old browsers and old e-mail applications) would have to be either upgraded or discarded in such a situation.
      End Quote
      Is it me or did whomever wrote that REALLY not understand how DNSSEC works?
      A DNSSEC zone contains all the same records as its unsigned counterpart, and the additional signature information won't be sent along unless asked for.”

      The point here is that a significant hurdle for any new technical standard is whether or not it is backward compatible. This is because there can be major switching costs involved in adoption. DNSSEC was designed to be backward compatible, secured nameservers will continue to resolve requests from resolvers which are not security aware. Although that does not mean there aren't other costs that registries could incur in deploying the technology.