Understand and Troubleshoot DNSSEC in Windows...

Understand and Troubleshoot DNS Security Extensions (DNSSEC)in Windows Server "8" Beta

Microsoft Corporation

Published: February 2012

Abstract

This Understand and Troubleshoot Guide (UTG) enables you to learn technical concepts, functionality, and troubleshooting methods for DNS Security Extensions (DNSSEC) in Windows Server “8” Beta. This UTG provides you with:

A technical overview and functional description of this feature.

Technical concepts to help you successfully install, configure, and manage this feature.

User Interface options and settings for configuration and management.

Relevant architecture of this feature, with dependencies, and technical implementation.

Primary troubleshooting tools and methods for this feature.

Copyright informationThis document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft. All rights reserved.

Active Directory, Hyper-V, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Table of ContentsWindows Server "8" Beta Understanding and Troubleshooting Guide: DNS Security Extensions (DNSSEC)......................................................................................................................................................1

About The Understanding and Troubleshooting Guide.......................................................................................1

Introducing DNSSEC.................................................................................................................................................1

Technical Overview..................................................................................................................................................5

DNSSEC Terms.....................................................................................................................................................5

Functional Description.........................................................................................................................................8

Deploying DNSSEC.................................................................................................................................................18

Management Considerations.............................................................................................................................18

Security Considerations.....................................................................................................................................19

DNSSEC Configuration Settings..........................................................................................................................19

Management Tasks in a DNSSEC environment..................................................................................................35

Implementation Detail...........................................................................................................................................42

Services, Executables, DLLs................................................................................................................................42

Data Flow...........................................................................................................................................................43

Appendices............................................................................................................................................................45

Client Configuration of NRPT.............................................................................................................................46

Understand and Troubleshoot DNSSEC in Windows Server "8" Beta

Windows Server "8" Beta Understanding and Troubleshooting Guide: DNS Security Extensions (DNSSEC)About The Understanding and Troubleshooting Guide

Understanding and Troubleshooting Guides enable you to learn about technical concepts, functionality, and general troubleshooting methods for new Windows features and enhancements. The Understanding and Troubleshooting Guide supports you in developing understanding of key technical concepts, architecture, functionality, and troubleshooting tools and techniques. This understanding will enable more successful testing and early adoption experiences during the pre-release product evaluation phase, and will support early ramp-up of help desk and technical support roles.

Introducing DNSSEC

What Is DNSSEC?DNS Security Extensions (DNSSEC) is a suite of extensions that add security to the DNS protocol. RFCs 4033, 4034, 4035, and 5155 specify the core DNSSEC extensions 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 new resource records (DNSKEY, RRSIG, NSEC, NSEC3, and DS) to DNS.

More Information:

For definitions of the new resource records for DNSSEC, see the terms section of this document.DNSSEC Terms

DNSSEC allows for all the records in a DNS 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 requested. 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.

Given sufficient time and data, it is possible for attackers to compromise cryptographic keys. DNSSEC mitigates the possibility of compromise attempts by using a short-term key, called the Zone Signing Key (ZSK). The ZSK is used to routinely compute signatures for the DNS records. A long-term key, called the Key Signing Key (KSK), is used to compute a signature on the ZSK (along with other records) to allow it to be validated. The ZSK is changed or rolled over frequently to make it difficult for the attacker to "guess" while the longer KSK is changed less frequently over a much longer term.

1


In addition to spoofing the value of an existing record, an attacker might also spoof a response to the client saying a particular record does not exist. Since signatures are present only when a record exists, a validating client must have a mechanism of obtaining a response indicating authenticated denial of existence. Next Secure (NSEC) and NSEC3 options provide authenticated denial of existence.

More Information:

Windows Server 2008 R2 supports NSEC denial of existence, and Windows Server "8" Beta supports both NSEC and NSEC3 updates to provide hashed authenticated denial of existence. For more information about NSEC3, see the functional description section of this document:Hashed Authenticated Denial of Existence (NSEC3)

Updates to DNSSEC in Windows Server "8" BetaWindows Server 2008 R2 introduced support for DNSSEC, and provided the ability to generate keys and host a signed zone. However, there were several limitations to the support, as listed below.

Zones could only be signed offline, over a file-based copy of the zone. It was not possible to generate signatures or update signatures on a zone while the zone was online.

The processes of key generation and zone signing were manual, and required the command-line utility dnscmd

Dynamic updates to DNS records were not supported

There was no built-in support for automatic key rollovers

Windows Server "8" Beta introduces support for online signing and automated key management as part of updating the DNSSEC support in the DNS server’s authoritative functions. The new supported features include the following.

On the authoritative DNS server:

Support for DNS dynamic updates in DNSSEC signed zones

Support for updated DNSSEC standards, including NSEC3 and RSA/SHA-2

Automated trust anchor distribution through Active Directory

Automated trust anchor rollover support through RFC 5011

Updated user interface with deployment and management wizards

Windows PowerShell based command line interface for easy management and scripting

On the non-authoritative DNS resolver:

Validation of records signed with updated DNSSEC standards (NSEC3, RSA/SHA-2)

Automated trust anchor rollover support through RFC 5011

2 © 2012 Microsoft Corporation. All rights reserved.


Easy extraction of the root trust anchor

Each of these features is discussed in more detail in the Functional Description section of this document.

More Information:

For more information about DNSSEC, see the relevant Internet RFCs:HYPERLINK "http://tools.ietf.org/html/rfc4033"http://tools.ietf.org/html/rfc4033http://tools.ietf.org/html/rfc4034http://tools.ietf.org/html/rfc4035http://tools.ietf.org/html/rfc5155

Purpose/BenefitsAttackers have increasingly shifted the focus of their attacks away from the operating system and towards infrastructure services. Subsequently, attackers are more likely to exploit DNS as they realize the impact of compromising this critical service. DNSSEC adds an additional layer of protection to a network by providing validation of DNS responses. This allows client computers to trust that information they receive is valid.

As originally designed, DNS itself does not offer any form of security and is vulnerable to spoofing and man-in-the-middle attacks. Compromising DNS can allow an attacker to compromise all future communications to the targeted host, so securing DNS has become very critical. DNSSEC includes changes to the client and server DNS components, which allow them to sign data, stored in the DNS zone, and enforce name validation policies that can protect the DNS communication.

DNS Spoofing VulnerabilitySpoofing is the single greatest vulnerability in DNS. DNS spoofing is the practice of assuming the DNS name of another system either by corrupting a name service cache or by compromising a DNS server for a valid domain. When any DNS resolver sends a remote query, it tags the query with a 16-bit XID (transaction ID) value in the DNS packet header and expects that the remote DNS server will respond on the same port with the same XID value. The query is typically sent over UDP. Generally, TCP is only used after a UDP response has been truncated. When the resolver receives a UDP DNS response it can only weakly verify that the response is authentic by matching these parameters:

Remote DNS server address. This check is often disabled by default since many network devices make it appear that valid responses come from a different address than the query was sent to, making it even easier to spoof a DNS response.

Port on which the packet was received. The resolver will typically send from an ephemeral port to port 53. DNS servers respond from port 53 to whatever source port was used by the requestor.

3

http://tools.ietf.org/html/rfc5155




Packet XID value. The XID value is set in the request by the resolver and must match the value contained in the response. A strongly random value can and should be used for the XID but it is only 16 bits long. The XID value, like the rest of the DNS packet, is sent in the clear.

Query name and type. The DNS server echoes the query name and type in the question section of the DNS response.

If an attacker does not have access to a DNS client or server’s network traffic, they may be able to guess that a DNS client or server has sent a DNS query and is waiting for a DNS response. When they have determined this to be true, the attacker can send one or more spoofed DNS response packets and attempt to beat the authentic response back to the requestor. An attacker (or a botnet under their control) can attack DNS clients and DNS servers that send remote DNS queries. Since the attacker controls the time-to-live (TTL) assigned to the spoofed response, once the attack is successful it can persist for days, weeks, or even longer.

Figure 1 Example of DNS Spoofing Vulnerability

Technical OverviewDNSSEC Terms

The following table displays a list of DNSSEC-related terms used in this guide.

Term Definition Reference

Authentication chain A chain of signed and validated DNS records starting from a RFC 4035




preconfigured trust anchor to some child zone in the DNS tree.

[7] Section 5

Authoritative Answer (AA) bit

A name server indicates that its response is authoritative by setting the Authoritative Answer (AA) bit in the response to a query on a name for which it is authoritative.

RFC 1035 Section 4

Authenticated Data (AD) bit

The AD (Authenticated Data) bit indicates in a response that all data included in the answer and authority sections of the response have been authenticated by the DNS server according to the policies of that server.

RFC 4035 [7] Section 3

Delegation Signer (DS) record

A DNSSEC record type used to secure a delegation. RFC 4034 [6] Section 5

DNS Extension (EDNS0) A DNS record that carries extended DNS header information, such as the DO bit and maximum UDP packet size

RFC 2671 [3]

DNS Security Extensions (DNSSEC)

Extensions to the DNS service that provide mechanisms for signing and securely resolving DNS data

RFCs 4033 [5], 4034 [6], and 4035 [7]

DNSKEY record A DNSSEC record type used to store a public key. RFC 4034 [6] Section 2

DNSSEC OK (DO) bit A bit in the EDNS0 portion of a DNS request that signals that the client is DNSSEC-aware.

RFC 4035 [7] Section 3.2.1

Double Signature Double signature is a key rollover method where a future key and signatures generated using it are published into the DNS zone before the existing key and its signatures are deleted, thus leaving two sets of keys and associated signatures in the zone at any given time.

RFC 4641

Island of Security A signed zone that does not have an authentication chain from its delegating parent zone


Key Master (KM) The key master is the DNS server that is responsible for key generation and management, and acts as the server that the administrator interacts with to set up DNSSEC.

Key Rollover A key rollover (also called key supercession in some environments) is the act of replacing one key pair with

RFC 4641

5



another at the end of a key effectivity period.

Key Signing Key (KSK) The KSK is an authentication key that corresponds to a private key used to sign one or more other signing keys for a given zone. Typically, the private key corresponding to a KSK will sign a ZSK, which in turn has a corresponding private key that will sign other zone data. Local policy may require that the ZSK be changed frequently, while the KSK may have a longer validity period in order to provide a more stable secure entry point into the zone. Designating an authentication key as a KSK is purely an operational issue: DNSSEC validation does not distinguish between KSKs and other DNSSEC authentication keys, and it is possible to use a single key as both a KSK and a ZSK.

RFC 4033 section 2

Next Secure (NSEC) record

A DNSSEC record type used to provide authenticated denial of existence for a DNS name.


Next Secure (NSEC3) record

The NSEC3 Resource Record (RR) provides hashed authenticated denial of existence for DNS Resource Record Sets.

RFC 5155 Section 3

Non-validating security-aware stub resolver

A security-aware stub resolver that trusts one or more security-aware DNS servers to perform DNSSEC validation on its behalf


Offline zone signing The process of signing or re-signing a file that contains the DNS data for a zone on a machine that is not an authoritative DNS server for the zone. The signed zone file created by this process can then be transferred to an authoritative DNS server and loaded.


Online zone signing The process of signing or incrementally re-signing a zone while it is loaded by the DNS server. This requires that private keys be accessible to the DNS server process.


Pre-Publication Pre-publication is a key rollover method where a key for future use is added and published in the DNS zone without generating any signatures

RFC 4641

Resource Record Set (RRSet)

Each DNS Resource Record (RR) has a label, class, type, and data. It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered. It is however possible for most record types to exist with the same label, class and type, but with different data. Such a group of records is defined to be a Resource Record Set (RRSet).

RFC 2181

Resource Record A DNSSEC record type used to hold a signature, which See RFC




Signature (RRSIG) record

covers a set of DNS records for a particular name and type. 4034 [6] Section 3

Security-aware DNS server

A DNS server that understands the DNS security extensions defined in RFCs 4033 [5], 4034 [6], and 4035 [7]. In particular, a security-aware DNS server is an entity that receives DNS queries, sends DNS responses, supports the EDNS0 [3] message size extension and the DO bit, and supports the DNSSEC record types and message header bits.

RFCs 4033 [5], 4034 [6], and 4035 [7]

Security-aware resolver A resolver that understands the DNS security extensions defined in RFCs 4033 [5], 4034 [6], and 4035 [7]. In particular, a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 [3] message size extension and the DO bit, and supports the DNSSEC record types and message header bits.


Signed zone A zone whose records are signed as defined by RFC 4035 [7] Section 2. A signed zone contains DNSKEY, NSEC, RRSIG, and DS records. These records allow DNS data to be validated by resolvers.


Trust anchor (TA) A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response.


Unsigned zone Any DNS zone that has not been signed as defined by RFC 4035 [7] Section 2


Zone Signing Key (ZSK) An authentication key that corresponds to a private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key.

RFC 4033 Section 2

7


More Information:

For more information on parameters associated with DNSSEC implementation, see the DNSSEC Parameters table in the Configuration Settings section of this document.DNSSEC Parameters

Functional DescriptionTo allow for staged migration to the new server operating system, DNSSEC deployment does not require that all DNS servers are running Windows Server "8" Beta to host a signed zone. Although it is recommended to have all DNS servers hosting the signed zone upgraded to Windows Server "8" Beta before validation is enabled on resolvers, only one authoritative DNS server running Windows Server "8" Beta is required.

Note:Only Windows Server "8" Beta DNS servers will host a signed copy of the zone. Servers running earlier versions of Windows will continue to host unsigned zones.

Configure clients that require DNSSEC to resolve names using the Windows Server "8" Beta DNS servers by appropriately configuring the Name Resolution Policy Table (NRPT) on the client or by configuring forwarders on the non-authoritative servers.

More Information:

For detailed information on configuring clients to use DNSSEC, see the Client Configuration section in the Appendix of this document.Client Configuration of NRPT

Online SigningIn 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, including the following.

Administrators could only generate the keys required to sign a zone manually using the dnscmd utility. 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. Administrators were required to plan the type of rollover desired in advance, and then generate keys manually.

Dnscmd required several inputs to generate keys and assumed no defaults. In some cases, administrators 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 done over a file copy of the zone offline. The administrator then had to manually import this signed file copy of the zone onto the server.

Administrators were required to manually re-sign a zone whenever an update was made to the zone. Zone updates were limited to only those that could be made manually, and dynamic updates were disabled on a signed 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, and could not be easily exported to other DNS servers.

Windows Server 2008 R2 supported signing Active Directory (AD)-integrated zones, but could not have dynamic updates enabled. Windows Server "8" Beta introduces support for DNSSEC online signing, which enables signing and unsigning of Active Directory (AD)-integrated zones and support for dynamic updates. A Windows Server "8" Beta DNS server includes a DNSSEC wizard in DNS Manager, which walks an administrator through the signing and unsigning process. The wizard generates all keys necessary to sign a zone automatically as part of the process of signing the zone.

The only signatures that replicate between servers are the DNSKEY signatures. For AD-integrated zones, the private zone signing keys replicate automatically to all masters through AD replication. Each master server signs its own copy of the zone when it receives the key.

For optimal performance, and to prevent increasing the size of the AD database file, the signed copy of the zone remains in memory for AD-integrated zones. A DNSSEC signed zone is only committed to disk for file-based 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 may 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 DC sees the DNSSEC keys and configuration, it will wait for a random period between 5 minutes and 30 minutes before it begins signing the zone.

Note:Once a zone is signed for DNSSEC, the DNS server will explicitly block attempts to change the zone replication scope or zone type while the zone is signed. This is primarily to avoid complexities related to key storage.

Key MasterIn a multi-master DNS deployment, each master server is identical to all other master servers. However, for DNSSEC, a single master server must perform key generation and key management. Windows Server "8" Beta introduces the concept of a key master (KM) for

9


DNSSEC. The key master is the DNS server that is responsible for key generation and management, and acts as the server that the administrator interacts with to set up DNSSEC.

The KM generates all keys for the zone, and is responsible for distribution of private keys and zone signing information. Only the KM can perform any operations with or on the Key Signing Key (KSK). The KM is fully responsible for performing KSK and Zone Signing Key (ZSK) rollovers, and for polling child zones to keep signed delegations up to date. The server designated as the KM must be online and highly available to ensure uninterrupted service for key signing operations. However, it is possible to transfer the key master role from one DNS server to another.

The KM is master in the context of a given zone and is not global across multiple servers, zones, domains, or forests. Each signed zone will have a specific key master. A given server, however, can be the KM for multiple zones as long as it hosts a primary copy of the zone. Any authoritative DNS server that hosts a primary copy of the zone can be designated as the KM. The zone where the administrator initially performs DNSSEC operations automatically becomes the KM.

Updating DelegationsWhen the child zone of a signed parent is also signed, the Delegation Signer (DS) records from the child must be added to the parent zone so that resolvers can construct a chain of trust. The KM generates a file that contains the DS records and writes it to the %Windir%\System32\dns directory. The administrator must transfer these records to the parent zone manually by selecting the option to import DS records in the DNS Manager console. The import wizard prompts the administrator to select the DS file to import. The parent server then adds the DS record to the zone and re-signs the zone.

The KM will poll the child zone at regular intervals to see if the child zone’s keys have been rolled over. This polling is per-zone, and can be disabled at the parent zone. The default polling interval setting is 12 hours, with a minimum value of one hour and maximum of one week. During polling, the parent retrieves the DNSKEY record set from the child using standard DNS query and response. The parent server compares the DNSKEY record set returned with the current DS record, and then updates the record and re-signs the zone if needed.

Trust Anchor ConfigurationIn cryptographic terms, a trust anchor is an authoritative entity represented by a public key and associated data. In DNSSEC terms, a trust anchor (TA) is a configured DNSKEY RR or DS RR hash of a DNSKEY RR. A resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. A TA for a signed zone must be configured on every DNS resolver that will attempt to validate DNS data from that signed zone.



During the configuration process, if the DNS server hosting the zone is a domain controller, the following options are available for TA distribution. This includes file-backed zones hosted on domain controllers. If the KM is a standalone non-AD integrated server (such as a member server), these options will not be available.

• Distribute trust anchors for this zone as DNSKEY records to all DNS servers in this forest automatically (default)

• Distribute trust anchors for this zone as DS records to all DNS servers in this forest automatically

• Distribute trust anchors for this zone as DNSKEY and DS records to all DNS servers in this forest automatically

• Do not distribute trust anchors for this zone

Automation of Post-Signing TasksA primary limitation of DNSSEC in Windows Server 2008 R2 was that any changes made to a DNSSEC signed zone required manual offline re-signing of the zone. Dynamic DNS updates are disabled on any signed zone, which severely limits the deployment of Active Directory-integrated signed zones. In addition, there was no way to re-sign zones automatically as signatures neared expiration.

With Windows Server "8" Beta, the DNS server is now capable of performing all of these operations to keep signatures up-to-date automatically without the need for administrative intervention. This significantly reduces the cost of ownership of a DNSSEC-signed zone. The Windows Server "8" Beta DNSSEC implementation enables administrators to "sign and forget".

• Dynamic Updates: Dynamic updates can be enabled on a signed zone. As in the case of an unsigned zone, any DNS server authoritative for the zone can accept dynamic updates. When a Windows Server "8" Beta DNS server receives an update, it will automatically generate signatures for the update and add the update and its signatures to the zone. Through AD replication, the unsigned update will replicate to all other authoritative servers, and each authoritative server will generate signatures for the update and add it to its own copy of the zone.

• Updates to the zone through management tools: Updates to zone data through management tools like DNS Manager, dnscmd, and Windows PowerShell no longer require a manual re-signing of the zone.

• Keeping signatures up to date: The Windows Server "8" Beta server keeps track of signature expiration, and automatically refreshes signatures that are about to expire to ensure continuous availability of zone data.

• Scavenging: Scavenging of stale records in a signed zone works exactly like it does on unsigned zones.

11


Key RolloversDNSSEC keys do not have a permanent lifetime, and require periodic replacement. The longer a key is in use, the greater the risk of compromise. The key replacement process is known as a key rollover. Performing key rollovers are a vital part of operating a DNSSEC-signed zone. In Windows Server 2008 R2, administrators must perform the rollover process manually, assisted by documentation.

Windows Server "8" Beta DNS provides support for automated key rollover management, including provisioning and configuration of the supported methods for ZSK and KSK rollover, and the actual process of performing a key rollover.

More Information:

Windows Server "8" Beta key rollover automation methods are based on those described in RFC 4641 and NIST SP 800-51HYPERLINK "http://tools.ietf.org/html/rfc4641"http://tools.ietf.org/html/rfc4641http://csrc.nist.gov/publications/nistpubs/800-51-rev1/SP800-51rev1.pdf

The automated key rollover feature in Windows Server "8" Beta eliminates the need for the complicated and error prone task of performing manual rollovers. The server handles key rollovers at the correct time, maintaining the continuous operation of the signed zone with no increase in operational costs.

Rollover is a function of the key, and not of the DNS zone. During DNSSEC parameter selection for online signing, the administrator selects the rollover type, rollover frequency, and initial offset for each key. The DNS server maintains a timer to track the rollover period for each key, and initiates the rollover when the rollover time is reached. The server only rolls over one key at a time; additional keys are queued until after the current rollover is completed.

To prevent simultaneous expiration of keys, configure the initial offset value at the time of zone signing to set a delay in initiating key rollover. The initial offset value is used to ensure that multiple keys that are created at the same time and have the same rollover frequency do not expire on the same day. Initial offset values can be set for both ZSKs and KSKs.

Initial offset values are also used to ensure that a ZSK and a KSK rollover do not happen at the same time. However, if the administrator does not configure an offset, and the keys are up for rollover at the same time, the DNS server will first complete the KSK rollover before initiating the ZSK rollover.

Windows Server "8" Beta supports only the Double Signature and Pre-publish rollover methods for automatic rollover. Customers who wish to use a different method can still manually perform a rollover by using Windows PowerShell. A comparison of the supported key rollover methods is provided in the table below.

Rollover Method Description

Double Signature This method involves creating two ZSKs. The data in the zone is signed with


http://csrc.nist.gov/publications/nistpubs/800-51-rev1/SP800-51rev1.pdf


Rollover Method Description

both ZSKs so that each RRSet has two sets of signatures.Advantage:The main advantage of using this method is that it only requires 3 steps to be performed because at any time during the addition of the new key (the double signature) the old signature remains valid. Compared with the Key Pre-publication method, this method requires only 1 interaction with the parent zone.Disadvantage:Performing double signature rollovers will result in the number of signatures in the zone doubling, which can mean a significant increase in zone size.

Pre-publish This method involves creating two ZSKs in advance. The zone data is signed using one ZSK, but the second key is published in the zone as another (unused) DNS key 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 signatures cached can still be validated using the first ZSK.Advantage:This method has a few distinct advantages. If the old ZSK is compromised, then administrators can very quickly switch to the new ZSK since it has already been published. Secondly, since only one key generates signatures at a time, the number of signatures in the zone is not doubled as in the case of the double signatures method.Disadvantage:A minor disadvantage of this method is that it requires 4 steps to be performed instead of three as in the case of double signature rollover.There is also more work involved from a parent zone point of view when KSK rollover occurs where key pre-publication is being used.

For KSK rollover, only the Double Signature rollover method is supported for automatic rollover. This method is preferred because, compared to Pre-publish rollover, Double Signature requires one less interaction between parent and child. This rollover generates two signatures, but because the KSK signs a small amount of data, the extra signatures do not have a detrimental effect on the zone or zone operations.

For ZSK rollover, only the Pre-publish rollover method is supported for automatic rollover. Double Signature ZSK rollover generates twice the number of signatures, and since the ZSK signs the entire zone, the resultant size of the zone would be twice as large, which is undesirable.

In addition to automatic rollover configuration, administrators can manually initiate a rollover through the DNSSEC UI. Manual triggering of rollover is subject to the following rules.

13


• Manual triggering of rollovers can only be done on the key master

• Since rollovers are triggered on a per-key basis, the administrator must select the specific key that is to be rolled over

• If an administrator triggers multiple keys to be rolled over, then the keys are rolled over one at a time (with successive keys queued) in the order in which the administrator triggered the rollovers.

• Even if automatic rollovers are disabled, manual triggering is allowed for a given key

• If the key is a KSK, only Double Signature rollover will be performed

• If the key is a ZSK, only Pre-publish rollover will be performed

• If a manual rollover is triggered for a particular key, the rollover clock is reset after the rollover completes

If a failure occurs while rolling over a key, the DNS server automatically retries the operation that failed in order to handle intermittent issues, such as a temporary network outage. If the DNS server encounters a critical failure and is unable to recover automatically, the server updates the status to indicate that the rollover has failed, changes the state of the zone to what it was prior to initiating rollover, and resets the rollover clock so that the operation is attempted again at the next scheduled period.

Hashed Authenticated Denial of Existence (NSEC3)When the original DNSSEC standards were defined (RFCs 4033, 4034, and 4035), the specifications included a mechanism to provide authenticated denial of existence through a resource record called “Next Secure”, or NSEC. To provide this functionality, the DNS server sorts the contents of the zone in the canonical fashion before signing.

A canonical name order is required to construct the NSEC name chain, and to construct and verify RRSIG RRs. The DNS server orders the owner names by sorting the names according to their most significant (rightmost) labels. For example, the following names are sorted in canonical DNS name order.

example

a.example

yljkjljk.a.example

Z.a.example

zABC.a.EXAMPLE

z.example

Note:RFC 4034 specifies the canonical DNS name format used for sequencing the NSEC resource records.



When the zone is signed, an NSEC resource record is generated at each node, which contains a pointer to the next node, thus providing a linked-list of zone data. This NSEC record proves that nothing exists between the two names. However, NSEC has a side effect in that it enumerates the contents of the zone and allows for “zone-walking”. A resolver could issue several non-existent queries and enumerate the entire zone by analyzing the NSEC records returned.

To address this security concern, RFC 5155 creates the NSEC3 resource record, which offers the same authenticated denial of existence, but in addition also protects against undesired zone enumeration. To provide protection against zone enumeration, the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name prepended as a single label to the name of the zone. NSEC3 also includes mechanisms that allow a signed parent to host unsigned delegations and not require a re-signing whenever an unsigned delegation changes. This is a highly attractive feature for large zones like .com that are expected to have several hundreds of thousands of unsigned delegations.

More Information:

Windows Server "8" Beta hashed authenticated denial of existence support is based on RFC 5155.HYPERLINK "http://tools.ietf.org/html/rfc5155"http://tools.ietf.org/html/rfc5155

Windows Server "8" Beta introduces support for NSEC3 to the DNS Server’s authoritative and non-authoritative operations, including full support for the NSEC3 and NSEC3PARAM resource records. Updates to the DNS client provide the ability to recognize the NSEC3 and NSEC3PARAM records. During the initial signing process, administrators can choose between NSEC and NSEC3 for the preferred denial of existence mechanism.

RFC 5155 specifies four relevant NSEC3 parameters. The following table lists the default values for each parameter (Simple Signing) and the non-default options available (Advanced Signing).

Parameter Description Simple Signing default

Advanced Signing options

Hashing algorithm

The cryptographic hash algorithm used to construct the hash-value

SHA-1 SHA-1

Iterations Defines the number of additional times the hash function has been performed. More iterations result in greater resiliency of the hash value against dictionary attacks, but at a higher computational cost for both the server and resolver.

50 1024 bit key: up to 150

2048 bit key: up to 500

4096 bit key: up to 2500

15


Parameter Description Simple Signing default

Advanced Signing options

Salt The Salt field is appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. Augmenting original owner names with salt before hashing increases the cost of a dictionary of pre-generated hash-values. For every bit of salt, the cost of the dictionary doubles.

Generate randomly

No salt

Generate randomly

User provided

Salt length Defines the length of the Salt field in octets, ranging in value from 0 to 255

8 octets Min of 0, max of 255 octets

Opt Out The Opt-Out flag indicates whether this NSEC3 RR may cover unsigned delegations. If the Opt-Out flag is enabled, owner names of unsigned delegations may be excluded. If an NSEC3 RR has Opt-Out disabled, there must not be any hashed owner names of insecure delegations between it and the next hashed owner names of insecure delegations.

Opt Out disabled

Opt Out enabled/disabled

Automated updating of DNSSEC trust anchorsWhen an administrator uses dnscmd to sign a DNS zone in Windows Server 2008 R2, the server creates a text file that contains the trust anchor (TA) DNS records. If the current zone does not have a parent that is signed, and represents the root of an island of security, the administrator may consider publishing or distributing the TAs to administrators of other organizations.

In order to validate the DNSSEC protected data, DNSSEC-aware resolvers must have knowledge of the TA for that zone. Creating the TA at the trust point and adding the TA to the DNSSEC-aware resolvers is a manual process. If the public key expires or is compromised, the TA has to be updated manually by deleting the current TA and adding a new TA at the trust point. DNSSEC-aware resolvers have to manually update their local copies of the TA. Windows Server "8" Beta provides a method for DNSSEC-aware resolvers to poll for TA changes and automatically keep their copy of the TA updated.

More Windows Server "8" Beta support for automated, authenticated and authorized



Information: updating of DNSEC trust anchors is based on RFC 5011.http://tools.ietf.org/html/rfc5011

DNSSEC Windows PowerShell IntegrationWindows Server 2008 R2 provided support for configuring and managing DNS through the DNS Manager console and the DNS Server Role Management Tool (RMT). The dnscmd.exe utility provided a command line interface, and Microsoft DNS Server Management Protocol (MS-DNSP) provided an API programming interface.

Since the output of dnscmd.exe is text based, it does not provide an optimal scripting environment. An administrator needing to perform a set of tasks on the DNS server must write text-parsing code to extract data from dnscmd.exe output, and then perform tasks based on the values obtained. The need for text parsing increases complexity of scripting. There are no public APIs exposed for DNS server management, and the only option available to vendors who wish to build applications on top of Microsoft DNS server is to use MS-DNSP.

To address these shortcomings, Windows Server "8" Beta provides task-oriented Windows PowerShell cmdlets for DNS server management, including DNSSEC configuration. The DNSSEC configuration options are implemented in Windows Server "8" Beta Windows PowerShell as Common Information Model (CIM) based cmdlets. These Windows PowerShell CIM cmdlets allow interoperation with other management applications such as System Center. Windows PowerShell uses object pipelining to eliminate the need for parsing and manipulation of text output.

LimitationsThe Windows Server "8" Beta implementation of DNSSEC does not address all deployment scenarios and security risks associated with DNS. Limitations of DNSSEC functionality in Windows Server "8" Beta include the following.

• DNSSEC does not provide privacy or encryption of DNS data. IPsec rules can be used in coordination with DNSSEC configuration to provide this additional level of security.

• The DNS server will not attempt to gather DNSSEC records if a remote server or intermediate device does not support DNS Extensions (EDNS0). Intermediate devices, such as NAT devices that proxy DNS queries, may not support EDNS0. Deploying the server behind such devices will make DNSSEC validation impossible.

• DNSSEC is not supported in combination with DNS short name resolution using the GlobalNames Zone (GNZ), or with DNS zones configured to forward requests to WINS servers. DNSSEC signed zones will ignore configuration settings for GNZ and WINS forward lookup.

17



Deploying DNSSECManagement Considerations

Prior to signing any production DNS zone, administrators must consider the performance and resource utilization impact of DNSSEC. Performance considerations include the following.

• A DNS server hosting a signed zone may require up to 5 times the memory of the equivalent unsigned zone in order to support the signed zone. Ensure that sufficient memory is available on all the DNS servers that will host signed zones.

• When responding to queries, the DNS server will respond with additional DNSSEC resource records. This will increase the number of packets on the wire 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 that is authoritative for signed zones will typically experience only a small increase in CPU usage associated with its zone handling. However, the increase in CPU load can be more significant if the DNS Server is also performing validation on data it obtains from other remote signed zones, when servicing queries from clients or when configured to act as a forwarder for other DNS servers, depending on how many queries it needs to service. In such a case, ensure that the server has appropriate processor resources and monitor this during testing and rollout.

• A signed zone can have upwards of 4 times the number of records as the unsigned version of the zone depending on the number of keys/algorithms used to sign the zone. Depending on the signature size, the actual disk space consumed by a file-backed signed zone can be more than 10 times that of the unsigned zone. This is not a concern for AD-integrated zones, since the signatures are only stored in memory and are never committed to disk.

The actual performance depends on the following factors:

• AD-integrated versus file backed - The DNS server must generate signatures on load for AD-integrated zones, but will have signatures stored on disk for a file-backed zone. This will significantly affect the server performance with respect to zone loading.

• Algorithm used for signing - RSA based algorithms are generally faster from a signature generation and validation standpoint as compared to Elliptical Curve based algorithms, for example.

• Key length - longer key lengths will create larger signatures and increased signature computation and verification overhead

• Denial of Existence (NSEC vs. NSEC3) - NSEC3 requires the calculation of hashes in the authenticating and non-authenticating functions. The number of hash iterations can also affect performance by adding overhead to zone signing time and validation.



Security Considerations

Hosting Signed Zones on RODCsIn Windows Server 2008 and Windows Server 2008 R2 DNS servers running on Read Only Domain Controllers (RODCs) host AD-integrated copies of all zones. However, the DNS server cannot make any updates to the zones it hosts. It is considered unsafe to replicate private keys to an RODC, since RODCs are designed to operate in physically insecure environments.

In Windows Server "8" Beta, an RODC will load unsigned zones from AD with no change in functionality from Windows Server 2008 R2. However, if the RODC finds a signed zone in AD, it will not load the zone as AD-integrated. Instead, it will create a secondary copy of the zone, and then configure the closest writeable domain controller for the domain as the primary server.

The RODC will then attempt to perform a zone transfer. If zone transfers are enabled on the primary DNS server that the RODC selected, then the transfer succeeds and the RODC begins to respond to queries for the zone. However, if zone transfers are not enabled, the transfer operation fails. The RODC will log an error event and will take no further action. In this scenario, the administrator must manually enable zone transfers on the primary selected by the RODC. Alternately, the administrator can choose to reconfigure the RODC to point to a different primary server. The configured primary server must also have zone transfers enabled.

DNSSEC Configuration SettingsRollout of DNSSEC must be done in a phased manner, allowing for a period of validation between each phase. DNSSEC deployment begins with introducing Windows Server "8" Beta DNS servers into the environment, signing the zone, deploying trust anchors to perform validation, and eventually evaluating and deploying last-mile security solutions.

Introducing Windows Server "8" Beta DNS servers into the environment

The first step in deploying DNSSEC is the introduction of Windows Server "8" Beta DNS servers to the environment. The DNSSEC implementation in Windows Server "8" Beta is not backward compatible with the DNSSEC implementation in Windows Server 2008 R2. The best practice recommendation is that all DNS servers hosting a signed zone be running Windows Server "8" Beta.

However, since forklift upgrading of DNS servers in already existing production environments (that are often also Domain Controllers) is impractical, the DNSSEC

19


implementation in Windows Server "8" Beta supports mixed-mode environments. In a mixed-mode environment, some DNS servers are Windows Server "8" Beta while others are down-level versions of Windows Server.

In this deployment, all DNS servers host the same zone, but only the Windows Server "8" Beta DNS servers will host a signed copy of the zone. The down-level DNS servers will host an unsigned copy of the zone. This model works because each Windows Server "8" Beta DNS server signs its own copy of the zone and never replicates signatures. However, it is recommended that all DNS servers hosting the zone to be running Windows Server "8" Beta for green-field deployments, test lab deployments, and pilots.

Important:In mixed-mode environments, the Active Directory schema must be upgraded before signing a DNS zone. To upgrade the schema, follow the steps documented on TechNet:http://technet.microsoft.com/en-us/library/cc755834(WS.10).aspx

Signing DNS ZonesOnce Windows Server "8" Beta DNS servers are introduced to the environment, the zone can be signed. It is recommended that at least two Windows Server "8" Beta DNS servers be present in the mixed-mode environment before the zone is signed. The zone can be signed on any of the Windows Server "8" Beta DNS servers that host a primary copy of the zone. The server on which the zone is signed becomes the key master by default.

The DNSSEC configuration user interface is accessible within the DNS Manager console. To access the DNSSEC zone signing wizard, right-click the zone in the console tree of DNS Manager, and select DNSSEC > Sign the Zone. This launches the DNSSEC zone signing wizard. The following figures illustrate the wizard interface and configuration options available.


http://technet.microsoft.com/en-us/library/cc755834(WS.10).aspx


Figure 2 DNS Manager

Right-click on the zone name and select “Sign the zone” to launch the DNSSEC zone signing wizard. The zone signing wizard will guide you through the steps of signing a zone.

21


Figure 3 DNSSEC zone signing wizard

Figure 4 Signing Options

The Signing Options page provides three choices:

Configure the zone signing parameters: selecting this option will guide you through all the individual steps of signing the zone and will let you change all values. Defaults are provided for most values.

Sign the zone with parameters of an existing zone: selecting this option allows you to sign the selected zone using the same parameters and options as another zone that is already signed.

Use recommended settings to sign the zone: selecting this option signs the zone using all built-in defaults.

First, configure KSK options. At least one KSK is required.



Figure 5 Key Signing Key (KSK)

Figure 6 Edit Key Signing Key (KSK)

Next, configure the options for ZSK. At least one ZSK is required.

23


Figure 7 Zone Signing Key (ZSK)

Figure 8 Edit Zone Signing Key (ZSK)

Figure 9 Next Secure



Next, configure the Trust Anchor distribution options. If the DNS zone is Active Directory integrated, it is recommended to select the first check box. If the TAs must be kept up to date on servers that are not joined to the domain, or if the first check box is cleared, the second check box must be selected.

25


Figure 10 Trust Anchors

Figure 11 Signing and Polling Parameters

Figure 12 Summary



Figure 13 Zone Signing Progress

Figure 14 Confirmation

Refresh the DNS Manager window to display the newly added DNSSEC resource records.

27


Figure 15 DNSSEC Signed Zone in DNS Manager

The next section contains detailed descriptions of all the DNSSEC parameters.

DNSSEC ParametersWindows Server "8" Beta treats key management and zone signing as separate operations. This allows administrators a great deal of flexibility to edit keys and key parameters, and maintain continuity of signed zones. The table below gives a brief description of all the DNSSEC key and zone signing parameters.

Parameter Description

Signing algorithm The algorithm used to sign the zone. More than one algorithm can be used to sign a given zone. The supported DNSSEC algorithms are:

• RSA/SHA-1

• RSA/SHA-1NSEC3

• RSA/SHA-256

• RSA/SHA-512

• ECDSAP256/SHA-256

• ECDSAP384/SHA-384

NOTE: Only in the case of RSA/SHA-1 are there two distinct algorithms for NSEC and NSEC3. If you want the denial of existence to be NSEC, you must choose the signing algorithm as RSA/SHA-1 for all keys. If you want the denial of existence to be NSEC3, you must choose RSA/SHA-1NSEC3 for all keys.




For the other algorithms, there is no explicit distinction in its use with NSEC vs. NSEC3.

This behavior is an artifact of how the algorithms are defined in the RFCs.

KSK size The size of the Key Signing Key, in bits

Minimum size: 1024 bits

Maximum size: 4096 bits

Default size: 2048 bits

ZSK size The size of the Zone Signing Key, in bits

Minimum size: 1024 bits

Maximum size: 4096 bits

Default size: 1024 bits

Rollover type for KSK

Rollover mechanism to be used for KSK. Windows Server "8" Beta only supports Double Signature (as defined in RFC 4641) for automatic rollover

Rollover type for ZSK Rollover mechanism to be used for ZSK. Windows Server "8" Beta only supports Pre-Publish (as defined in RFC 4641) for automatic rollover

Frequency of KSK rollover

The frequency with which the KSK should be rolled over, specified in days.

Default rollover frequency for KSK: 390 days

Frequency of ZSK rollover

The frequency with which the ZSK should be rolled over, specified in days.

Default rollover frequency for ZSK: 30 days

Initial KSK offset The offset, specified in days, determines when the first KSK rollover will occur. The first rollover will occur at (date of KSK creation + rollover period + initial offset). All successive rollovers will occur on (date of last rollover + rollover period). The default for initial KSK offset is zero days.

Initial ZSK offset The offset, specified in days, determines when the first ZSK rollover will occur. The first rollover will occur on (date of ZSK creation + rollover period + initial offset). All successive rollovers will occur on (date of last rollover + rollover period). The default for initial ZSK offset is zero days.

Signature expiration (DNSKEY)

Amount of time for which DNSKEY signatures are valid from the inception time, as per RFC 4034, specified in hours

Default: 72 hours

29



Signature expiration (DS)

Amount of time for which DS signatures are valid from the inception time, as per RFC 4034. The DS records are present in the parent zone.

Default: 72 hours

Signature expiration (all records)

Amount of time for which the signatures for all records in the zone are valid from the inception time, as per RFC 4034, specified in hours

Default: 240 hours

Per-zone Parameters:


Denial of existence The mechanism that should be used for providing authenticated denial of existence. Either NSEC or NSEC3

NSEC3 hashing algorithm

Hashing algorithm to be used for NSEC3. The only supported algorithm is SHA-1

NSEC3 iterations Number of hashing iterations to be used for NSEC3.

Default value is 50

NSEC3 salt length Length of the salt to be used for NSEC3

NSEC3 salt The salt value to be added for NSEC3

NSEC3 Opt Out Whether or not NSEC3 Opt-Out is to be used

Signature inception Date and time of when the signature is created, as per RFC 4034 expressed as an offset from current time (for example, current time - n hours)

Secure Delegation Polling Period

The period at which the parent key master will poll the child zone to see if delegations need to be updated (as a result of a child KSK being rolled over)

DS Record Generation Algorithm

The hashing algorithm(s) to be used for DS record generation

TA rollover using RFC 5011

Whether the server should use RFC 5011 to enable resolvers to obtain the most up to date trust anchors

DNSKEY RRSet TTL TTL for the DNSKEY RRSet, in seconds, default is 3600

DS RRSet TTL TTL for the DS RRSet, in seconds, default is 3600

Publish TAs to all DNS servers in forest

This parameter determines whether to publish the TA for this key to all DNS servers in the forest. Specify the TA type (none, DS, DNSKEY,




both)

Upgrade all DNS servers to Windows Server "8" BetaAfter the zone is signed, existing DNS servers running previous Windows versions can be upgraded to Windows Server "8" Beta. New DNS servers or domain controllers running Windows Server "8" Beta can also be introduced. As soon as a Windows Server "8" Beta DNS server is added to the list of DNS servers hosting the zone, the DNS server will automatically receive the DNSSEC parameters and keys and will sign its own copy of the zone.

Before enabling validation, it is strongly recommended that as many DNS servers as possible are upgraded to Windows Server "8" Beta.

Creating secure delegationsThe next step is to create a secure delegation from the parent to the signed zone. To do this, a new resource record called Delegation Signer (DS) is added to the parent. The DS record contains a hash of the public key signing keys used to sign the zone.

Right-click on the zone, and then click Other New Records… Select Delegation Signer (DS), and click Create Record.

Figure 16 Create DS Record

31


Copy the values from the “dsset-zonename” file found under %windir%\system32\dns on the key master server for the zone.

Figure 17 DS Record Properties

Enabling validation on the caching resolverOnce all the authoritative DNS servers hosting the signed zone are running Windows Server "8" Beta, DNSSEC validation can be enabled on the non-authoritative or caching resolvers. Note that DNSSEC validation can only be enabled for the following OS versions:

If the zone is signed using RSA/SHA-1 signing algorithm and uses NSEC for denial of existence, validation can be enabled on Windows Server 2008 R2 and Windows Server "8" Beta caching resolvers.

If the zone is signed with any other signing algorithm (for example RSA/SHA-256) or uses NSEC3 for denial of existence, validation can only be enabled on Windows Server "8" Beta caching resolvers.

DNSSEC validation is enabled by configuring Trust Anchors. As discussed previously, a trust anchor is the public half of the public/private key pair that is used to sign the zone. With the pre-configured trust anchor, the caching resolver is able to validate DNSSEC signatures and ensure that names are resolved securely.

Trust anchors can be configured in following ways:



1. To enable other DNS servers in the forest that are AD-integrated to validate responses from the AD-integrated signed zone, select the “Distribute Trust Anchors to all servers in the forest” checkbox by right clicking on the signed zone, and navigating to the DNSSEC > Properties > Trust Anchors tab. With this checkbox selected, the authoritative DNS server that hosts the signed zone will insert the trust anchor into Active Directory and set it to replicate to the entire forest. All Windows Server "8" Beta DNS servers that are DCs in the same forest will automatically pick up the trust anchor and use it to securely resolve names from the signed zone.

2. Trust anchors must be manually configured on the caching resolvers if any of the below conditions are true:

The signed zone is file-backed

The caching resolver is not AD-integrated (i.e. is a standalone DNS server)

The caching resolver is a member of a different AD forest

To manually configure trust anchors, copy the “dsset-zonename” file found under %windir%\system32\dns on the key master server hosting a primary copy of the signed zone to the caching resolver.

On the caching resolver, right click on Trust Points and select “Import DS Key”. Browse to the location where the “dsset-zonename” file is stored and select the file. The trust anchor for the signed zone is now configured.

If a trust anchor for a signed parent zone is configured, additional trust anchors for child zones that are also signed do not need to be configured. The caching resolver is capable of securely obtaining keys for signed children by querying the parent. However, a trust anchor must be configured if the signed zone does not have a secure delegation in the parent.

Important:Once trust anchors are configured, DNSSEC validation is automatically enabled on the caching resolver. The caching resolver will now expect all responses from the signed zone to be accompanied by signatures. However, in a mixed mode environment where some of the DNS servers are running Windows Server "8" Beta and some are running previous versions of Windows Server, the DNS servers running previous versions of Windows Server will not be able to return signed responses. Therefore, the caching resolver must be configured to query only those authoritative DNS servers that are running Windows Server "8" Beta. This can be achieved by creating a Conditional Forwarder on the caching resolver for the signed zone and configuring only the IP addresses of the Windows Server "8" Beta authoritative DNS servers.

33


Last-mile security optionsOnce validation has been enabled on the caching resolver, a number of options are available to secure the hop between the caching resolver and the client.

1. Implicit trust

2. Enabling IPsec between the client and the caching resolver

3. Enabling IPsec between the client and the caching resolver with an explicit DNSSEC EKU certificate validation

4. Enabling IPsec between the client and the caching resolver with an explicit DNSSEC EKU certificate validation and making the client DNSSEC-aware

This Understanding and Troubleshooting Guide does not provide detail on how to configure the above options. It is recommended that early evaluators sign their zones as described above, deploy trust anchors on the caching resolvers, and assume implicit trust between the client and the caching resolver.

Management Tasks in a DNSSEC environment

Transferring the Key Master RoleWhile a given zone can only have one key master (KM) at any given point, it may be necessary to transfer the KM role to another server in certain scenarios.

Graceful Transfer of the KM RoleA graceful transfer of the key master role from one master server to another may be needed in the following scenarios.

• The domain controller that is the current KM is being decommissioned

• The hardware on the KM server is being replaced or upgraded

• The domain controller is being upgraded or migrated

• Administrator preference

It is important to note that the KM role is a per-zone concept, and a given server can be the KM for some of the zones it hosts and not for others. If an administrator wishes to retire a particular server, they must manually move the KM role for all zones individually per zone. In addition, an administrator can choose to move the KM role for just one zone from a server, while allowing the server to continue to be the KM for other zones.

The following steps describe a graceful KM role transfer. This operation does not generate new keys, and will not disrupt service of the zone.



• The administrator accesses the server intended as the new KM through the DNS Manager console. The administrator launches the DNSSEC Properties UI, and in the context of the zone for which the KM role is being transferred, selects “Use the following DNS server as the key master:”

Figure 18 DNSSEC Properties Key Master tab

• The new KM looks up the signing metadata and obtains the identity of the current key master. The new KM contacts the original KM through LDAP, and configures itself as the new KM. The server then tries to gain access to all the keys. It looks up the signing metadata to determine where the original KM has stored the private KSK. During this process, the location of the keys cannot be changed.

• If the new KM is not able to access the private keys for some reason, the transfer operation will fail.

• The new KM must assume the responsibilities of the KM role once it has successfully established access to all keys. All the information it needs to be the KM is available in the signing metadata and is accessible to this server. The new KM then edits the signing metadata file, makes itself the key master, and notifies the Domain Naming FSMO role holder. If the Domain Naming FSMO role holder is not reachable, the transfer will fail.

• The old KM, upon receiving this notification, decommissions itself as the KM and goes back to being a peer master server.

• Meanwhile, the signing metadata replicates to all master servers, and each master now knows that a KM role transfer has taken place.

35


Transfer of the KM Role for Disaster RecoveryIn scenarios where the key master goes offline because of a disaster situation, the administrator must transfer the KM role to another master server. The following steps outline the process of seizing the KM role in this scenario.

• The administrator accesses the server intended as the new KM through the DNS Manager console. The administrator launches the DNSSEC Properties UI, and in the context of the zone for which the KM role is being transferred, selects “Use the following DNS server as the key master:”

• The new KM looks up the signing metadata and obtains the identity of the original KM. The new KM tries to contact the original role owner. If it is not reachable, it will proceed with the transfer.

• The server then tries to gain access to the keys. It looks up the signing metadata to determine where the original key master has stored the private KSK.

• If the new key master is not able to access the private keys for some reason, the transfer operation will fail.

• The new KM must assume the responsibilities of the KM role once it has successfully established access to all keys. All the information it needs to be the KM is available in the signing metadata and is accessible to this server. The new KM then edits the signing metadata file, makes itself the key master, and notifies the Domain Naming FSMO role holder. If the Domain Naming FSMO role holder is not reachable, the transfer will fail.

• The signing metadata replicates to all master servers, and each master now knows that a KM role transfer has taken place.

There is a possibility that the old key master is not available on the network, but is still operational, after the administrator transfers the KM role. Later, if network connectivity to the old KM is restored, the zone would have two key masters. If both KMs have performed a key rollover during this period, the zone will have two private keys trying to perform signing operations. To protect against this, the following steps are taken.

• A key master will perform tasks such as key rollover or DNSKEY signature refresh only after it has successfully contacted the Domain Naming FSMO role holder. The KM will read the metadata from the FSMO holder to ensure that it is still the KM for the given zone. If the KM is not able to contact the FSMO holder, or if it finds that it is not the current KM, these operations will not be performed.

• If later, the old KM comes back online, the system has two key masters. This state is not problematic as it is, but before the old KM performs any key master operation, it will check with the FSMO holder to ensure that it is still the current KM. Since a transfer has already happened, it will no longer consider itself the KM and will cease all KM processes.



Transfer of the KM Role for File-backed ZonesFor file-backed zones, there is only one primary server, which is also the key master. In this scenario, if an administrator wishes to move the KM role, they must also move the role of the primary server. This is essentially a migration involving the following steps.

• Migrate the copy of the signed zone (which the primary will commit to disk)

• Migrate the registry settings

• Migrate the signing metadata

• Re-configure all secondary servers to point to the new primary

The new primary, upon loading the zone, will detect that it is a signed zone and will assume KM role responsibilities.

Manual Key Rollovers There may be situations that require the initiation of key rollovers manually. These can include emergency scenarios or a general requirement to roll the key over in an ad-hoc manner.

Key rollovers can be manually triggered even if automatic key rollovers are enabled. To trigger a manual key rollover:

1. Right click on the zone name whose key(s) is/are to be rolled over. Navigate to the DNSSEC fly-out and select Properties.

2. Navigate to either the KSK or ZSK tab depending on whether a KSK or ZSK is to be rolled over.

3. Select the key to roll over.

4. Select “Rollover” to initiate a manual rollover of that key

Modifying Key and other Signing PropertiesAfter a zone is signed, certain DNSSEC properties can be modified. For instance, keys may be added or removed after the zone is signed.

Switching between NSEC and NSEC3Switching between NSEC and NSEC3 is not expected to be a common scenario, but Windows Server "8" Beta DNSSEC does support making this change. The steps required differ depending on whether the signing algorithm is RSA/SHA-1 or not.

If the signing algorithm is RSA/SHA-1, then the keys will explicitly indicate whether they are RSA/SHA-1 or RSA/SHA-1NSEC3 keys.

37


To switch from NSEC to NSEC3:

1. Launch the DNSSEC properties page

2. Delete the existing KSKs and ZSKs that use the RSA/SHA-1 algorithm

3. Create new KSKs and ZSKs using the RSA/SHA-1NSEC3 algorithm

4. On the Next Secure tab, select NSEC3

5. Hit OK

To switch from NSEC3 to NSEC:

1. Launch the DNSSEC properties page

2. Delete the existing KSKs and ZSKs that use the RSA/SHA-1NSEC3 algorithm

3. Create new KSKs and ZSKs using the RSA/SHA-1 algorithm

4. On the Next Secure tab, select NSEC

5. Hit OK

Note:For both processes described above, you do not need to modify any keys that use other algorithms.

Modifying other parametersIt is also possible to modify a number of other properties after the zone is signed. Right-click the zone and select Properties to modify settings for a zone.



Figure 19 Zone Properties

Unsigning a ZoneIf there are errors in the signing or TA distribution process, or if the zone was signed experimentally and is being reverted, the administrator will need to unsign the zone. This can be done by launching the DNSSEC UI from with the DNS Management console on the key master (or remotely on another server connected to the KM), and selecting the option to Unsign the zone.

39


Figure 20 Unsign Zone Wizard

Through AD replication, the KM notifies other servers that the zone is no longer signed, deletes all signatures and keys from its in-memory copy of the zone, and then loads the unsigned zone. Once the change replicates to other master servers, they each delete all DNSSEC records and signatures from their copy of the zone and reload it as unsigned. Secondary servers and RODCs will receive a copy of the unsigned zone during the next zone transfer.

The parent zone of the zone that has just been unsigned will eventually poll the child zone and will get an unsigned empty response when it queries for the DNSKEY record set. Since this cannot be validated, the parent will not delete the DS set. The administrator must delete the DS record set from the parent manually.

Disabling DNSSECIn emergency situations, one may need to disable DNSSEC functionality either on the authoritative DNS server or on the validating caching resolver.

To disable authoritative DNSSEC functionality, uncheck the below checkbox “Enable DNSSEC Signing”. To disable validation on the caching resolver, uncheck the below checkbox “Enable DNSSEC Trust Anchor”.



Figure 21 Server Properties Advanced Tab

Implementation DetailServices, Executables, DLLs

Binaries changed to support Windows Server "8" Beta DNSSEC functionality are listed in the table below.

Binary Description

Dns.exe DNS server core service process binaryChanges: implementation of online signing, RFC 5011 agent; integration with DKM; service of all new and changed MS-DNSP operations

Dnscmd.exe DNS server command line management toolChanges: make all new and changed MS-DNSP operations available.

DnsMgr.dll DNS Manager console snap-in

41


Binary Description

Changes: online signing wizard and other GUI related to online signing and zone maintenance

DnsPerf.dll DNS server performance counter DLLChanges: new counters for online signing and RFC 5011 agent

DNS Windows PowerShell

DNS server Windows PowerShell providerNew binary: will expose all existing MS-DNSP functionality and all new MS-DNSP functionality required for online signing and other new DNSSEC features

Data Flow

Secure DNS Name Resolution ExampleIn the example below, the DNS client has been provisioned with policy to require IPsec to its local DNS server. IPsec policy and an associated certificate have been deployed to the local DNS server. The local DNS server has been provisioned with a trust anchor for the .mil zone.

Figure 22 Secure DNS Name Resolution Example

1. The DNSSEC-aware non-validating DNS client sends a query for www.abc.mil with the DNSSEC OK (DO) bit set.

2. The local DNS server receives the client query. After first checking the resolver cache, the local DNS server determines that it must send the query to one of its root servers. The server sends a query for www.abc.mil to one of its root servers with the DO bit set.



3. The DNS root server returns an unsigned delegation to mil. The local DNS server caches the delegation to mil, applying standard cache pollution protection rules.

4. The local caching DNS server continues to process the query. Using the delegation to mil, it determines that it must send the query to one of the DNS servers authoritative for mil. The server sends a query with the DO bit set for www.abc.mil to one of the DNS servers for mil.

5. The DNS server for mil returns a signed delegation response, including a DS record, for abc.mil from its local signed authoritative zone. The Authenticated Data (AD) bit is sent in the response to indicate that the data has been validated by the server for mil. The local caching DNS server uses its preconfigured trust anchor to validate the signed delegation. If validation fails, it will abort query processing and return a "Server Failure" response message to the client. If validation passes, it caches the delegation for abc.mil.

6. The local DNS server determines that it must use the cached delegation for abc.mil, but it does not have the DNSKEY record set for abc.mil, so it sends a query with the DO bit set for the abc.mil record set to one of the DNS servers for abc.mil.

7. The abc.mil DNS server returns a signed response with the Authoritative Answer (AA) bit set containing the DNSKEY records for abc.mil. The local DNS server uses the cached DS record to validate this DNSKEY record set. If validation fails, it will abort query processing and return a "Server Failure" response message to the client. If validation succeeds, the DNSKEY record set is cached. The local DNS server has now established an authentication chain from mil to abc.mil.

8. The local DNS server determines that it must use the trusted cached delegation for abc.mil, so it sends a query with the DO bit set for www.abc.mil to one of the authoritative DNS servers for abc.mil.

9. The abc.mil DNS server returns a signed response with the AA bit set. The local caching DNS server uses the cached DNSKEY record set to validate this response. If validation fails, it will abort query processing and return a "Server Failure" response message to the client. If validation succeeds, the record set is cached.

10. The local caching DNS server determines that it has a cached answer to the original query, and so responds to the client query for www.abc.mil. The AD bit is set and DNSSEC records are included in the response.

Automatic Maintenance of Trust AnchorsAdministrators can create and maintain trust anchors automatically within an AD forest. Each signed zone has an optional parameter indicating if the administrator wishes for the zone to have an automatically maintained trust anchor in the forest-wide TA store. When this parameter is set, the KM will create or modify the TA store whenever the zone’s DNSKEY record set is signed, configuring the zone’s new KSK as the forest-wide trust anchor for this zone.

43


Administrators must create TAs manually for trust chains between AD forests. Once created, TAs will be maintained automatically in accordance with RFC 5011. The figure below shows a simple cross-forest example. The administrator has manually created TAs for a zone in the other forest. As each zone executes key rollover, the corresponding TA is automatically updated as per RFC 5011. All Windows Server "8" Beta servers (including RODCs) will act as RFC 5011 agents, that is, they will query for key rollovers and update trust anchors. Windows Server 2008 R2 servers will receive RFC5011 updates if installed alongside Windows Server "8" Beta servers, but will not query for key rollovers or update trust anchors.

Figure 23 Automatic Maintenance of Trust Anchors

Appendices



Client Configuration of NRPTWindows 7 introduced DNSSEC awareness in the DNS resolver client. The Windows DNS client is a non-validating security-aware stub resolver. This means that the DNS client will request validation by setting the DNSSEC OK (DO) bit in DNS queries, but will not perform any validation itself. Instead, it will trust that one or more security-aware DNS servers will perform validation on its behalf.

A security-aware Windows client will only return the results to an application for a query that requested validation if the server indicates that it has successfully performed validation. The server indicates that it has validated the response by setting the Authenticated Data (AD) bit in the query response. If the query fails validation, then no response is returned.

The Name Resolution Policy Table (NRPT) in Windows 7 to provides the ability to support per-namespace DNS resolution settings for DirectAccess and DNSSEC. The NRPT stores mappings from DNS name suffixes or prefixes to policy settings that specify whether DNSSEC based resolution is required. The information stored in the NRPT on the client computer is written via Group Policy to the client's registry.

The DNS client only performs DNSSEC validation on domain names where it is configured to do so by the NRPT. This determines the DNS client’s behavior when issuing queries and processing responses.

• Before issuing name resolution queries, the DNS client will consult the NRPT to determine if any additional DNSSEC flags are to be set in the query.

• It will also check to see if IPsec should be used and what encryption level and certificates are to be used for this process.

• Upon receiving the response, the client will once again consult the NRPT to determine if there are any special processing or policy requirements.

In the absence of the NRPT, such as in the case of down-level clients or clients that have no NRPT configured, the client will operate in a normal fashion and will not issue queries indicating the knowledge of DNSSEC.

Important:A client or server that is not DNSSEC-aware or is not configured to request validation can still submit a DNS query to a DNSSEC-aware server and receive an answer. Signing a zone for DNSSEC does not adversely affect any client resolvers that are not security-aware.

Windows Server "8" Beta includes several updates to the NRPT functionality, including the following.

• Updates to prevent NRPT corruption

• Improved conflict management when merging policies

• Addition of a generic DNS Server column

45


• International Domain Name (IDN) encoding and mapping

Configure NRPT settings by editing the Group Policy settings in Group Policy Management Editor under Computer Configuration | Policies | Windows Settings | Name Resolution Policy.

Note:The client NRPT can also be configured using registry scripts. For an example, see the HYPERLINK "http://technet.microsoft.com/en-us/library/ee649208(WS.10).aspx"NRPT Example Script on TechNet.http://technet.microsoft.com/en-us/library/ee649208(WS.10).aspx

Figure 24 Name Resolution Policy

A DNSSEC policy is defined as a set of rules. Each rule applies only to a specified portion of the DNS namespace.

Follow the below steps to create a new rule:

1. Choose the part of the namespace to which the policy applies. Typically, this will be the name of a signed zone. From the dropdown menu, select the appropriate option:

Option Usage

Suffix The policy applies to all the specified namespace e.g. contoso.com applies to *.contoso.com – anything ending .contoso.com.


http://technet.microsoft.com/en-us/library/ee649208(WS.10).aspx


Option Usage

Prefix The policy applies only to a hostname. This policy will be triggered only if the hostname portion of a DNS query matches the flat name configured here e.g. server1.contoso.com, server1.nwtraders.com etc.

FQDN The policy applies only to the specified host. This is not an FQDN of a domain, but an FQDN of a host computer.

Subnet (IPv4) This configures a policy which applies to reverse IPv4 lookup queries

Subnet (IPv6) This configures a policy which applies to reverse IPv6 lookup queries

Any This configures the default policy.

2. Select the DNSSEC tab

3. Select the checkbox next to Enable DNSSEC in this rule

4. Select the checkbox under Validation.

This means the DNS client will set the DNSSEC OK (DO) bit in queries that match this rule, and will check that any response includes the Authenticated Data (AD) bit.

5. Select the IPsec checkbox if IPsec is to be used to protect these DNS queries, and if encryption is to be used select the appropriate IPsec encryption level.

6. Click Create to add this rule to the policy table. The rule will be displayed in the table at the bottom of the screen.

7. Repeat steps 1 through 6 to add additional rules for more areas of the namespace.

47

Understand and Troubleshoot DNSSEC in Windows...

Documents

Transcript of Understand and Troubleshoot DNSSEC in Windows...