Share via

The Cable Guy - May 2010

  • Article

Changes to the DNS Client Service in Windows 7 and Windows Server 2008 R2

TechNet's The Cable Guy

By The Cable Guy

The Domain Name System (DNS) Client service in Windows 7 and Windows Server 2008 R2 includes the following:

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

The following sections describe these features in detail.

Changes to Name Devolution Behavior

Name devolution is a behavior of the DNS Client service in Windows that allows a user on an Active Directory Domain Service (AD DS)-joined computer to 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 only occurs for the primary domain suffix. Name devolution does not occur when there is no primary domain suffix, for connection-specific DNS suffixes, or when you have configured a global suffix search list.

Name Devolution Behavior Prior to Windows 7

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 is not configurable.

Security Issue of Devolution Level 2

The devolution level of 2 and new types of Internet names can result in a domain-joined computer attempting to connect to possibly 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 with a devolution level of 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 succeeds and the computer attempts to connect. A malicious user that registered and owns the server1.co.us server on the Internet can attempt to spoof an intranet server.

Name Devolution Behavior in Windows 7 and Windows Server 2008 R2

The following is the new default behavior for DNS devolution for computers running Windows 7, Windows Server 2008 R2, 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, disable devolution.

  2. If the primary DNS suffix ends with the forest root domain, set the devolution level 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 result in an attempt to resolve a name that is 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 described in the following section. If you manually specify the devolution level, keep in mind that changes to the devolution level can affect the ability of client computers to resolve the names of resources 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 the wcoast.corp.contoso.com and you set the devolution level to 4, when the user tries to connect to server1, the only FQDN that is tried is server1.wcoast.corp.contoso.com. 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.

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, name devolution is enabled.

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 of 2 by 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.

Note If Group Policy settings are configured, the 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.

NRPT

For technologies that require special handling for name queries for specific portions of the DNS namespace, Windows 7 and Windows Server 2008 R2 include the 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.

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, the February 2010 The Cable Guy article.

DNSSEC

The DNS protocol was not designed to provide authentication or verification that the name resolution responses are authentic. This lack of security has been exploited in the past for various types of attacks that try to spoof an Internet resource.

DNSSEC is a suite of Internet Engineering Task Force (IETF) standards (RFCs 4033, 4034, and 4035) that provides 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 is 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.

DNSSEC settings within an NRPT rule

Figure 3 DNSSEC settings within an NRPT rule

For a specified portion of the DNS namespace defined by the NRPT rule, you 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 Use IPsec in communication between the DNS client and DNS server and then specify the type of protection. You can also optionally specify the certification authority (CA) from which the DNS client will accept certificates when performing IPsec authentication in Certification authority (optional) (see Figure 2).

For More Information

See the following resources:

For a list of all The Cable Guy articles, click here.