Installing and Configuring Windows Server 2012 Training Guide: Network Administration

Lesson 2: Implementing DNSSEC

DNS provides a user-friendly way of naming hosts and services on a TCP/IP network. DNS servers perform name resolution to convert DNS names into IP addresses so that DNS clients can access network services. DNS servers thus play a critical role in enabling users and applications to locate hosts and services on the network or on the Internet. However, no authentication or integrity checking is done when name resolution is being performed using traditional DNS. As a result, communications between DNS clients and servers is inherently insecure, and by spoofing DNS traffic or otherwise poisoning the DNS cache on clients, an attacker could hijack network communications and redirect users and applications to malicious sites and services.

To help organizations address this problem, Windows Server 2012 includes enhanced support for DNS Security Extensions (DNSSEC), a suite of extensions that add security to the DNS protocol by enabling DNS servers to validate DNS responses. In a practical sense, this enables users to be confident that the site they are accessing on their corporate intranet is in fact the site they believe it to be, and not some malicious site masquerading as a legitimate site. This lesson helps you understand the benefits of DNSSEC, how it works, and how to implement it in an Active Directory environment based on Windows Server 2012.

Benefits of DNSSEC

DNS is used for locating resources on a TCP/IP network and the Internet. For example, when a user types www.bing.com into the address bar of Internet Explorer, the DNS client on the user’s computer sends a name query request to a DNS server. The DNS server then either responds with the IP address for the site being accessed (Bing) or forwards the query to another DNS server for consideration. When the client has the site’s IP address, it can access the site to download content.

But the question arises, how can the user or application be confident that the site being accessed is genuine and not some fake site masquerading as the real one? To a certain extent, the Secure Sockets Layer (SSL) protocol already does this. SSL is used whenever the user or application accesses a resource using Secure HTTP (HTTPS).SSL does this by authenticating the site being accessed and encrypting the data returned over the network. However, SSL is of no use if the DNS server being queried returns a spoofed IP address instead of the real one. This could be accomplished, for example, if a malicious DNS server intercepted name-resolution traffic and inserted a spoofed response to a query from a DNS client or a recursive DNS server. And not only could such an attack hijack a particular DNS session, it would also poison the local DNS cache on the client server, recursive server, or both, which could lead to further erroneous responses to name-resolution requests until the cache data expired.

To address these issues, the Internet Engineering Task Force (IETF) developed DNSSEC to add a layer of security to the inherently insecure DNS protocol. Specifically, DNSSEC helps prove two things:

• The information the client is accessing is coming from the correct source. In other words, it confirms the authority of the originator of the data being returned by a DNS server.
• The information you have received is the same as the information that was sent. In other words, it confirms the integrity of the data being returned by a DNS server.

DNSSEC also provides authenticated denial of existence when the information the client is trying to access does not exist. In other words, it provides proof that the site being requested really doesn’t exist.

What DNSSEC does not provide is confidentiality of the data being returned by a DNS server. In other words, it does not guarantee that the data hasn’t been intercepted and examined while en route to the client. DNSSEC also does not provide any protection against a distributed denial of service (DDoS) attack against an organization’s DNS infrastructure. So while DNSSEC provides two of the requirements of the information security CIA triad (Confidentiality, Integrity, and Availability), it is not in itself a complete solution to the problem of protecting an organization’s DNS infrastructure and traffic.

DNSSEC in previous Windows Server versions

Basic support for DNSSEC was introduced in Windows Server 2003 to allow DNS servers to act as secondary DNS servers for existing DNSSEC-compliant secure zones. Windows Server 2003 DNS servers, however, were not capable of signing zones and resource records or validating the Signature (SIG) resource records. In addition, all DNSSEC configuration had to be performed by editing the registry on DNS servers.

Support for DNSSEC was enhanced in Windows Server 2008 R2 but was limited by being intended as a solution only for file-backed, static zones and not for dynamic Active Directory integrated zones. The DNS server command-line management tool (Dnscmd.exe) could be used to perform offline key generation and zone-signing capability through a signing tool. Windows PowerShell scripts were later released through the TechNet Script Center for performing DNSSEC administration tasks such as signing zones and for adding, rolling over, and verifying trust anchors. However, the DNS client in Windows 7 and Windows Server 2008 R2 is DNSSEC-aware but nonvalidating. In other words, the DNS client can examine a response received from a DNS server to determine whether the response has been validated by the DNS server, but the client cannot itself validate the response it receives from the DNS server. This means that some other method, such as Internet Protocol security (IPsec), must still be used to secure the last mile between the client and its local DNS server, even when DNSSEC has been configured on DNS servers running Windows Server 2008 R2.

Windows Server 2012 now includes full DNSSEC support for Active Directory–integrated DNS scenarios, including DNS dynamic updates in DNSSEC signed zones, automated trust-anchor distribution through Active Directory, automated trust-anchor rollover support per RFC 5011, and validation of records signed with updated DNSSEC standards (NSEC3, RSA/SHA-2). An updated user interface with deployment and management wizards is also included, as well as full Windows PowerShell support for configuring and managing DNSSE. However, the DNS client in Windows 8 and Windows Server 2012 is still DNSSEC-aware but nonvalidating, which means IPsec should still be used to secure the network connecting the client to its local DNS server.

How DNSSEC works

DNSSEC works by combining public key infrastructure (PKI) cryptography with DNS to use digital signatures and cryptographic keys to sign DNS zones and validate that DNS responses are authentic. Figure 6-5 shows the steps involved in the name-resolution process when DNSSEC has been implemented in a Windows Server–based network. The basic steps involved are as follows:

1. A client such as a Windows 8 computer issues a DNS query to its local DNS server.

2. The client’s local DNS server has DNSSEC enabled but is not authoritative for the zone being queried, so it issues a recursive query to the authoritative server for the zone to request an authoritative response.

3. The authoritative server has DNSSEC enabled and is the authoritative server for the zone being queried. This means that the zone has been digitally signed on this server. When the authoritative server receives the recursive query, it returns an authoritative response to the client’s local server. This response includes one or more DNSSEC resource records, which can include the following types:

   • Resource Record Signature (RRSIG) These resource records contain digital signatures for all records in a zone.

   • DNS Public Key (DNSKEY) These resource records contain the public keys for a particular zone.

   • Delegation Signer (DS) These resource records indicate the public key for a child zone.

   • Next Secure (NSEC or NSEC3) These resource records allow the validation of a negative response.

4. The local server uses the public key of the signed zone on the authoritative server to validate the response it received from the authoritative server.

5. The local server returns the requested response to the client that issued the query. The client can now access the network resource represented by the name it was querying for.

Figure 6-5 How DNSSEC works.

Deploying DNSSEC

Deploying DNSSEC using Windows Server 2012 into an existing Active Directory environment involves performing the following steps:

1. Begin by introducing Windows Server 2012 domain controllers into your environment. These domain controllers should also have the DNS Server role and be configured to use Active Directory–integrated zones.

2. DNSSEC is implemented by signing zones on your DNS servers. After deciding which DNS zone to implement DNSSEC on, sign the zone by opening the DNS Manager console, selecting the DNS server, right-clicking on the zone, and selecting DNSSEC, followed by Sign The Zone:

   

3. Follow the prompts of the Zone Signing Wizard to complete the process of signing the zone. The simplest approach is to use the default settings to sign the zone:

   

   For example, selecting this option when signing the corp.contoso.com zone on your first Windows Server 2012 domain controller DC-1.corp.contoso.com would have the following results:

   • The domain controller becomes the key master for the corp.contoso.com zone. The key master is the DNS server that generates and manages signing keys for a zone that is protected with DNSSE

   • A key signing key (KSK) with a length of 2048 bits is generated using the RSA/SHA-256 cryptographic algorithm. The 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. By default, the KSK has a rollover frequency of 755 days, and any DNSKEY records signed using the key have a signature validity of 168 hours. Key rollover and signature refresh are enabled by default on Windows Server 2012 DNS servers.

   • A zone signing key (ZSK) with a length of 1024 bits is generated using the RSA/SHA-256 algorithm. The ZSK is used to sign zone data, such as the SOA, NS, and A resource records found in a typical zone. By default, the ZSK has a rollover frequency of 90 days, and any zone resource records signed using the key have a signature validity of 240 hours. Key rollover and signature refresh are enabled by default on Windows Server 2012 DNS servers.

   • NSEC3 is used by default for providing authenticated denial of existence. The NSEC3 hash algorithm used is RSA/SHA-1 with 50 iterations and a salt length of 8.

   • Trust anchors are not distributed. A trust anchor is a preconfigured public key associated with a specific zone. The trust anchor enables DNS servers to validate DNSKEY resource records for the corresponding zone and establish a chain of trust to child zones, if any exist. Validating DNS servers must be configured with one or more trust anchors in order to perform DNSSEC validation. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory.

4. If the zone you signed is an Active Directory–integrated zone, private zone-signing keys now replicate automatically to all domain controllers hosting the zone through Active Directory replication. Each zone owner signs its own copy of the zone when it receives the key, as long as the zone owner is a domain controller running Windows Server 2012.

   Most of the key-management process is automated for DNSSEC in Windows Server 201. After the key rollover frequency has been configured for a zone using the Zone Signing Wizard, the key master automatically generates new keys and replicates via Active Directory. The zone owner rolls over keys and re-signs the zone, and secure delegations from the parent are also automatically updated within the same forest.

5. At this point, the zone has been signed and contains the necessary RRSIG, DNSKEY, DS, and NSEC3 resource records to support DNSSEC validation:

   

6. When zone data is updated by a client sending a DNS dynamic update to an authoritative DNS server, that DNS server updates its own copy of the zone and generates the required signatures. The unsigned update is then securely replicated to all other authoritative servers, and each DNS server adds the update to its copy of the zone and generates the required signatures.

7. Trust anchors must then be distributed to the DNS servers in your environment to enable the DNSSEC validation process to be performed by nonauthoritative (recursive or caching) DNS servers. If the DNS servers are running on domain controllers, trust anchors are stored in the forest directory partition in Active Directory and are replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns and can be manually imported to these servers using the DNS Manager console or Windows PowerShell.

   For example, the standalone DNS server running Windows Server 2012 shown next displays its configured trust anchors in the DNS Manager console tree in the Trust Points container. Note that two DNSKEY trust points are displayed: one for the active key and one for the standby key.

   

8. Trust Anchor updates are then automatically replicated via Active Directory to all servers in the forest, and automated Trust Anchor rollover is used to keep trust anchors up to date.

9. The final step in deploying DNSSEC is to ensure security between the nonvalidating DNS client (which can be computers running Windows 7, Windows 8, Windows Server 2008 R2, or Windows Server 2012) and their local DNS servers. The recommended way to do this is to use IPsec to protect the last mile between the client and its local DNS server. The DNS clients must also be configured to check that responses have been validated by their local DNS server, and this is done by configuring the Name Resolution Policy Table (NRPT) on the clients. The NRPT is a table that contains rules you can configure to specify DNS settings or special behavior for names or namespaces. The NRPT can be configured by using either Group Policy or Windows PowerShell.

Lesson summary

• DNSSEC is a suite of extensions that add security to the DNS protocol by enabling DNS servers to validate DNS responses.

• DNSSEC confirms the authority of the originator and the integrity of the data being returned.

• DNSSEC provides authenticated denial of existence when the information the client is trying to access does not exist. In other words, it provides proof that the site being requested really doesn’t exist.

• DNSSEC does not provide confidentiality for the data being returned by a DNS server.

• DNSSEC works by combining public key infrastructure (PKI) cryptography with DNS to use digital signatures and cryptographic keys to sign DNS zones and validate that DNS responses are authentic.

• DNSSEC is implemented by signing zones on your DNS servers. Signing a zone adds new resource records of types RRSIG, DNSKEY, DS, and NSEC (or NSEC3) into the zone.

• Most of the key-management process is automated for DNSSEC in Windows Server 2012. However, trust anchors must be manually distributed to standalone DNS servers.

• The DNS client in Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 is DNSSEC-aware but nonvalidating. This means that IPsec should be used to secure the network connecting the client to its local DNS server.

Lesson review

Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. Which of the following is not a correct explanation of a DNSSEC term or concept?

   1. DNSKEY resource records contain the public keys for a particular zone.

   2. Only zones that are authoritative can be signed.

   3. The key signing key (KSK) is used to sign all of the DNSKEY records at the root of the zone.

   4. When zone data is updated by a client sending a DNS dynamic update to an authoritative DNS server, the entire zone must be re-signed.

2. In a Windows Server–based DNS infrastructure where DNSSEC has been implemented, where is the validation of the response to a query performed?

   1. On an authoritative DNS server in the forest root domain

   2. On an authoritative DNS server in a child or tree domain

   3. On a recursive DNS server that is not authoritative for the zone being queried

   4. On the client computer issuing the name query

3. When you want to implement DNSSEC in an Active Directory environment where all DNS servers are domain controllers and use only Active Directory–integrated zones, which of the following steps in the DNSSEC deployment process is not correct?

   1. Begin by introducing Windows Server 2012 domain controllers into your environment.

   2. After deciding which DNS zone to implement DNSSEC on, sign the zone.

   3. Use Robocopy.exe to replicate the private zone-signing keys to all domain controllers hosting the zone.

   4. Use IPsec to protect the last mile between the nonvalidating DNS client and its local DNS server.