DNS Servers

Applies To: Windows Server 2012 R2, Windows Server 2012

If a zone is signed with DNSSEC and validation is required, DNSSEC must be supported by each DNS server that is involved in the process of a DNS query and response. This support creates a chain of trust that enables DNSSEC data to be passed from the authoritative DNS server that hosts a signed zone to other DNS servers that can verify this data and thus validate that DNS responses are genuine. DNS clients are protected against spoofing attacks when they receive this validated response.

To enable DNSSEC and the chain of trust:

• Primary authoritative DNS servers must support zone signing.

• Primary and secondary authoritative DNS servers must support hosting of signed zones.

• Recursive or forwarding DNS servers must support DNSSEC validation of DNS responses.

DNS clients that are security-aware can also be configured to require that DNSSEC validation be performed. Clients that are not security-aware or that do not require validation can still be protected with DNSSEC. For more information, see DNS Clients.

In this section

• DNSSEC support in Windows Server

  • DNSSEC mixed-mode deployment

  • WINS lookup for signed zones

• DNSSEC in Windows Server 2012

  • Online signing and dynamic updates

  • Read-only domain controllers (RODCs)

  • DNSSEC in DNS Manager

  • The Key Master

    • Transferring the Key Master role

    • Seizing the Key Master role

• DNSSEC standards

• Zone transfers

DNSSEC support in Windows Server

DNSSEC support in Windows Server is greatly improved in Windows Server 2012 and Windows Server 2012 R2.

The following table provides a summary of DNSSEC support in Windows Server operating systems.

Note: The DNS client in Windows 7, Windows Server 2008 R2 and later versions of Windows is a non-validating DNSSEC-aware stub resolver. Earlier versions of the Windows DNS Client were not DNSSEC-aware. For more information about DNSSEC and DNS clients, see the DNS Clients topic in this guide.

For detailed information about DNSSEC in Windows Server 2008 R2, see Deploying DNS Security Extensions (DNSSEC) in the Secure DNS Deployment Guide for Windows Server 2008 R2.

DNSSEC mixed-mode deployment

To support staged migration, you can deploy DNSSEC in a mixed environment with some DNS servers running Windows Server 2008 R2 and other DNS servers running Windows Server 2012 or a later operating system.

The following specifications apply to mixed-mode deployments:

• Updated DNSSEC standards (ex: NSEC3) that are available in Windows Server 2012 and Windows Server 2012 R2 are incompatible with DNS servers running Windows Server 2008 R2. As a result, servers running Windows Server 2008 R2 will load zones that are signed on Windows Server 2012 as unsigned zones.

• Zones that are signed on (legacy) DNS servers running Windows Server 2008 R2 are compatible with some DNSSEC operations on (current) DNS servers running Windows Server 2012 or a later operating system. DNSSEC-related resource records (ex: RRSIG, DNSKEY) in these zones will be loaded on current DNS servers and the zones will be capable of DNSSEC validation. However, the zone will not appear to be signed in DNS Manager or using current Windows PowerShell cmdlets.

• A zone that is signed on Windows Server 2008 R2 cannot be unsigned on a server running Windows Server 2012 or a later operating system using the Invoke-DnsServerZoneUnsign cmdlet or the DNS Manager console. To unsign a zone that was signed on a legacy DNS server, you must use legacy procedures. These procedures can be performed on a current DNS server or a legacy DNS server.

• Trust anchors that are created on legacy DNS servers can be imported and will be displayed on current DNS servers using the DNS Manager console or Windows PowerShell. The format of trust anchors is the same in both legacy and current operating systems.

WINS lookup for signed zones

You can configure a DNS server to use Windows Internet Name Service (WINS) to look up names that are not found in DNS by checking the NetBIOS namespace.

To use WINS lookup integration, two special resource record types—the WINS and WINS-R resource records—are enabled and added to a zone. When the WINS resource record is used, DNS queries that fail to find a matched host (A) resource record in the zone are forwarded to WINS servers that are configured in the WINS resource record. For reverse lookup zones, the WINS-R resource record can be enabled and used to provide a similar benefit for further resolving a reverse DNS query that is not found.

In Windows Server 2008 R2, WINS lookup was disabled for DNSSEC-signed zones. For unsigned zones, the WINS tab is displayed in DNS Manager when you view properties of the zone. See the following example.

If a zone was signed, WINS lookup was disabled, and the WINS tab was not displayed.

In Windows Server 2012 and later operating systems, WINS forwarding is enabled for signed zones. If you select the Use WINS forward lookup check box to enable WINS lookup on a signed zone, a warning message appears. See the following example.

A similar message is displayed if you attempt to sign a zone that previously has had WINS lookup enabled. Warning messages are also displayed when you attempt to sign a zone with Windows PowerShell that has WINS lookup enabled.

In summary, WINS lookups are available for both signed and unsigned zones on Windows Server 2012 or later, but WINS lookup is not tamper-proof and constitutes a security risk if it is enabled for a DNSSEC-signed zone.

DNSSEC in Windows Server 2012

Windows Server 2012 and Windows Server 2012 R2 provide many enhancements over Windows Server 2008 R2 that simplify DNSSEC deployment and administration, including online signing of dynamic, Active Directory-integrated DNS zones, Windows PowerShell support, and wizards that are integrated into the DNS Manager console. These key DNSSEC-related features are described in this topic and summarized in the table below.

The following table provides a summary of new DNSSEC features in Windows Server 2012.

Online signing and dynamic updates

Support for DNSSEC zone signing was added with Windows Server® 2008 R2, and subsequently extended in Windows Server 2012 to support online signing.

DNSSEC in Windows Server 2008 R2

In Windows Server 2008 R2, DNSSEC-signed zones could only be signed offline, over a file-based copy of the zone. It was not possible to generate or update signatures on a zone while the zone was online. Nearly all configuration required manual administration, which included the following operations:

• You could only generate the keys required to sign a zone manually by using the dnscmd tool. Although it is recommended that a zone be signed with both a KSK and a ZSK, the keys had to be generated one at a time.

• There was no built-in provision to generate additional keys automatically for rollovers. You were required to plan the type of rollover that you wanted in advance, and then generate keys manually.

• Dnscmd required several inputs to generate keys and assumed no defaults. In some cases, you had to specify the option even though there was only one available – such as algorithm (the only supported algorithm was RSA/SHA-1).

• Zone signing was also a manual operation through dnscmd and was performed over a file copy of the zone offline. You then had to manually import this signed file copy of the zone to the server.

• Windows Server 2008 R2 supported signing Active Directory-integrated zones, but a signed zone could not have dynamic updates enabled. You were required to manually re-sign a zone whenever an update was made to the zone.

• There was no provision to replicate or distribute private keys. Keys were stored in the machine certificate store on the computer where they were generated. They could not be easily exported to other DNS servers.

DNSSEC in Windows Server 2012 and Windows Server 2012 R2

In Windows Server 2012 and later operating systems, DNSSEC support is enhanced to include online signing of dynamic zones. In addition, multiple zone management tasks are automated:

• Signing keys are generated automatically by DNS Manager or Windows PowerShell when parameters have been specified. You can also choose a default parameter set.

• For each signing key, the administrator can enable or disable automatic key rollover at a specified frequency.

• DNS Manager or Windows PowerShell can be used to sign a zone using default values or using custom values. If the zone was previously signed, you can also choose to re-use these parameter values. DNS Manager also provides the option of signing a zone using the same values that were used to sign another zone.

• Zone signing is now performed on active, online zones. There is no need to take a zone offline for signing, and then import a signed copy of the zone after signing is complete.

• If a zone is updated, it is automatically re-signed. Updates to signed zones can be performed manually or dynamically. Dynamic updates are no longer disabled for DNSSEC-signed zones.

• For Active Directory-integrated zones, signing keys are automatically replicated to all primary authoritative DNS servers.

DNS in Windows Server 2012 and Windows Server 2012 R2 also includes a DNSSEC wizard in DNS Manager, which walks an administrator through the signing and unsigning process. The wizard generates all keys that are necessary to sign a zone automatically. For more information, see DNSSEC in DNS Manager.

For Active Directory-integrated zones, private zone signing keys replicate automatically to all primary DNS servers through Active Directory replication. Each authoritative server signs its own copy of the zone when it receives the key. For optimal performance, and to prevent increasing the size of the Active Directory database file, the signed copy of the zone remains in memory for Active Directory-integrated zones. A DNSSEC-signed zone is only committed to disk for file-backed zones. Secondary DNS servers pull a full copy of the zone, including signatures, from the primary DNS server.

In general, cryptographic operations are computationally expensive. For large zones, the DNS server can take several minutes to sign the zone depending on the key length and size of the zone. To prevent performance degradation from occurring when all DNS servers start to sign the zone at the same time, signing is staggered. When a replica domain controller sees the DNSSEC keys and configuration, it waits for a random period between 5 minutes and 30 minutes before it begins signing the zone.

Read-only domain controllers (RODCs)

In Windows Server 2008 and Windows Server 2008 R2, DNS servers running on read-only domain controllers (RODCs) host Active Directory-integrated copies of all zones. However, because the zone is read-only, the DNS server cannot make any updates to the zones that it hosts. Instead, updates occur on other DNS servers and are transferred to the RODC through Active Directory replication.

When an Active Directory-integrated zone is signed with DNSSEC, private keys are also replicated to all DNS servers running on domain controllers, with an exception: Private keys are not replicated to an RODC because RODCs are intended to operate in insecure environments.

In Windows Server 2012 and Windows Server 2012 R2, an RODC loads unsigned zones from Active Directory with no change in functionality from Windows Server 2008 R2. However, if the RODC finds a DNSSEC-signed zone in Active Directory, it does not load the zone as Active Directory-integrated. Instead, it creates a secondary copy of the zone, and then configures the closest writeable domain controller for the domain as the primary server. The RODC then attempts to perform a zone transfer. Zone transfers must be enabled on the primary DNS server for this transfer to succeed. If zone transfers are not enabled, the RODC logs an error event and takes no further action. In this scenario, you must manually enable zone transfers on the primary server that is selected by the RODC. Alternately, you can choose to reconfigure the RODC to point to a different primary DNS server that has zone transfers enabled.

DNSSEC in DNS Manager

DNS Manager in Windows Server 2012 and Windows Server 2012 R2 includes wizards to help you sign zones with DNSSEC, to view and edit DNSSEC parameters, and to easily unsign a zone.

The DNSSEC status of a zone is displayed in the console tree with a lock icon displayed next to the name of the zone if it is signed with DNSSEC. A signed zone also displays a status of Signed in the right-hand pane in the DNSSEC Status column and the name of the The Key Master is shown in the corresponding column. See the following example.

If you recently signed the zone, you might have to refresh the DNS Manager console view to see the DNSSEC-signed status of a zone.

You can also right-click the zone in DNS Manager and point to DNSSEC. If the zone is not yet signed, the only choice available is Sign the Zone. See the following example.

For information about signing and unsigning a zone, see DNS Zones.

The Key Master

The DNSSEC Key Master is a new concept and component of a Windows DNSSEC deployment that was introduced in Windows Server 2012.

In Windows DNSSEC, the Key Master is the DNS server that is responsible for key generation and key management for a DNSSEC-signed zone. When you use default settings to sign a zone, the local server is selected as Key Master. You also have the option of choosing a different DNS server from a list of servers that support online DNSSEC signing. Only one DNS server can be the Key Master for a given zone at a given time.

The Key Master must be a primary, authoritative server for the zone and must be capable of online zone signing. However, in a Microsoft multi-master DNS deployment environment, the following is possible:

• The Key Master role can be transferred to a different authoritative name server after zone signing. This transfer can be performed gracefully if the current Key Master is online, or it can be performed as part of a disaster recovery scenario if the current Key Master is offline. For more information, see Transferring the Key Master role and Seizing the Key Master role later in this topic.

• One authoritative server can be the Key Master for multiple zones.

• Different authoritative servers can be Key Masters for different zones.

You cannot transfer the Key Master role if a zone is file-backed, because these zones have only one primary, authoritative DNS server.

The name of the Key Master is displayed in DNS Manager when you click Forward Lookup Zones or Reverse Lookup Zones, and it is displayed on the Key Master tab of the DNSSEC properties page. You can also use the Get-DnsServerDnsSecZoneSetting Windows PowerShell cmdlet to view the Key Master. See the following example:

PS C:\> Get-DnsServerDnsSecZoneSetting -ZoneName secure.contoso.com | Select KeyMasterServer

KeyMasterServer
---------------
DC1.contoso.com

The Key Master generates all keys for the zone, and is responsible for distribution of private keys and zone signing information. The Key Master is also responsible for performing all zone signing key (ZSK) and key signing key (KSK) rollovers and for polling child zones to keep signed delegations up-to-date.

Transferring the Key Master role

If the Key Master is online, you can perform a graceful transfer the Key Master role to another DNS server. Another qualifying DNS server must be available on the network.

To transfer the Key Master role using DNS Manager, view the DNSSEC properties of the zone, click the Key Master tab, and then choose Use the following DNS server as the Key Master. When you click the drop-down list, a pop-up alert asks if you want the local server to build a list of available, qualifying DNS servers that can be the Key Master. Click OK, choose a server from the list, and then click OK. See the following examples:

You can also perform this operation using Windows PowerShell with the Reset-DnsServerZoneKeyMasterRole cmdlet. See the following example.

PS C:\> Reset-DnsServerZoneKeyMasterRole -ZoneName secure.contoso.com -KeyMasterServer dc2.contoso.com -force

PS C:\> Get-DnsServerDnsSecZoneSetting -ZoneName secure.contoso.com | Select KeyMasterServer

KeyMasterServer
---------------
DC2.contoso.com

In this example, the Get-DnsServerDnsSecZoneSetting cmdlet is also used to verify that the Key Master role was transferred successfully.

Seizing the Key Master role

The server that is designated as the Key Master should be online and highly available to ensure uninterrupted service for key signing operations. However, if the Key Master becomes offline and cannot easily be restored to online status, it is possible to forcibly transfer the Key Master role to another qualifying DNS server, using a process called seizing. Do not seize the Key Master role unless it is unavoidable. A graceful online transfer of the Key Master role is always preferred.

Private key material

To store private key material in Active Directory, select the Replicate this private key to all DNS servers authoritative for this zone check box in KSK settings for all KSKs that are used. See the following example.

If you do not want to store private key material in Active Directory, you might also be able to provide access to private key material using a certificate or hardware storage module (HSM) device. This storage media must be accessible to the DNS server that is selected as the new Key Master.

If private key material is not stored in Active Directory or an external device, you can use the following command to store this material in a certificate on the local computer.

MakeCert -ss MS-DNSSEC -sr LocalMachine

To use the MakeCert command, you must first download and install the Windows SDK from https://go.microsoft.com/fwlink/p/?linkid=84091.

If the new Key Master cannot access private key material for the zone, a notification is displayed that indicates that private key material is not accessible and that new keys must be generated. See the following example.

If private key material is stored in Active Directory, you can seize the Key Master role on another primary, authoritative Active Directory-integrated DNS server and have full access to private key material. In this case, the signing keys (ZSKs and KSKs) do not have to be replaced.

If you use DNS Manager to access an Active Directory-integrated authoritative DNS server with a primary copy of the zone when the Key Master is offline, a notification is displayed when you view DNSSEC properties of the zone, which indicates that DNSSEC settings could not be loaded. See the following example.

Click OK to load DNSSEC settings using the local server. These settings will be the settings that were configured during the last successful replication.

On the Key Master tab, you can choose a new Key Master from a list of available DNS servers, similar to the procedure that is used for a graceful transfer of the Key Master role, described earlier in this topic.

After choosing a new Key Master and clicking OK, a notification is displayed with information about the changes to be made. Click OK again to proceed with the seizing operation. Another notification is displayed with the status of the role transfer. See the following examples:

Information about the new Key Master replicates in Active Directory to all primary DNS servers. After seizing the Key Master role on another server, if the old Key Master comes online, it detects that it is no longer the Key Master. You do not have to modify settings further.

DNSSEC standards

In addition to online signing and unsigning of dynamic Active-Directory-integrated zones, DNSSEC in Windows Server 2012 and Windows Server 2012 R2 includes support for:

• Automated key rollover

• Automated updates of DNS security trust anchors (RFC 5011)

• NSEC3 zone signing and validation

• NSEC3 random salt and user-defined salt

• RSA/SHA-2 zone signing and validation

For more information about DNSSEC settings that are used in zone signing, see Parameter values.

Zone transfers

Zone transfers can be secured using IPsec. Windows Server 2012 and Windows Server 2012 R2 do not support Transaction Signature (TSIG) for zone transfers.

Certificate-based authentication can be used to establish an IPsec session between DNS servers. Each endpoint must present a certificate to prove its identity. This method requires that certificates are created and configured on all DNS servers that participate in zone transfers for DNSSEC-signed zones.

To configure certificate-based IPsec policies on DNS servers, see the following topics:

Procedure: Deploy Certificates for DNS Server Authentication

Procedure: Deploy IPsec Policy to DNS Servers

See also

Overview of DNSSEC

DNS Clients

DNS Zones