The Cable Guy: Changes to the DNS Client Service in Windows 7 and Windows Server 2008 R2

  • Article

Joseph Davies

There are several new, critical factors in the Domain Name System (DNS) Client service in Windows 7 and Windows Server 2008 R2:

  • Changes to name devolution behavior
  • The Name Resolution Policy Table (NRPT)
  • DNS Security (DNSSEC)

Exploring each of these in detail can help you work with the DNS more effectively and efficiently.

Changes to Name Devolution Behavior

Name devolution is a behavior of the DNS Client service in Windows that lets an Active Directory Domain Service (AD DS) user specify a single-label, unqualified name for a resource instead of its fully qualified domain name (FQDN). When name devolution is enabled, Windows appends portions of the computer’s primary domain suffix to the single-label name and sends separate DNS queries for the resulting FQDNs.

For example, a user on a computer that is a member of the corp.contoso.com domain can use the name server1 and name devolution automatically queries server1.corp.contoso.com and server1.contoso.com on the user’s behalf.

Name devolution occurs only for the primary domain suffix. It does not occur when there is no primary domain suffix, for connection-specific DNS suffixes, or when you’ve configured a global suffix search list.

In versions of Windows prior to Windows 7 and Windows Server 2008 R2, name devolution continues to the second-level domain name for the primary domain suffix. For example, if the computer is a member of the wcoast.corp.contoso.com domain and you type ping server1 at a command prompt, the DNS Client service sends separate DNS queries for server1.wcoast.corp.contoso.com, server1.corp.contoso.com, and server1.contoso.com.

The devolution level is the number of labels in the primary domain suffix at which name devolution stops. For versions of Windows prior to Windows 7 and Windows Server 2008 R2 without the Microsoft Security Advisory 971888: Update for DNS Devolution installed, the name devolution level is 2 and you can’t configure that level. That’s a problem.

Security Issues with Devolution Level 2

Devolution to level 2 and new types of Internet names can result in a domain-joined computer connecting with potentially malicious computers on the Internet. For example, if the computer’s primary domain suffix is westcoast.corp.contoso.co.us and the user attempts to connect to server1, DNS name devolution to level 2 tries the following names:

  • server1.westcoast.corp.contoso.co.us
  • server1.corp.contoso.co.us
  • server1.contoso.co.us
  • server1.co.us

The last name attempted, server1.co.us, is outside the control of the Contoso Corporation. If someone has registered server1.co.us, the DNS name resolution will succeed and the computer will attempt a connection. If the owner of the server1.co.us server is malicious, he can try to spoof an intranet server.

The New Name Devolution Behavior

The new default behavior for DNS devolution blocks that possibility. Here’s how it works for computers running Windows 7, Windows Server 2008, or a previous version of Windows with the Microsoft Security Advisory 971888: Update for DNS Devolution installed:

  1. If the number of labels in the AD DS forest root domain is one or the primary DNS suffix does not end with the forest root domain, devolution will be disabled.
  2. If the primary DNS suffix ends with the forest root domain, devolution level is set to the number of labels in the forest root domain.

For example, if the computer is a member of the westcoast.corp.contoso.co.us domain and the forest root domain name is corp.contoso.co.us, the devolution level is 4 (the number of labels in corp.contoso.co.us). If the computer is a member of the westcoast.corp.contoso.com and the forest root domain name is corp.contoso.co.us, devolution is disabled (westcoast.corp.contoso.com does not end with corp.contoso.co.us). This default behavior ensures that the devolution level does not lead to an attempt to resolve a name outside of the control of an organization.

You can also manually set the devolution level with the Primary DNS Suffix Devolution Level Group Policy setting. If you manually specify a devolution level, however, keep in mind that changes made to this devolution level value can affect the ability of your client computers to resolve resource names in a domain. If you set the devolution level too high, name devolution can be impaired.

For example, if a computer is a member of wcoast.corp.contoso.com and you set the devolution level to 4, when a user tries to connect to server1, then server1.wcoast.corp.contoso.com is the only FQDN attempted. If the FQDN of the server1 server is server1.corp.contoso.com, the user must use the server1.corp.contoso.com FQDN, rather than server1.

Configuring Name Devolution Behavior

You can enable name devolution from the DNS tab for the advanced properties of the TCP/IPv4 or TCP/IPv6 protocols. Figure 1 shows an example.

Figure 1 DNS devolution settings on the DNS tab

Figure 1  DNS devolution settings on the DNS tab.

When you click Append primary and connection specific DNS suffixes and select Append parent suffixes of the primary DNS suffix, this enables name devolution.

You can also configure name devolution with the following Group Policy settings in Computer Configuration\Policies\Administrative Templates\Network\DNS Client:

  • Primary DNS Suffix Devolution Level

Set to Not configured, but with a level 2 default. You can also configure this setting with the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\UseDomainNameDevolution (REG_DWORD) registry value (1-enabled, 0-disabled).

  • Primary DNS Suffix Devolution

Set to Not configured by default. You can also configure this setting with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DomainNameDevolutionLevel (REG_DWORD) registry value.

If Group Policy settings are configured, local registry settings are ignored. For versions of Windows prior to Windows 7 or Windows Server 2008 R2, the Primary DNS Suffix Devolution Level and Primary DNS Suffix Devolution settings apply to computers with the Microsoft Security Advisory 971888: Update for DNS Devolution installed.

Name Resolution Policy Table

For technologies requiring special handling for name queries for specific portions of the DNS namespace, Windows 7 and Windows Server 2008 R2 include the Name Resolution Policy Table (NRPT). DirectAccess and DNSSEC use the NRPT for the following:

  • When on the Internet, DirectAccess clients send DNS queries for intranet names to intranet DNS servers across the encrypted connection to the DirectAccess server. Rules in the NRPT specify the namespace of the intranet and the set of intranet DNS servers.
  • Windows 7-based computers send DNSSEC-based DNS queries for names in specified namespaces to authenticate the DNS server and ensure that DNSSEC validation has been performed by the validating DNS resolver. Rules in the NRPT specify the namespace for DNSSEC-based queries and whether to require DNSSEC validation.

The NRPT contains rules for either names or namespaces and the settings for the special handling required. When performing a DNS name resolution, the DNS Client service checks the NRPT before sending a DNS name query and when processing the response. Queries and responses that match an NRPT entry get the specified special handling applied. Queries and responses that do not match an NRPT entry are processed normally.

You can configure the NRPT with Group Policy (in Computer Configuration\Policies\Windows Settings\Name Resolution Policy), through the Windows Registry, or for DirectAccess-based entries, using the DirectAccess Setup wizard. For DNSSEC-based entries, Group Policy is the preferred method of configuration. For DirectAccess-based entries, the DirectAccess Setup wizard is the preferred method of configuration.

Figure 2 shows the Group Policy-based configuration of the NRPT.

Figure 2 Group Policy-based configuration of the NRPT

Figure 2**  Group Policy-based configuration of the NRPT.**

For more information, see The Name Resolution Policy Table, in the February 2010 “The Cable Guy.”

DNS Security

The DNS protocol wasn’t designed to provide authentication or verification of authentic name resolution responses. Various types of attacks trying to spoof an Internet resource have exploited this lack of security in the past.

DNSSEC is a suite of Internet Engineering Task Force (IETF) standards (RFCs 4033, 4034, and 4035) that provide the following for DNS data sent as network traffic or cached:

  • Origin authentication: Confirmation that the response sent as network traffic originated from the expected DNS server.
  • Authenticated denial of existence: The response was Name not found and this was authenticated by the authoritative DNS server.
  • Data integrity: The response was not modified in transit.

DNSSEC uses public key cryptography to provide these security services. When a DNS client sends a DNSSEC-specific DNS name query, the response contains an accompanying digital signature. The validating DNS resolver—a Windows Server 2008 R2-based DNS server—validates the signature using a preconfigured trust anchor, a computer that has the starting public key in an authentication chain to the authoritative DNS server.

For more information about how DNSSEC works, see Appendix A: Reviewing Key DNSSEC Concepts.

For information about deploying DNSSEC on DNS servers running Windows Server 2008 R2, see the Secure DNS Deployment Guide.

Configuring the DNS Client Service to Use DNSSEC

You can configure DNSSEC behavior for the DNS Client service in Windows 7 and Windows Server 2008 R2 with the NRPT. See the NRPT section in this article for more information.

Figure 3 shows the configuration settings for DNSSEC within an NRPT rule.

Figure 3 Enabling DNSSEC in an NRPT rule

Figure 3 **Enabling DNSSEC in an NRPT rule.  **

For a specified portion of the DNS namespace defined by the NRPT rule, enable DNSSEC with Enable DNSSEC in this rule. You can then require validation with Require DNS clients to check that name and address data has been validated.

You can also specify that the DNS client protect traffic between itself and the DNS server with UseIPsec in communication between the DNS client and DNS server, and then specify the type of protection. You can also specify the certification authority (CA) from which the DNS client will accept certificates when performing IPsec authentication in Certification authority (see Figure 2).

Joseph Davies* is a principal technical writer on the Windows networking writing team at Microsoft. He’s the author and coauthor of a number of books published by Microsoft Press, including “Windows Server 2008 Networking and Network Access Protection (NAP),” “Understanding IPv6, Second Edition” and “Windows Server 2008 TCP/IP Protocols and Services.”*

Related Content