7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 1/7

DNS Enhancements in Windows Server 2008 R2DNSSEC, DNS Devolution, and DNS Cache Locking introduce a new world of secure communications  

DNS is our trusted guide to the digital world. When we access a server by name, we're trusting DNS to give us the IPaddress 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 needsomething more. Confidence in our DNS infrastructure and the information it provides is crucial to maintaining anorganization's security and integrity. With Windows Server 2008 R2, we have some very powerful technologies with which togain 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. Aclient can check whether the DNS server address matches the expected address; however, this capability is often disableddue to network infrastructure configurations. This check is also easy to fake: The port used in the response needs to matchthe 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 thetime 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 enoughto 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 DNSresults don't come from the authoritative DNS server; rather, they come from an in-between DNS server that has a cachedlookup and returns the information in the cache. Many hackers poison the cache of DNS servers by bombarding them withfalse records.

 

DNSSEC for All

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

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

Facilitating this public key cryptography are several new DNS record types—specifically, DNS Public Key (DNSKEY), whichis a container for a DNS zone's public key; Resource Record Signature (RRSIG), which contains the digital signature of aDNS 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 thatwould be prior to the non-existent requested name (if they were in alphabetical order) and notifying what the next securerecord would be. For example, if you had records A and E in your DNS zone, and you were asked for record C, theresponse would be A NSEC E with a signature, thereby notifying you that the asked-for record doesn't exist because thereare no records between A and E.

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 2/7

The critical element is the trust. The client must trust the zone's public key because the public key is used to authenticate theresponse 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 beDNSSEC-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 Figure1's example, .net is DNSSEC-enabled, so any child zone that is signed by the .net parent would be trusted by any DNSclient 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 certainInternet root certificate authorities (CAs), such as VeriSign, Thawte, and Equifax. These authorities then grant certificates tosites, and the certificates are signed by the root CAs. Because clients trust the root CA, they trust certificates signed by a CAthat has effectively been vouched for by the root authorities they trust. DNS works the same way: Clients trust the root andtop-level domains (assuming the root and top-level domains are the trust anchors), which will then authenticate the childsites.

 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 inmid-2010, and COM some time in 2011 or 2012. Therefore, we need an interim solution to enable clients to trust the DNSzones that are DNSSEC-enabled.

Whenever we talk about digital signatures, we need a mechanism for clients to be able to validate the signature. This isachieved through public key cryptography. A public key for the secured DNS zone is available for clients to use to validatethe digital signature that was generated using the DNS zone's private key. This public key at the root of a DNSSEC trustednamespace—for example, .net—is known as the trust anchor ; it’s the anchor of trust between the client and DNSnamespace. If a client has a trust anchor to a zone, the client builds a chain of authentication to any child zone of the trustanchor, removing the need for DNS clients to explicitly trust every zone within a namespace. Don’t panic, though: You don't

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 3/7

need a full PKI deployed in your environment. The public keys for the security zones are actually stored within the DNSinfrastructure, 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 thenuse. These public repositories are trust anchors on the clients. We trust these repositories to do the right thing and makesure 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 ActiveDirectory (AD) can replicate the DNSSEC information downloaded to all DNS servers. (DLV isn’t supported in Server 2008R2.)

Figure 2: Trusting DNS responses

 

 Alternatively, you can manually configure trust anchors within DNS by specifying a zone name and specifying the public keythat zone name servers give, as Figure 2 shows. When the entry point for a trust chain (i.e., a trust anchor)is beingconfigured, 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 canadd it as a trust anchor, that organization will need the content of the %systemroot%\System32\dns\keyset-<zone name>file, as you see in Figure 3.

 

Figure 3: Sharing the public key

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 4/7

 

This functionality isn’t between a DNS client (e.g., your workstation) and the authoritative DNS server for the lookup you’reperforming. 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 DNSserver and it recursively looks up the answer, so your DNS server is the component that needs to validate responses. Inmost 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 encryptcommunication between the client and the local DNS server. This method ensures no local corruption of data from the DNSserver to the client.

To configure the DNS clients’ expectation of DNSSEC, you use the Name Resolution Policy Table (NRPT), which is whatdetermines 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 betweenthe client and its next DNS hop (i.e., the client’s local DNS server). You typically manage NRPT through Group Policyinstead 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, youneed your DNS servers to run Server 2008 R2 and your clients to run Windows 7, and because of the way DNSSECfunctions, 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 websiteaddress. A zone that is digitally signed with DNSSEC will no longer accept any dynamic updates, which most environmentsuse for their hosts to register their host-to-IP mappings without any manual intervention. Therefore, you’ll create a separatezone to use for your secure records, in addition to a zone facing the Internet for dynamic updates. Every DNS server thathosts a copy of the signed zone must be running Server 2008 R2, and you need to ensure that your network can handle theincreased DNS packet size that comes with DNSSEC enablement. For example, ensure that you have support for ExtendedDNS 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 zonesigning keys, and store them in the local computer’s certificate store (MS-DNSSEC). The zone signing key (ZSK in the codebelow) 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, Iperform the following:

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

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 5/7

For your AD-integrated zones, you need to export the zone to a file, sign the file-based zone with your certificates, and saveto 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.dnsdnscmd /offlinesign /signzone /input securesavilltechnet.dns /outputsecuresavilltechnetsigned.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 /filesecuresavilltechnetsigned.dns /loaddnscmd /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 similarlytime-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 “DeployingDNS Security Extensions (DNSSEC)”—at technet.microsoft.com/en-us/library/ee649268(WS.10).aspx—a great step-by-stepguide.

 

DNS Devolution

DNSSEC is probably the most famous Server 2008 R2 DNS feature, but there are some other useful enhancements. Inenvironments 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’mnot 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 requeststraverse up the DNS namespace until a match is found or until a certain number of devolutions is reached. (Every move upthe namespace to a parent is a devolution to one level above.) An example would be savdalfile01: With DNS Devolutionenabled, when a client attempts to resolve savdalfile01, savdalfile01.dallas.na.savilltech.net would be initially queried, then itwould be up to the parent to search for savdalfile01.na.savilltech.net. (It’s checking a third-level devolution because the DNSsuffix 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 amember of a child namespace to access resources in the parent without having to specify the parent’s namespace as part of the DNS query.

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 6/7

New to the Server 2008 R2 and Windows 7 DNS client is the ability to set a devolution level. As an administrator, you candefine whether DNS devolution is enabled and which DNS devolution level you’ll devolve down to. For example, setting adevolution 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 Configuration\Policies\Administrative\Templates\Network\DNS Client, as Figure6 shows. You can also set DNS Devolution directly in the registry with theHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\UseDomainNameDevolution andHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters\DomainNameDevolutionLevelsubkeys.

 

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.

InstantDoc ID #125360

DNS Cache Locking

 At the beginning of this article, I mentioned that one DNS vulnerability was that DNS servers cache entries for recursivelookups (lookups for records they aren’t authoritative for, and for which they have to consult other DNS servers) they'veperformed 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 incorrectresponses 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 cachefor the record’s TTL. So, if someone tries to poison the cache with a replacement record, the DNS server will ignore it andthus 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, asetting of 75 means that cached records can’t be overwritten until 75 percent of their TTL has passed. The default value is100, which means records can’t be updated until the TTL has expired. However, you can change this by setting’s registryvalue at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\CacheLockingPercent to our desired percentage. Note that if this value isn’t present, the default of 100 is used.

7/28/2019 DNS Enhancements in Windows Server 2008 R2

http://slidepdf.com/reader/full/dns-enhancements-in-windows-server-2008-r2 7/7

 

More on the NRPT

I already discussed how the NRPT helps define the way clients and servers act for different DNS zone requests. You havenumerous entries in the NRPT, and if a DNS query matches an entry in it, the query is handled according to theconfiguration 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, andDirectAccess 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 knowwhich destinations in the corporate network should be accessed through DirectAccess and which should just use normalInternet connectivity? I don’t want my Amazon purchases to be sent via my corporate network when I’m sitting at home or atStarbucks.

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 inFigure 7. If you want to check a machine's Group Policy rules, you'll find them atHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. You can also create

exceptions, which let you create general rules for an entire namespace but then treat a particular host or namespace portiondifferently.

 

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 shoulddefinitely consider Server 2008 R2 DNS to be the secure release and use it to replace previous Microsoft DNS services tooffer maximum protection. DNS is your trusted advisor to the computer world, so make sure it can really be trusted!