To mitigate the long-recognized vulnerabilities in the Domain Name and Addressing System (DNS), the Internet Engineering Task Force (IETF), using the same open standards process employed to develop the core DNS protocols, has developed a set of protocol extensions, called the DNSSEC to protect the Internet from certain DNS-related attacks.
Development of DNSSEC Edit
DNSSEC is designed to support authentication of the source and integrity of information stored in the DNS using public key cryptography and a hierarchy of digital signatures. It is designed to offer protection against forged ("spoofed") DNS data, such as that created by DNS cache poisoning, by providing: (1) validation that DNS data is authentic; (2) assurance of data integrity; and (3) authenticated denial of existence. DNSSEC does not provide any confidentiality for, or encryption of, the DNS data itself. The DNSSEC protocol also does not protect against denial of service (DoS) attacks or other attacks against the name server itself.
The DNSSEC protocol is designed to allow for deployment in discrete zones within the DNS infrastructure without requiring deployment elsewhere, as DNSSEC is an opt-in technology. Signing of any individual zone or domain within the hierarchy does not obligate or force any entity operating a zone elsewhere in the DNS hierarchy to deploy. In addition, end users systems only receive DNSSEC signed information if they request it.
Proponents of DNSSEC assert that widespread deployment of the protocol would mitigate many of the vulnerabilities currently associated with the DNS, increasing the security and integrity of the DNS in a scalable fashion. Ubiquitous deployment of DNSSEC would also enable authentication of the hierarchical relationship between domains to provide the highest levels of assurance. Thus, to realize the greatest benefits from DNSSEC, there needs to be an uninterrupted chain of trust from the zones that choose to deploy DNSSEC back to the root zone.
Ubiquitous deployment of DNSSEC throughout the Internet landscape would require action by a broad range of entities supporting the operation of the DNS infrastructure including, for example, domain name registrars, top level domain (TLD) registry operators and the operators or managers for sub-domains or enterprise networks, Internet service providers (ISPs), software vendors, and others. Additionally, software will need to be developed, servers will need to be configured to support DNSSEC, and users' systems will need to be configured to look for the authenticating signatures.
- ↑ The DNSSEC protocol has been under development since the 1990s with the latest revision approved by the IETF in 2005. RFC 4033 and its companion documents RFCs 4034 and 4035 update, clarify and refine the security extensions previously defined orginally in RFC 2535 and its predecessors. National Research Council, The National Academies, Signposts in Cyberspace: The Domain Name System and Internet Navigation 154 (2005) (Signposts); see also S. Rose and R. Chandramouli, "Challenges in Securing the Domain Name System," at 4 Institute of Electrical and Electronics Engineers (IEEE) Security & Privacy J., Jan./Feb. 2006, at 84. (full-text).
- ↑ R. Arends et al., DNS Security Introduction and Requirements, Internet Engineering Task Force (IETF) Request for Comment (RFC) 4033 (March 2005)(RFC 4033).rfc4033.txt
- ↑ Id.
- ↑ Id. at 6.
- ↑ See Signposts, at 158.
- ↑ See e.g., Challenges, at 86-87. The Department recognizes that the ultimate success of DNSSEC would also require a widespread education campaign among end users and DNSSEC awareness would have to be integrated into application and operating system software and development.