.png)
Overview of DNSSEC
Published: June 29, 2012
Updated: June 29, 2012
Applies To: Windows Server 2012
In environments that do not employ security technologies such as IPsec or HTTPS, the DNS protocol can be vulnerable to attack due to an inherent lack of authentication and integrity checking of data that is exchanged between DNS servers or provided to DNS clients. Domain Name System Security Extensions (DNSSEC) is a suite of extensions that adds security to the DNS protocol by providing the ability for DNS servers to validate DNS responses. With DNSSEC, resource records are accompanied by digital signatures. These digital signatures are generated when DNSSEC is applied to a DNS zone using a process called zone signing. When a resolver issues a DNS query for resource record in a signed zone, a digital signature is returned with the response so that validation can be performed. If validation is successful, this proves that the data has not been modified or tampered with in any way.
DNSSEC uses digital signatures and cryptographic keys to validate that DNS responses are authentic. The following sections briefly explore how these signatures are managed and how validation is performed.
Signatures that are generated with DNSSEC are contained within the DNS zone in new resource records. These new resource records are called RRSIG (resource record signature) records. When a resolver issues a query for a name, one or more RRSIG records are returned in the response. A public cryptographic key that is stored in a DNSKEY resource record is used to verify the signature. The DNSKEY record is retrieved by a DNS server during the validation process.
When you sign a zone with DNSSEC, you are individually signing all the records that are contained in the zone. Because each record is individually signed, you can add, modify, or delete records in the zone without re-signing the entire zone. It is only necessary to re-sign the updated records.
If the DNS server responds to a query that no matching resource record was found, this response also needs to be validated as authentic. However, because there is no resource record, there is no RRSIG record. The answer to this problem is the Next Secure (NSEC) record. NSEC records create a chain of links between signed resource records. A validator can use the NSEC record as proof that the name does not exist, or that the name exists but does not contain any records of the requested type. This is called authenticated denial-of-existence.
NSEC3 is a replacement or alternative to NSEC that has the additional benefit of preventing “zone walking,” which is the process of repeating NSEC queries to retrieve all the names in a zone. A DNS server running Windows Server® 2012 supports NSEC and NSEC3. A zone can be signed with NSEC or NSEC3, but not both.
A trust anchor is a preconfigured public key that is associated with a specific zone. A validating DNS server must be configured with one or more trust anchors to perform validation. A trust anchor allows the DNS server to validate DNSKEY resource records for the corresponding zone and establish a chain of trust to child zones, if these exist. If the DNS server is running on a domain controller, trust anchors can be stored in the forest directory partition in Active Directory Domain Services (AD DS). If you choose this option, they are replicated to all DNS servers that run on domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS server running Windows Server 2012 displays configured trust anchors in the DNS Manager console tree in the Trust Points container. You can also use Windows PowerShell or Dnscmd.exe to view trust anchors. Windows PowerShell is the recommended command line method for viewing trust anchors.
A DNSSEC key management strategy includes planning for key generation, key storage, key expiration, and key replacement. Together, key expiration and replacement in DNSSEC is called key rollover. In Windows Server 2012, key management is made easier with simple and flexible key generation, Active Directory storage and replication, an automated key rollover.
Windows Server 2012 introduces the concept of a DNSSEC Key Master. The Key Master is a DNS server that generates and manages signing keys for a zone that is protected with DNSSEC. Any authoritative DNS server running Windows Server 2012 that hosts a primary copy of the zone can be the Key Master. Each zone can have a different Key Master, or a single server can function as the Key Master for multiple zones. You must choose a Key Master when you first sign the zone with DNSSEC. You can choose to transfer the Key Master role to another server that hosts the zone later, if desired.
To sign a zone with DNSSEC, you must choose at least one zone signing key (ZSK) and one key signing key (KSK). Multiple keys are also supported. Typically, a zone is signed with a single ZSK and a single KSK. You might use more than one key to sign a zone under the following circumstances:
-
All DNS validators do not support a single cryptographic algorithm
-
You are transitioning the DNS infrastructure to a use new signing key properties
-
You are merging DNS zones or network elements that use different signing key properties
The key signing key, or KSK, is an authentication key that signs all of the DNSKEY records at the root of the zone, and it is part of the chain of trust.
When you generate a new KSK, the Key Master can create an active and a standby key. Properties for the KSK include the following:
-
Cryptographic algorithm: By default, the RSA/SHA-1 (NSEC3) algorithm is chosen. To sign a zone with NSEC3, you cannot choose the RSA/SHA-1 algorithm (RSA/SHA-1 (NSEC3) and RSA/SHA-1 are two different available algorithms).
-
Key length: By default, this is 2048 bits for keys that use the RSA/SHA-1 (NSEC3) algorithm. Typically, the KSK will have a longer key length than a ZSK for greater security. The KSK key length affects the time that is required for zone signing less than the ZSK key length.
-
Key storage provider: If keys will be distributed by using Active Directory Domain Services, you must choose Microsoft Software Key Storage Provider.
-
DNSKEY RRSET signature validity period: By default, this is set to 72 hours. Signatures that are generated using the KSK might have a longer validity period than signatures that are generated by the ZSK to provide a more stable secure entry point into the zone.
-
Key rollover: You can choose whether to use automatic rollover and supply a rollover frequency. Automatic key rollover is highly recommended. You can also delay the first rollover by a specified number of days.
The zone signing key, or ZSK, is used to sign zone data. A ZSK is typically rolled over more frequently than a KSK. Properties for the ZSK include the following:
-
Cryptographic algorithm: By default, the RSA/SHA-1 (NSEC3) algorithm is chosen. To sign a zone with NSEC3, you cannot choose the RSA/SHA-1 algorithm (RSA/SHA-1 (NSEC3) and RSA/SHA-1 are two different available algorithms). The algorithm you choose can affect the time required for zone signing.
-
Key length: By default, this is 1024 bits for keys that use the RSA/SHA-1 (NSEC3) algorithm. Typically, the ZSK will have a shorter key length than a KSK. The ZSK key length can affect the time required for zone signing.
-
Key storage provider: If keys will be distributed by using Active Directory Domain Services, you must choose Microsoft Software Key Storage Provider.
-
DNSKEY signature validity period: By default, this is set to 72 hours.
-
DS signature validity period: By default this is set to 72 hours.
-
Zone record validity period: By default this is set to 240 hours.
In Windows® 8 and Windows Server 2012 the DNS Client service continues to be non-validating and security-aware, which is the same as computers running Windows 7 and Windows Server 2008 R2. When the DNS client receives a response to a DNS query, it can examine the response to tell whether or not it has been validated by a DNS server. The DNS client itself is non-validating. When issuing queries, the DNS client relies on the local DNS server to indicate that validation was successful. If the server fails to perform validation, the DNS Client service can be configured to return no results. If validation is unsuccessful on the DNS server, no results are returned to the DNS client.
The Name Resolution Policy Table (NRPT) is a table that contains rules that you can configure to specify DNS settings or special behavior for names or namespaces. The NRPT can be configured by using Group Policy or by using Windows PowerShell.
When performing DNS name resolution, the DNS Client service checks the NRPT before sending a DNS query. If a DNS query matches an entry in the NRPT, it is handled according to settings in the policy. Queries that do not match an NRPT entry are processed normally. You can use the NRPT to require that DNSSEC validation is performed on DNS responses for queries in the namespaces that you specify.
See Also
