Partager via

DNSSEC Deployment Planning

  • Article

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 support in Windows Server® 2008 R2 is intended as a solution for file-backed static zones and is not intended to be used with dynamic, Active Directory-integrated DNS zones. If a zone is DNSSEC-signed on a DNS server running Windows Server 2008 R2, all types of dynamic updates (secure and non-secure) will be disabled on that zone. DNS zones that contain Active Directory-joined client resource records require dynamic updates for refresh of SRV and other records to function normally. It is recommended that you do not sign these internal, domain zones with DNSSEC on a server running Windows Server 2008 R2.

DNSSEC in Windows Server® 2012 contains significant enhancements, including support for online signing of dynamic DNS zones. Before signing any zone with DNSSEC, it is critical that you understand and carefully consider additional DNSSEC related maintenance requirements.

Deployment stages

A phased approach is recommended when deploying DNSSEC in your organization, as described below. Depending on the complexity of your environment, you might want to limit the initial deployment to a small number of domains before you deploy DNSSEC broadly. For guidance on choosing these zones, see Identify Zones for DNSSEC.

Important

Dynamic updates are not supported for a signed zone. When deploying DNSSEC, choose a zone that contains only static resource records, and can be effectively administered through manual updates.

A summary of the major stages used when deploying DNSSEC is provided below. Allow at least 2-3 days between each stage.

  1. Upgrade DNS servers to Windows Server® 2008 R2.

  2. Identify and sign DNSSEC-protected zones on DNS servers.

  3. Configure and distribute trust anchors.

  4. Configure IPsec policy on the servers.

  5. Configure IPsec and DNSSEC on clients.

If you are not deploying DNSSEC with IPsec, you can ignore stage 4 and the IPsec portion of stage 5 and simply configure DNSSEC. In this model, it is assumed that the channel between the local DNS server and the client is implicit.

Operating system considerations

Hardware and performance

Before you upgrade your DNS servers to Windows Server 2008 R2 and deploy DNSSEC, consider the following factors that affect hardware and performance:

  • Windows Server 2008 R2 is available for 64-bit processors only.

  • A DNS server can consume as much as three to five times the memory of an unsigned zone in order to load a signed zone. Make sure there is enough memory on the DNS server.

  • When responding to queries, the DNS server will respond with additional DNSSEC resource records. This will increase the number of packets on the network and can decrease the maximum query throughput of the DNS server.

  • A DNS server that is performing validation of DNSSEC data can experience an increase in CPU usage. A server authoritative for signed zones will experience a minimal increase unless it is also performing validation on data from other zones. Make sure that the server has sufficient processing capabilities.

  • If large signed zones are hosted in Active Directory Domain Services (AD DS), there can be a significant impact on the size of the Active Directory database file. Verify that all servers that participate in Active Directory replication of the database file have the required disk space.

Hosting signed zones

For file-backed zones, the primary and all secondary DNS servers hosting the zone must running Windows Server 2008 R2 or a DNSSEC-aware server that is running an operating system other than Windows. For Active Directory-integrated zones, every domain controller that is a DNS server in the domain must be running Windows Server 2008 R2 if the signed zone is set to replicate to all DNS servers in the domain. Every domain controller that is a DNS server in the forest must be running Windows Server 2008 R2 if the signed zone is set to replicate to all DNS servers in the forest.

DNSSEC in mixed environments

Windows implementations of DNSSEC will interoperate with older versions of Windows that do not use DNSSEC as well as other operating systems.

The following are guidelines for DNSSEC deployment in a mixed environment:

  • All servers authoritative for a DNSSEC-signed zone must be a DNSSEC-aware server (such as Windows Server 2008 R2).

  • A DNSSEC-aware Windows client that requests DNSSEC data and validation must be configured to issue DNS queries to a DNSSEC-aware and (optionally) IPsec-compatible DNS server that is configured with trust anchors (such as Windows Server 2008 R2).

  • Non-DNSSEC-aware Windows clients can be configured to issue DNS queries to DNSSEC-aware servers.

  • A DNSSEC-aware server can be configured to recurse queries to a non-DNSSEC-aware DNS server.

Key management

Signing securely and securing the private key

Like any other security model relying on public key cryptography, it is imperative that private DNSSEC signing keys are kept secure. By definition, the public key can be made widely available; it does not need to be secured. However, if the private key is compromised, a rogue DNS server can masquerade as the real authoritative server for a signed zone. For this reason, we strongly recommend the following:

  • Make sure that the generation of keys, the storing of the private key, and the signing of zones is performed on a DNS server that physically secure and whose access is restricted to essential personnel only.

  • Store at least one backup copy of the private key on a different computer. For more information about how to perform this backup, see Checklist: Preparing to Deploy DNSSEC. The DNS service must be installed on that computer so that you can access the signing tool using Dnscmd.exe.

Key rollover

DNSSEC keys do not have a permanent lifetime. The chances a key will be compromised, whether through accident, espionage, or cryptanalysis, increase the longer the key is used. Key rollover is the process by which a key is replaced with a new key and associated signatures are updated. We strongly recommend that you familiarize yourselves with the options in RFC 4641 and identify the preferred rollover mechanisms as part of your DNSSEC implementation planning.

RFC 4641 recommends key rollover methods for each key type. The following table describes these methods.

Zone Signing Key (ZSK) rollover

Double Signature

This method involves creating two ZSKs and signing the zone with both ZSKs to generate two sets of signatures for each RRSet.

Advantage:This method can be performed in three steps.

Disadvantage: Performing double signature rollovers will result in the zone size doubling.

Key Pre-publication

This method involves creating two ZSKs. The zone data is signed using one ZSK, but the second key is published in the zone even though no signatures have been generated using it. At a time when key rollover is to be performed, the zone is re-signed using the second ZSK, and both keys are still maintained in the zone so old cached signatures can still be validated using the first ZSK.

Advantages:If the old ZSK is compromised, then administrators can quickly switch to the new, already-published ZSK. And because only one key generates signatures at a time, the size of the zone is not doubled.

Disadvantage:This method is performed in four, rather than three, steps.

Key Signing Key (KSK) rollover

Double Signature

Rollover of the KSK is different from rollover of the ZSK in that the former requires interactions with the parent zone; the latter does not.

The parent zone contains a DS resource record pointing to the KSK of the child zone. When performing a rollover, the new KSK is added to the child zone, but is also provided to the owner of the parent zone. The parent generates a new DS RR pointing to the new KSK of the child. After this data has been propagated to all authoritative parent zones, and after the old DS resource record has been cleared from all caches (max DS record TTL), the old KSK is removed from the child zone.

Advantage: Compared to the Key Pre-publication method, this method requires only one interaction with the parent.

Key Pre-publication

When rollover is performed on the child, the parent is notified and the new KSK is provided to the parent. The parent zone publishes two DS records, one for the old key and one for the new key. As soon as the new DS record has been propagated, the old KSK is replaced with the new KSK. At this point, the old DS record can also be deleted.

Disadvantages:This method requires two interactions with the parent, so it can take more time. In addition, the parent cannot verify the match between the new DS record and the new KSK because the new KSK has not yet been published. This also introduces “security lameness,” a scenario in which the parent has a DS record pointing to a non-existent DNSKEY record. In this case, a validator might mark the child zone as bogus.

Updating parent zones

After a zone is DNSSEC-signed, and if the parent of the zone is also DNSSEC-signed, the signed delegation records must be added to the parent zone and the parent zone must be re-signed. This process must be performed every time a new child zone is signed for the first time, or if a child zone is re-signed with a new key signing key. If you own a signed zone but do not own the children of the zone, and if the children zones are in the process of being DNSSEC-signed one at a time, you must re-sign your zone after adding the delegation records each time a new child zone is signed. However, the process of signing multiple zones can be optimized if you own the parent as well as the children zones that are to be signed.

Trust anchor management

A trust anchor for a signed zone must be configured on every DNS server that will attempt to validate DNS data from that signed zone. As mentioned before, Windows Server 2008 R2 only supports the DNSKEY resource record as a trust anchor. A DNS server performing validation will build a chain of authentication from the trust anchor to the child zones; hence it is sufficient if a trust anchor for a parent zone is present. However in scenarios where islands of trust are present, a trust anchor must be configured for the root of each island. The following diagrams illustrate these scenarios.

The following diagram illustrates a scenario in which some zones (shown in blue) are signed while others are not. The right side of the tree is completely signed; the left side of the tree is intermittently signed. Therefore, for a DNS server to be able to perform DNSSEC validation for all the zones in the example, at a minimum, you must configure trust anchors for the zones in yellow.

You can configure more trust anchors for the other signed zones, but the trust anchors for the zones in yellow are sufficient for full validation of all zones.

Last hop communication

In the context of this document, last hop communication refers to the communication between a DNSSEC-enabled client computer running Windows 7 and its local DNS server.

IPsec is used to secure last hop communication between the client and the DNS server. If you have a domain IPsec policy as part of a server and domain isolation deployment, then you must exempt 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.

Configuring policy on the DNS client

DirectAccess

To enable the DNS client to set the DNSSEC OK bit in queries, you must configure the NRPT with the appropriate polices. Do not configure any settings on the DirectAccess tab unless this remote access technology is deployed in your environment. If DirectAccess is deployed in your environment, contact the DirectAccess administrator to be sure that any DNSSEC policies you create do not conflict with DirectAccess policies.

Advanced settings

When an application uses the GetAddrInfo API or other name resolution APIs to resolve a name, DNS is typically the first protocol that is used to attempt to resolve the name. If DNS fails to successfully resolve the name, and if the query is a flat name, protocols such as Link-Local Multicast Name Resolution Protocol (LLMNR) and NetBIOS are tried.

If DNSSEC is enabled on a client, by default, failover to LLMNR/NetBIOS will occur only if the DNS client receives an authenticated denial of existence response. For any other failure response, the DNS client will not fail over. Although this behavior can be modified so that the client fails over for other failure responses, DNSSEC does not offer security for name resolution provided by other name service providers. Be sure to understand the security risks associated with modifying this setting. It should be changed only when link-local flat name resolution is an absolute necessity.

Policy mismatch between server and client

Make sure there is no mismatch between the policy configured on a client and the trust anchors in the server to which the client issues queries. An application can fail to resolve a name if the DNS client policy on that computer requires DNSSEC for a name, but the DNS server to which queries are issued does not possess the trust anchor for that zone. In this scenario, either the appropriate trust anchor must be added to the DNS server or the policy requiring DNSSEC on the client must be deleted.

See Also

Concepts

Checklist: Preparing to Deploy DNSSEC