Introduction to DNSSEC
Updated: October 7, 2009
Applies To: Windows Server 2008 R2
Tip
This topic applies to DNSSEC in Windows Server 2008 R2. DNSSEC support is greatly enhanced in Windows Server 2012. For more information, see DNSSEC in Windows Server 2012.
What is DNSSEC?
The Domain Name System (DNS) is a hierarchical, distributed database that contains mappings between names and other information, such as IP addresses. DNS allows users to locate resources on the network by converting friendly, human-readable names like www.microsoft.com to IP addresses that computers can connect to.
DNS is a critical infrastructure service that supports the Internet and corporate networks. Users and applications rarely ever attempt to locate other computers directly by IP address; name resolution is performed first instead. Web, e-mail, and instant messaging, applications and technologies like Active Directory Domain Services (AD DS) rely on DNS to perform their operations.
Because DNS does not offer any form of security, it is vulnerable to spoofing, man-in-the-middle and cache poisoning attacks. Attacks of this kind can compromise all future communications to the host. For this reason, it has become critical to develop a means for securing DNS.
Domain Name System Security Extensions (DNSSEC) is a suite of extensions that add security to the DNS protocol. The core DNSSEC extensions are specified in RFCs 4033, 4034, and 4035, with additional RFCs providing supporting information. Specifically, DNSSEC provides origin authority, data integrity, and authenticated denial of existence. In addition to several new concepts and operations for both the DNS server and the DNS client, DNSSEC introduces four new resource records (DNSKEY, RRSIG, NSEC and DS) to DNS. This guide provides an overview of DNSSEC and information about how to deploy DNSSEC on the Windows Server® 2008 R2 and Windows® 7 operating systems.
Note
In Windows Server 2003 and Windows Server® 2008, DNSSEC is implemented on secondary zones as described in RFC 2535. Because RFC 2535 has been made obsolete by the previously mentioned RFCs, the Windows Server 2003 and Windows Server 2008 implementations are not interoperable with the Windows Server 2008 R2 or Windows 7 implementation.
Why is DNSSEC important?
DNSSEC provides the ability for DNS servers and resolvers to trust DNS responses by using digital signatures for validation. All signatures generated are contained within the DNS zone itself in the new resource records. When a resolver issues a query for a name, the accompanying digital signature is returned in the response. Validation of the signature is then performed through the use of a preconfigured trust anchor. Successful validation proves that the data has not been modified or tampered with in any way.
DNS threats and security
Spoofing
Of all malicious attacks, DNS is most vulnerable to spoofing. When any DNS resolver sends a remote query, it tags the query with a 16-bit transaction ID (XID) value in the DNS packet header and expects that the remote DNS server will respond on the same port with the same XID value. The query is typically sent over UDP. TCP is used only after a UDP response has been truncated. When the resolver receives a UDP DNS response, it can only weakly verify that the response is authentic by matching these parameters:
Remote DNS server address. This check is often disabled by default because many network devices make it appear that valid responses come from an address different from the one the query was sent to. This makes the spoofing of a DNS response even easier.
Port on which the packet was received. The resolver will typically send from an ephemeral port to port 53. DNS servers respond from port 53 to the source port used by the requester. The port value is often easy for a malicious user to guess.
Packet XID value. The XID value is set in the request by the resolver and must be matched in the response. A strongly random value can and should be used for the XID, but it is only 16 bits long. The XID value, like the rest of the DNS packet, is sent in the clear.
Query name and type. The DNS server echoes the query name and type in the question section of the DNS response.
If a malicious user does not have access to a DNS client or server’s network traffic, he might be able to guess that a DNS client or server has sent a DNS query and is waiting for a DNS response. When he has determined this to be true, the attacker can send one or more spoofed DNS response packets and attempt to beat the authentic response back to the requester. As the following figure illustrates, a malicious user can attack DNS clients and DNS servers that send remote DNS queries.
.gif)
DNS client and server implementations will typically discard non-matching responses and continue to wait for a matching response. This makes it easy for the malicious user to submit multiple spoofed responses. If the DNS resolver receives the malicious user’s response before the authentic response, and if all of the previously described properties have the expected values, then the malicious user will have successfully spoofed the DNS client or server. The user can insert any DNS data of his choosing into the response for the queried name and type. For example, the malicious user can place the IP address of his own server in a spoofed response to a query for www.microsoft.com or for the Web site of a bank or online merchant. Obviously, the results can be catastrophic.
The malicious user can increase his odds of success by sending many spoofed UDP response packets, each with different XID values. For example, if the user is able to hit a DNS client or server with 100 spoofed response packets with different XIDs, in the time it takes the authentic DNS server to respond, the odds his response will be accepted as authentic are 100/65535 or approximately 0.15%. If the user has the time and bandwidth to send 1,000 spoofed responses, the odds increase to 1.5%. If the DNS implementation uses predictable XIDs, the odds greatly increase. Given the fact that the malicious user will have many opportunities to retry his attack as DNS cached entries expire, over time it is not difficult for a patient attacker to spoof DNS clients or servers. Because the attacker controls the Time-to-Live (TTL) value on his spoofed data, a successful attack can persist for days, weeks, or even longer.
Data integrity
Because DNS does not provide any sort of data integrity, it is possible for a man-in-the-middle attacker to modify DNS requests or responses. For example, a man-in-the-middle attacker can rewrite the entire answer section of a DNS response packet. DNS clients and servers cannot detect that this data modification has occurred.
Mutual authentication
DNS does not provide a way for a resolver to know that it is communicating with an appropriate DNS server, or for the DNS server to discover the identity of its clients. The Microsoft implementation of the DNS dynamic update protocol does provide mutual authentication by signing DNS update packets, but this mechanism does not extend to DNS queries. In its current form, it is suitable for use in enterprise environments only.
Privacy
DNS does not provide any mechanism for the encryption of DNS queries and responses. A traditional authoritative DNS server will not typically allow a client to perform any sort of trivial enumeration of the nodes and data within its zones. If an attacker wants to know which hosts are present in a zone, this data is not readily available. The attacker is forced to guess, either at DNS names or IP addresses.
DNS pinning or rebinding attacks
These attacks exploit the way in which applications (specifically, browsers and their plug-ins) consume DNS entries that have multiple IP addresses associated with them. DNSSEC does not address this vulnerability.