DNS Security Extensions (DNSSEC)
Published: October 21, 2009
Support for Domain Name System Security Extensions (DNSSEC) is introduced in Windows Server® 2008 R2 and Windows® 7. With Windows Server 2008 R2 DNS server, you can now sign and host DNSSEC-signed zones to provide security for your DNS infrastructure.
The following changes are available in DNS server in Windows Server 2008 R2:
Ability to sign a zone and host signed zones.
Support for changes to the DNSSEC protocol.
Support for DNSKEY, RRSIG, NSEC, and DS resource records.
The following changes are available in DNS client in Windows 7:
Ability to indicate knowledge of DNSSEC in queries.
Ability to process the DNSKEY, RRSIG, NSEC, and DS resource records.
Ability to check whether the DNS server with which it communicated has performed validation on the client’s behalf.
The DNS client’s behavior with respect to DNSSEC is controlled through the Name Resolution Policy Table (NRPT), which stores settings that define the DNS client’s behavior. The NRPT is typically managed through Group Policy.
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 and add origin authority, data integrity, and authenticated denial of existence to DNS. 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.
In short, DNSSEC allows for a DNS zone and all the records in the zone to be cryptographically signed. When a DNS server hosting a signed zone receives a query, it returns the digital signatures in addition to the records queried for. A resolver or another server can obtain the public key of the public/private key pair and validate that the responses are authentic and have not been tampered with. In order to do so, the resolver or server must be configured with a trust anchor for the signed zone, or for a parent of the signed zone.
This feature will be of interest to IT professionals who manage Active Directory® Domain Services (AD DS) and DNS, as well as to security administrators. Specifically, this feature will be of interest to all administrators of U.S. federal IT systems who must be compliant with National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53.
The DNSSEC implementation in Windows Server 2008 R2 DNS server provides the ability to sign both file-backed and Active Directory–-integrated zones through an offline zone signing tool. This signed zone will then replicate or zone-transfer to other authoritative DNS servers. When configured with a trust anchor, a DNS server is capable of performing DNSSEC validation on responses received on behalf of the client.
The DNS client in Windows Server 2008 R2 and Windows® 7 is a non-validating security-aware stub resolver. This means that the DNS client will offload the validation responsibilities to its local DNS server, but the client is capable of consuming DNSSEC responses. The DNS client’s behavior is controlled by a policy that determines whether the client should check for validation results for names within a given namespace. The client will return the results of the query to the application only if validation has been successfully performed by the server.
As DNS security threats become more topical, it is important to realize that securing the DNS is critical to securing enterprise networks and the Internet. DNS is often subject to man-in-the-middle, spoofing, and cache-poisoning attacks that are hard to defend against. DNSSEC is the best available solution that helps protects against these security threats against DNS. DNSSEC will be the technology of choice for enterprises, registrars, and ISPs as they look for ways to secure their DNS deployments.
Last hop communication refers to the communication between a DNSSEC-enabled client computer running Windows 7 and its local DNS server. We strongly recommend the use of Internet Protocol security (IPsec) to secure last hop communication between the client and the DNS server, but keep the following deployment considerations mind:
DNSSEC uses Secure Sockets Layer (SSL) to ensure that client-to-server communication is secure. The use of SSL allows the DNS client to check that the server has a certificate that proves its identity as a valid DNS server. This adds an additional level of trust between the client and the server.
If you have a domain IPsec policy as part of a server and domain isolation deployment, then you must exempt TCP/UDP port 53 traffic (DNS traffic) from the domain IPsec policy. Otherwise, the domain IPsec policy will be used and certificate-based authentication will not be performed. The client will fail the EKU validation and will not trust the DNS server.
We recommend that you review your DNS infrastructure to identify the zones that must be secured with DNSSEC. After you have identified the zones, review the instructions in Deploying DNS Security Extensions (DNSSEC) to understand deployment requirements and considerations.
This feature is available in all editions.