Domain Name System Security Extensions - Overview

Overview

The original design of the Domain Name System (DNS) did not include security; instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.

DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties). Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in IETF RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.

The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete.

It is widely believed that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered by several difficulties:

• The need to design a backward-compatible standard that can scale to the size of the Internet
• Prevention of "zone enumeration" (see below) where desired
• Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
• Disagreement among implementers over who should own the top-level domain root keys
• Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating (but DNSSEC-aware) stub resolver. For the non-validating stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question (which is usually controlled by the Internet Service Provider) and the communication channels between itself and those name servers, using methods such as IPsec, SIG(0), or TSIG. The use of IPsec is not widespread.