DNS Enhancements in Windows Server 2008 R2

DNS is our trusted guide to the digital world. When we access a server by name, we're trusting DNS to give us the IP address of the correct destination. If our DNS infrastructure is compromised, names might be resolved to malicious hosts, which could capture sensitive information and credentials, distribute misinformation, or just disrupt our access to services.

Today’s infrastructure houses highly sensitive information and forms the backbone of many businesses, so we need something more. Confidence in our DNS infrastructure and the information it provides is crucial to maintaining an organization's security and integrity. With Windows Server 2008 R2, we have some very powerful technologies with which to gain this confidence. Let's start with a little background, then see what new enhancements such as DNS Security Extensions (DNSSEC) can provide.

Traditional DNS Shortcomings

With traditional DNS, clients can perform only basic checks to determine whether DNS responses have been spoofed. A client can check whether the DNS server address matches the expected address; however, this capability is often disabled due to network infrastructure configurations. This check is also easy to fake: The port used in the response needs to match the client request's port, which is easy to guess.

Even with new Server 2008 R2 DNS enhancements to source-port randomization, the risk isn't mitigated so much as the time required for an attack is increased. The random XID value sent by the client (included in the response) is sent in clear text, so it's easy to duplicate. Also, in traditional DNS, the client's query is echoed back, but if a technology is smart enough to capture the request and spoof a response, echoing back the initial response is easy.

There's no checksum within the DNS response—say, to ensure that the content of the response hasn't been altered. So, man-in-the-middle attacks can modify the content as it's transmitted to the client. Also, consider that many of our DNS results don't come from the authoritative DNS server; rather, they come from an in-between DNS server that has a cached lookup and returns the information in the cache. Many hackers poison the cache of DNS servers by bombarding them with false records.

DNSSEC for All

DNS Security Extensions (DNSSEC) isn't a proprietary Microsoft technology but rather an Internet-standard extension to DNS defined in RFCs 4033, 4034, and 4035 that Microsoft has implemented as part of the Server 2008 R2 DNS role. An earlier version of DNSSEC was defined in RFC 2535, but it's been replaced by the aforementioned RFCs and implementations that follow RFC 2535. Windows 2003 Server and even Server 2008 aren't compatible with the Windows 2008 R2 implementation.

At its most basic level, DNSSEC assures the integrity of the DNS infrastructure through technologies that verify the authenticity of received data, including authenticated denial-of-existence responses. Assurance is enabled through public key cryptography, which enables the use of digital signatures on all DNS responses. A successful digital signature validation means that the data received is genuine and can be trusted. The digital signature is generated using the DNS zone's private key (which is kept secret) and the content of the record, and can be validated with the public key. If a packet is generated from a malicious source, its digital signature will fail; if a packet has been modified, the signature will no longer match the content.

Facilitating this public key cryptography are several new DNS record types—specifically, DNS Public Key (DNSKEY), which is a container for a DNS zone's public key; Resource Record Signature (RRSIG), which contains the digital signature of a DNS response; Delegation Signer (DS), which is used between a child and parent zone that are both DNSSEC-enabled; and Next Secure (NSEC), which allows authenticated denial-of-existence records by effectively returning the name that would be prior to the non-existent requested name (if they were in alphabetical order) and notifying what the next secure record would be. For example, if you had records A and E in your DNS zone, and you were asked for record C, the response would be A NSEC E with a signature, thereby notifying you that the asked-for record doesn't exist because there are no records between A and E.

The critical element is the trust. The client must trust the zone's public key because the public key is used to authenticate the response by decrypting the signature, which was created using the private key. Ensuring that clients trust only the “real” authoritative DNS zone owner is achieved through chains of trust.

In an ideal world, this PKI hierarchy would be self-contained in the DNS hierarchy in that the root of DNS—“.”—would be DNSSEC-enabled and globally trusted by all clients, Then, the root could sign the top-level domain names (e.g., com, net, org), which could then sign their subordinate domains (e.g., company.com), thereby creating a trust path. This means that clients would need only to trust the root zone, since the root zone is used to authenticate all the other child zones. In Figure 1's example, .net is DNSSEC-enabled, so any child zone that is signed by the .net parent would be trusted by any DNS client that trusts .net.

Figure 1: Setting the trust anchor

You see this today with normal public key infrastructure (PKI) certificates. Most computers are configured to trust certain Internet root certificate authorities (CAs), such as VeriSign, Thawte, and Equifax. These authorities then grant certificates to sites, and the certificates are signed by the root CAs. Because clients trust the root CA, they trust certificates signed by a CA that has effectively been vouched for by the root authorities they trust. DNS works the same way: Clients trust the root and top-level domains (assuming the root and top-level domains are the trust anchors), which will then authenticate the child sites.

At this time, the DNS root zone doesn't support DNSSEC, and neither does COM, but this will change in the near future as the use of DNSSEC is being mandated by many governments around the world. The DNS root will be DNSSEC-enabled in mid-2010, and COM some time in 2011 or 2012. Therefore, we need an interim solution to enable clients to trust the DNS zones that are DNSSEC-enabled.

Whenever we talk about digital signatures, we need a mechanism for clients to be able to validate the signature. This is achieved through public key cryptography. A public key for the secured DNS zone is available for clients to use to validate the digital signature that was generated using the DNS zone's private key. This public key at the root of a DNSSEC trusted namespace—for example, .net—is known as the trust anchor; it’s the anchor of trust between the client and DNS namespace. If a client has a trust anchor to a zone, the client builds a chain of authentication to any child zone of the trust anchor, removing the need for DNS clients to explicitly trust every zone within a namespace. Don’t panic, though: You don't need a full PKI deployed in your environment. The public keys for the security zones are actually stored within the DNS infrastructure, but how do you know who to trust? How do you get valid trust anchors since the root DNS zone can't sign?

Through a process called DNSEC Lookaside Validation (DLV), public keys can be configured to be trusted by DNS clients. There are repositories on the Internet that allow DNSSEC-enabled zones to upload their public keys, which clients can then use. These public repositories are trust anchors on the clients. We trust these repositories to do the right thing and make sure the public keys they store are legitimate—the same way we trust Verisign to ensure that a company is genuine before giving them SSL or code signing certificates. An organization can download the content of this repository, and Active Directory (AD) can replicate the DNSSEC information downloaded to all DNS servers. (DLV isn’t supported in Server 2008 R2.)

Figure 2: Trusting DNS responses

Alternatively, you can manually configure trust anchors within DNS by specifying a zone name and specifying the public key that zone name servers give, as Figure 2 shows. When the entry point for a trust chain (i.e., a trust anchor)is being configured, and you’re specifying the key signing key (more on this later), you would check the Secure Entry Point (SEP) option in addition to the zone signing key. If you want to share your public key so that another organization or repository can add it as a trust anchor, that organization will need the content of the %systemroot%System32dnskeyset- file, as you see in Figure 3.

Figure 3: Sharing the public key

This functionality isn’t between a DNS client (e.g., your workstation) and the authoritative DNS server for the lookup you’re performing. We can’t actually define trust anchors on a DNS client! In fact, even though I’ve been using the term DNS client, DNSSEC is actually more important between DNS servers. In the typical DNS-resolution flow, you ask your local DNS server and it recursively looks up the answer, so your DNS server is the component that needs to validate responses. In most environments, the client won’t perform DNSSEC validation; it relies on its DNS server to do that by asking the DNS server to use DNSSEC.

To provide maximum protection for end clients, best practice is to use IPsec to authenticate the data and perhaps encrypt communication between the client and the local DNS server. This method ensures no local corruption of data from the DNS server to the client.

To configure the DNS clients’ expectation of DNSSEC, you use the Name Resolution Policy Table (NRPT), which is what determines how security should be used for DNS, whether you have entries for various DNS namespaces (e.g., microsoft.com), whether DNSSEC validation is required for each namespace, and whether IPsec should be used between the client and its next DNS hop (i.e., the client’s local DNS server). You typically manage NRPT through Group Policy instead of trying to manually configure it across many clients. Figure 4 shows a sample policy. Note that you can base your NRPT on more than just the DNS suffix: You can use prefix, fully qualified domain name (FQDN), and subnet.

Figure 4: Specifying DNSSEC requirements for a DNS zone

Now that you understand how DNSSEC ensures DNS responses are genuine, how do you get it? In the Microsoft world, you need your DNS servers to run Server 2008 R2 and your clients to run Windows 7, and because of the way DNSSEC functions, there are some restrictions on its use. You aren’t going to turn DNSSEC on for every record in your organization; you’ll use DNSSEC to secure records that are used with a wider, Internet-focused audience, such as your secure website address. A zone that is digitally signed with DNSSEC will no longer accept any dynamic updates, which most environments use for their hosts to register their host-to-IP mappings without any manual intervention. Therefore, you’ll create a separate zone to use for your secure records, in addition to a zone facing the Internet for dynamic updates. Every DNS server that hosts a copy of the signed zone must be running Server 2008 R2, and you need to ensure that your network can handle the increased DNS packet size that comes with DNSSEC enablement. For example, ensure that you have support for Extended DNS 0 (EDNS0), which permits DNS packets up to 4KB instead of the standard 512 bytes.

To enable DNSSEC on your Server 2008 R2 zones, you use DnsCmd utility to generate the key signing keys and zone signing keys, and store them in the local computer’s certificate store (MS-DNSSEC). The zone signing key (ZSK in the code below) signs all the records in the zone, and the key signing key (KSK in the code) signs only other keys, such as the ZSK. You also need to create the DNSSEC resource records at the root of the trust chain. To create my certificates, for example, I perform the following:

dnscmd /offlinesign /genkey /alg rsasha1 /flags KSK /length 2048 /zone secure.savilltech.com /SSCert /FriendlyName KSK- secure.savilltech.com
dnscmd /offlinesign /genkey /alg rsasha1 /length 2048 /zone secure.savilltech.com /SSCert /FriendlyName ZSK- secure.savilltech.com

For your AD-integrated zones, you need to export the zone to a file, sign the file-based zone with your certificates, and save to a new file. Then, you need to delete the existing zone, import the new signed zone file, and reset to be AD integrated. Here are the major steps I used in my environment after creating the aforementioned certificates:

dnscmd /zoneexport secure.savilltech.net securesavilltechnet.dns
dnscmd /offlinesign /signzone /input securesavilltechnet.dns /output       securesavilltechnetsigned.dns /zone secure.savilltech.net      /signkey /cert /friendlyname KSK-secure.savilltech.net /signkey   /cert /friendlyname ZSK-secure.savilltech.netdnscmd /zonedelete secure.savilltech.net /dsdel /f
dnscmd /zoneadd secure.savilltech.net /primary /file       securesavilltechnetsigned.dns /load
dnscmd /zoneresettype secure.savilltech.net /dsprimary

Figure 5 shows our various DNSSEC-related entries.

Figure 5: DNSSEC-related entries

Implementing DNSSEC involves many steps, and keeping it running and ensuring that the keys are maintained is similarly time-consuming. The keys we created have a limited lifetime and need to be updated; if we have trust anchors configured, those public keys will change and therefore require updating. I strongly recommend reading the Microsoft article “Deploying DNS Security Extensions (DNSSEC)”—at technet.microsoft.com/en-us/library/ee649268(WS.10).aspx—a great step-by-step guide.

DNS Devolution

DNSSEC is probably the most famous Server 2008 R2 DNS feature, but there are some other useful enhancements. In environments that have a deep DNS namespace, it can sometimes be tricky to know the correct DNS suffix for an address. For example, in my environment, I know the host is called savdalfile01, but I’m a member of dallas.na.savilltech.net, and I’m not sure if savdalfile01 should be savdalfile01.dallas.na.savilltech.net, savdalfile01.na.savilltech.net, or savdalfile01.savilltech.net. In the past, we would define a global suffix list of all the DNS suffixes that should be tried when resolving a name.

Server 2008 R2 and Windows 7 offers an update to a key feature—DNS Devolution—that lets DNS resolution requests traverse up the DNS namespace until a match is found or until a certain number of devolutions is reached. (Every move up the namespace to a parent is a devolution to one level above.) An example would be savdalfile01: With DNS Devolution enabled, when a client attempts to resolve savdalfile01, savdalfile01.dallas.na.savilltech.net would be initially queried, then it would be up to the parent to search for savdalfile01.na.savilltech.net. (It’s checking a third-level devolution because the DNS suffix has three parts—na, savilltech, and net). If there's no match, it's up to that zone's parent to look for savdalfile01.savilltech.net (which now has a devolution level of 2, as this DNS suffix has twoparts). Basically, it allows a member of a child namespace to access resources in the parent without having to specify the parent’s namespace as part of the DNS query.

New to the Server 2008 R2 and Windows 7 DNS client is the ability to set a devolution level. As an administrator, you can define whether DNS devolution is enabled and which DNS devolution level you’ll devolve down to. For example, setting a devolution level of 2 means you would devolve down to the two-part Forest Root Domain (FRD) second-level domain (e.g., savilltech.net). Setting a devolution level of 3 means you would devolve only to the third-level DNS domain (e.g., na.savilltech.net).

You can configure DNS Devolution using Group Policy, through the Primary DNS Suffix Devolution and Primary DNS Suffix Devolution Level policies found at Computer ConfigurationPoliciesAdministrativeTemplatesNetworkDNS Client, as Figure 6 shows. You can also set DNS Devolution directly in the registry with the HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTDNSClientUseDomainNameDevolution and HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDnscacheParametersDomainNameDevolutionLevel subkeys.

Figure 6: Setting the DNS devolution level

This functionality is useful in environments that have multiple levels of DNS namespace. The Microsoft security advisory “Update for DNS Devolution” (www.microsoft.com/technet/security/advisory/971888.mspx) offers an update for older versions of Windows.

DNS Cache Locking

At the beginning of this article, I mentioned that one DNS vulnerability was that DNS servers cache entries for recursive lookups (lookups for records they aren’t authoritative for, and for which they have to consult other DNS servers) they've performed to speed up future lookup requests for the same information. Those lookups have a specific time to live (TTL) before the record must be rechecked to see if it’s changed. The exploit uses DNS cache poisoning to send incorrect responses to a DNS server to try and update that cache so that clients using the server will receive incorrect information.

DNS Cache Locking is a new Server 2008 R2 feature that helps mitigate cache poisoning: It locks the entries in the cache for the record’s TTL. So, if someone tries to poison the cache with a replacement record, the DNS server will ignore it and thus maintain the integrity of the cache content.

To use Cache Locking, you set a percentage of the TTL of records that the cache content is locked for—for example, a setting of 75 means that cached records can’t be overwritten until 75 percent of their TTL has passed. The default value is 100, which means records can’t be updated until the TTL has expired. However, you can change this by setting’s registry value at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDNSParametersCacheLockingPercent to our desired percentage. Note that if this value isn’t present, the default of 100 is used.

More on the NRPT

I already discussed how the NRPT helps define the way clients and servers act for different DNS zone requests. You have numerous entries in the NRPT, and if a DNS query matches an entry in it, the query is handled according to the configuration of the matching NRPT entry. If no match is found, the system performs default DNS handling.

In addition to DNSSEC, the NRPT is used for one other key piece of Windows 7 and Server 2008 R2 functionality—namely, DirectAccess, which is the new technology that lets Windows 7 clients communicate with corporate resources no matter where they are on the Internet, without having to use VPNs. The client just accesses a corporate resource, and DirectAccess facilitates secure communicate back to the corporate network.

This automatic use of DirectAccess to get to resources raises an important question: How does the Windows 7 client know which destinations in the corporate network should be accessed through DirectAccess and which should just use normal Internet connectivity? I don’t want my Amazon purchases to be sent via my corporate network when I’m sitting at home or at Starbucks.

This decision is based on the Name Resolution Policy Table and in the same way we can define DNSSEC actions for various DNS name and IP values we can do exactly the same thing for DirectAccess using the DirectAccess tab as shown in Figure 7. If you want to check a machine's Group Policy rules, you'll find them at HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTDNSClientDnsPolicyConfig. You can also create exceptions, which let you create general rules for an entire namespace but then treat a particular host or namespace portion differently.

Figure 7: Enabling the use of DirectAccess

Server 2008 R2 brings you a very powerful DNS service that adheres to some of the most recent specifications. You should definitely consider Server 2008 R2 DNS to be the secure release and use it to replace previous Microsoft DNS services to offer maximum protection. DNS is your trusted advisor to the computer world, so make sure it can really be trusted!