DNS is our trusted guide to the digital world. When we access a server by name, we're trusting DNS to give us the IP address of the correct destination. If our DNS infrastructure is compromised, names might be resolved to malicious hosts, which could capture sensitive information and credentials, distribute misinformation, or just disrupt our access to services.
Today’s infrastructure houses highly sensitive information and forms the backbone of many businesses, so we need something more. Confidence in our DNS infrastructure and the information it provides is crucial to maintaining an organization's security and integrity. With Windows Server 2008 R2, we have some very powerful technologies with which to gain this confidence. Let's start with a little background, then see what new enhancements such as DNS Security Extensions (DNSSEC) can provide.
Traditional DNS Shortcomings
With traditional DNS, clients can perform only basic checks to determine whether DNS responses have been spoofed. A client can check whether the DNS server address matches the expected address; however, this capability is often disabled due to network infrastructure configurations. This check is also easy to fake: The port used in the response needs to match the client request's port, which is easy to guess.
Even with new Server 2008 R2 DNS enhancements to source-port randomization, the risk isn't mitigated so much as the time required for an attack is increased. The random XID value sent by the client (included in the response) is sent in clear text, so it's easy to duplicate. Also, in traditional DNS, the client's query is echoed back, but if a technology is smart enough to capture the request and spoof a response, echoing back the initial response is easy.
There's no checksum within the DNS response—say, to ensure that the content of the response hasn't been altered. So, man-in-the-middle attacks can modify the content as it's transmitted to the client. Also, consider that many of our DNS results don't come from the authoritative DNS server; rather, they come from an in-between DNS server that has a cached lookup and returns the information in the cache. Many hackers poison the cache of DNS servers by bombarding them with false records.
DNSSEC for All
DNS Security Extensions (DNSSEC) isn't a proprietary Microsoft technology but rather an Internet-standard extension to DNS defined in RFCs 4033, 4034, and 4035 that Microsoft has implemented as part of the Server 2008 R2 DNS role. An earlier version of DNSSEC was defined in RFC 2535, but it's been replaced by the aforementioned RFCs and implementations that follow RFC 2535. Windows 2003 Server and even Server 2008 aren't compatible with the Windows 2008 R2 implementation.
At its most basic level, DNSSEC assures the integrity of the DNS infrastructure through technologies that verify the authenticity of received data, including authenticated denial-of-existence responses. Assurance is enabled through public key cryptography, which enables the use of digital signatures on all DNS responses. A successful digital signature validation means that the data received is genuine and can be trusted. The digital signature is generated using the DNS zone's private key (which is kept secret) and the content of the record, and can be validated with the public key. If a packet is generated from a malicious source, its digital signature will fail; if a packet has been modified, the signature will no longer match the content.
Facilitating this public key cryptography are several new DNS record types—specifically, DNS Public Key (DNSKEY), which is a container for a DNS zone's public key; Resource Record Signature (RRSIG), which contains the digital signature of a DNS response; Delegation Signer (DS), which is used between a child and parent zone that are both DNSSEC-enabled; and Next Secure (NSEC), which allows authenticated denial-of-existence records by effectively returning the name that would be prior to the non-existent requested name (if they were in alphabetical order) and notifying what the next secure record would be. For example, if you had records A and E in your DNS zone, and you were asked for record C, the response would be A NSEC E with a signature, thereby notifying you that the asked-for record doesn't exist because there are no records between A and E.
The critical element is the trust. The client must trust the zone's public key because the public key is used to authenticate the response by decrypting the signature, which was created using the private key. Ensuring that clients trust only the “real” authoritative DNS zone owner is achieved through chains of trust.
In an ideal world, this PKI hierarchy would be self-contained in the DNS hierarchy in that the root of DNS—“.”—would be DNSSEC-enabled and globally trusted by all clients, Then, the root could sign the top-level domain names (e.g., com, net, org), which could then sign their subordinate domains (e.g., company.com), thereby creating a trust path. This means that clients would need only to trust the root zone, since the root zone is used to authenticate all the other child zones. In Figure 1's example, .net is DNSSEC-enabled, so any child zone that is signed by the .net parent would be trusted by any DNS client that trusts .net.
Figure 1: Setting the trust anchor