Understanding DNSSEC in Windows

Article
06/18/2014

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.

DNSSEC in Windows Server 2008 R2

Offline signing of static zones

The DNS server command-line management tool (Dnscmd.exe) offers offline key generation and zone-signing capability through a signing tool. RSA/SHA-1 is the supported algorithm. Supported key lengths are from 512 bits to 4096 bits.

The signing tool generates keys that will be stored in certificates, an example of which would be a self-signed certificate in the computer store.

In order to sign a zone, the zone data from a file-backed or an Active Directory-integrated zone must be copied to a temporary file. The zone signing tool consumes this file as the input and generates a signed zone file as the output. The signed zone file contains the additional RRSIG, DNSKEY, DS, and NSEC resource records for data in the zone. This signed zone must then be reloaded on the DNS server in order for the server to host the zone. You can reload the signed zone by using Dnscmd.exe or DNS Manager.

The zone signing tool also allows for key rollover either by pre-publishing keys or by generating two sets of signatures (one for the key being retired, one for the new key).

Dynamic updates are automatically disabled on a DNSSEC-signed zone. Windows Server® 2008 R2 DNS server supports the signing of static zones only. You must use Dnscmd.exe or DNS Manager to add more resource records to a zone and the zone must be re-signed.

Important

Secure dynamic update is a feature introduced in Windows Server 2000 that is used by DNS clients to register and dynamically update their resource records with a DNS server whenever changes occur. This feature should not be confused with DNSSEC. After a zone is DNSSEC-signed, all mechanisms of dynamic updates (secure and non-secure) will be disabled on that zone.

Configuration of trust anchors

A trust anchor is a preconfigured public key associated with a specific zone. Windows Server 2008 R2 supports the configuration of trust anchors by using DNSKEY resource records.

A validating DNS server must be configured with one or more trust anchors in order to perform validation. At least one trust anchor is required if any DNSSEC data is to be validated by the DNS server. Additional trust anchors can be deployed to support islands of trust. DNS server management tools (DNS Manager and Dnscmd.exe) can be used to locally or remotely view and modify trust anchors. Trust anchors apply only to the zone for which they are configured.

If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and will be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns in %windir%\System32\DNS.

Validation

The DNS server will perform validation for a name as long as the trust anchor for the zone or for a parent zone is present, no matter if the client issuing the query indicates knowledge of DNSSEC. This behavior of the DNS server ensures that DNSSEC-unaware clients are protected.

Forwarding and recursion

Non-authoritative DNS servers are typically configured to either forward queries to other DNS servers or to recurse queries to the Internet root servers. A Windows Server 2008 R2 DNS server deployed as a forwarder or a recurser will retrieve the additional resource records required to perform DNSSEC validation based on configured trust anchors and will validate responses received.

Zone transfers

Zone transfers of a DNSSEC-signed zone function in the same way they do for an unsigned zone. All of the resource records, including DNSSEC resource records, are transferred from the primary server to the secondary servers with no additional setup requirements.

A Windows Server 2008 R2 DNS server can also be configured as a secondary server for a DNSSEC-signed zone with the primary hosted on a DNS server running an operating system other than Windows.

Active Directory-integrated zones and Active Directory replication

A DNSSEC-signed zone stored in AD DS will continue to replicate to other DNS servers in the forest or the domain (as configured) in the same way it does for a zone that is not DNSSEC-signed.

Managing DNSSEC through Dnscmd.exe and DNS Manager

All DNSSEC tasks can be performed by using the Dnscmd.exe command-line tool. This allows you to script common DNSSEC operations, such as re-signing a zone.

You can use the graphical user interface, DNS Manager, to view DNSSEC-signed zones. DNS Manager also allows you to view and edit trust anchors. However, you cannot use DNS Manager to generate keys or sign a zone. These operations can only be performed by using Dnscmd.exe.

Flat-name resolution

The signing of the GlobalNames Zone and WINS forwarding are not supported in Windows Server 2008 R2.

DNSSEC in Windows Server 2008 R2 and Windows 7

Non-validating security-aware stub resolver

The DNS client service is included in every version of the Windows operating system, no matter if the computer is also a DNS server.

The Windows DNS client is a stub resolver, which means it always issues recursive queries to the DNS servers configured on its network interfaces (hereafter referred to as local DNS servers). With the implementation of DNSSEC, the client remains a stub resolver.

The DNS client is now security-aware, which means that when issuing queries, the DNS client can indicate to the local DNS server that it understands DNSSEC by setting the DNSSEC OK bit in queries. The client can also process the new DNSSEC resource records in addition to the DNSSEC EDNS0 bits in responses.

However, the DNS client is non-validating, which means it does not perform DNSSEC validation; it relies on its local DNS servers for validation instead. If the local DNS server indicates the successful validation of the name, the DNS client returns the name resolution results to the application. If the server failed validation, the client will not return the results to the application.

The setting of the DNSSEC OK bit and checking for validation in the response are operations controlled through policy stored in the Name Resolution Policy Table (NRPT), which is described in the following section.

Because the DNS client relies on its local DNS server for DNSSEC, the client must be able to trust the local DNS server. For more information about the way IPsec is used to establish this trust relationship, see DNSSEC Deployment Planning.

To deploy DNSSEC with IPsec, the local DNS servers must be IPsec-compatible DNSSEC-aware servers, such as Windows Server 2008 R2 DNS server.

The Name Resolution Policy Table (NRPT)

The NRPT is a new feature in Windows Server 2008 R2 used to specify special DNS settings for names or namespaces. For information about configuring the NRPT see Appendix B: The Name Resolution Policy Table (NRPT).

Securing server-to-client communication

Because the Windows DNS client is a non-validating resolver that relies on its local DNS server for DNSSEC validation, the client must be able to establish a trust relationship with the local DNS server. IPsec is used to establish this trust relationship. See the following figure.

Certificates

Certificate-based authentication is used to establish an IPsec session between the client and the server. Each endpoint must present a certificate to prove its identity. The client can use its domain certificate, but the server must use a special certificate that contains an enhanced key usage (EKU) that proves the server’s identity as a DNS server. This certificate must be created and configured on all local DNS servers.

In order to validate the server’s certificate, the client computer must also trust the certification authority (CA) that is used to issue the server’s certificate.

Warning

Certificate authentication is optional in the NRPT and is ignored when you configure certificate requirements in IPsec connection security rules.

IPsec policy

Matching IPsec policy must be configured on both the server and the client. The use of encryption is optional. Enable client IPsec policy using the NRPT, and by configuring IPsec connection security rules. Server IPsec policy is configured only using connection security rules.

NSEC and NSEC3

Next Secure (NSEC) is a method to provide authenticated denial of existence for DNS resource records. NSEC3 is an update that has the additional benefit of preventing “zone walking,” which is the process of repeating NSEC queries to retrieve all of the names in a zone. Servers running Windows Server 2008 R2 can host DNS zones that are signed with NSEC only.

Support for NSEC3 in Windows Server 2008 R2 and Windows 7 is limited to the following scenarios:

Windows Server 2008 R2 can host a zone signed with NSEC that has NSEC3 delegations. In this scenario, the NSEC3-signed child zones are not hosted on Microsoft DNS servers.
Windows Server 2008 R2 can be a non-authoritative DNS server configured with the trust anchor for a zone that is signed with NSEC and has NSEC3 child zones. In this scenario, the DNS server will be able to validate data from the NSEC-signed parent and will treat data from the NSEC3-signed child zones as insecure.
Clients running Windows 7 can use a non-Microsoft DNS server for DNS resolution that is aware of NSEC3. Use IPsec in this scenario to secure the channel between the client and server.
If a zone is signed with NSEC3, configure DNSSEC settings in the NRPT to not require validation for the zone. In this scenario, the Windows Server 2008 R2 DNS server will not perform validation and will return the response with the AD bit clear.

The following scenarios are not supported:

You cannot sign or host a zone that is signed with NSEC3 using a DNS server running Windows Server 2008 R2.
Client computers running Windows 7 cannot perform DNSSEC validation on data from a zone that has been signed with NSEC3.
You cannot configure a trust anchor on a DNS server running Windows Server 2008 R2 for a zone signed with NSEC3.
Configuring a server running Windows Server 2008 R2 as a secondary DNS server for a zone that is signed with NSEC3 is not recommended.

Share via