Post-installation behavior on client computers after you install the DNS update

Definitions

Current overview of DNS devolution

• A DNS suffix search list is configured. The suffix search list may be configured manually or by using Group Policy (expand Computer Configuration, expand Administrative Templates, expand Network, and then click DNS Client). For more information, click the following article number to view the article in the Microsoft Knowledge Base:
  294785

  (http://support.microsoft.com/kb/294785/ )

  New group policies for DNS in Windows Server 2003
• The append parent suffixes of the primary DNS suffix check box is not selected on the DNS tab in the Advanced TCP/IP Settings dialog box of the Internet Protocol (TCP/IP) component.

Changes to DNS devolution

Managing devolution

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then click the following subkey in the registry:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type UseDomainNameDevolution for the name of the DWORD value, and then press ENTER.
5. Right-click UseDomainNameDevolution, and then click Modify.
6. In the Value data box, type 1 to enable DNS devolution, and then click OK.
   
   Note A value of 0 indicates that devolution is disabled.
7. Exit Registry Editor.

Setting the devolution level

• A value of 2 or higher, for example, a value of 3, makes sure that a minimum of 3 labels of primary DNS suffix are appended during devolution.
• A value of 2 makes sure that the behavior is the same as it was before the installation of the update.

• To manually change this setting by editing the registry, add a DWORD value that is named DomainNameDevolutionLevel to the following registry subkey:
  HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\Dnscache\Parameters
• To change this setting by using Group Policy, open the "Primary DNS Suffix Devolution Level" entry in the following location:
  Computer Configuration/Administrative Templates/Network/DNS Client
  "Primary DNS Suffix Devolution Level" is a new policy that is introduced by this feature to define the devolution level that is appropriate to the domain, site, organizational unit, or computer. The policy stores the level in the DomainNameDevolutionLevel DWORD entry that is located in the following subkey in the registry:
  HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\WindowsNT\DNSClient\
• Devolution settings can be pushed over a domain by using Group Policy. For more information about how to edit and apply Group Policy, visit the following Microsoft Web page:
  http://technet.microsoft.com/en-us/library/bb742376.aspx

  (http://technet.microsoft.com/en-us/library/bb742376.aspx)

• The devolution level should match the organization boundary for both of the following reasons:
  • Make sure that devolved queries remain inside the organization.
  • Make sure that all domains that were previously available through devolution are still available.
• A setting of value 2 for devolution level means that the behavior is the same as it was before the installation of the update.
• Clients to which this Group Policy setting is being applied must be updated with update 957579 for the Group Policy setting to be effective.
• For more information about pushing scripts through Group Policy, visit the following Microsoft Web page:
  http://technet.microsoft.com/en-us/library/bb742499.aspx

  (http://technet.microsoft.com/en-us/library/bb742499.aspx)
• Group Policy for the devolution level is not supported in Windows Server 2000 or in Windows NT 4. To set the key manually, Domain Administrators can write scripts that are run on the domain joined clients.
• If the local registry entry and the Group Policy are set on a computer, the Group Policy will take precedence.
• The default behavior of the update on installation is to automatically determine the devolution level. The logic for this is discussed in the next section.

Devolution behavior

Devolution level behavior across platforms with and without the update

Automatic determination of the devolution level

1. First, the computer will determine the FRD of the computer locally. No network queries are used in this operation.
2. If the FRD is obtained, it is analyzed for the following conditions:
   • The devolution level will be set to 2 if the number of labels in the forest root domain is 1. That is, it is a single label domain.
   • The devolution level is set to the number of labels in the forest root domain if the PDS is a trailing subset of (ends with) the forest root domain.
     • Examples of trailing DNS suffixes for contoso.com and contoso.co.us are corp.contoso.com and corp.contoso.co.us.
     • Examples that are not trailing suffixes for contoso.com and contoso.co.us are corp.contoso.net and corp.contoso.co.au.
   • Devolution will not be performed if the primary DNS suffix is not a trailing subset of the FRD or a disjoint name scenario.

Default behavior

• When the Suffix Search List is enabled on the computer
  DNS devolution has no effect (disabled) when the Suffix Search List is enabled on the computer. There is no change in behavior after the update is installed. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
  275553

  (http://support.microsoft.com/kb/275553/ )

  How to configure a domain suffix search list on the Domain Name System clients
When the name of the domain to which the client is joined to is a single label
• Devolution level is set as 2 if the FRD is single labeled and the PDS is a trailing subset of the FRD.
• Devolution level is turned off if the FRD is single labeled and the primary DNS suffix is not a trailing subset of the FRD.


• When the computer is in a disjoint namespace
  On domain joined computers, DNS devolution depends on the FRD and PDS combinations as depicted in the following table. If FRD is completely disjointed with PDS, devolution is turned off.

Resolution for potential issues

• Manually configure the devolution level limit to a value appropriate for the specific domain name
  In this configuration, DNS will devolve to the administrator-specified level instead of using the level based on FRD.
  For example:
  • On a computer without the update, with devolution enabled:
    If the FRD is Contoso.corp.com and the PDS is America.Contoso.corp.com, an unsuccessful query for "wpad" would eventually lead to a query for wpad.corp.com, which could be valid for the given organization.
  • " On a computer with the update, the query for wpad would stop at wpad.contoso.corp.com. This may break name resolutions that rely on wpad.corp.com. To work around this issue, an administrator could set the devolution level on the computers as appropriate. For more information, see the "Setting the devolution level" section.
• Create a DNS suffix search list
  In this configuration, when a DNS suffix search list is configured, DNS will try the suffixes in the list. Administrators can make sure that domain of all the servers that are accessed through devolution before is in the suffix search list. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
  275553

  (http://support.microsoft.com/kb/275553/ )

  How to configure a domain suffix search list on the Domain Name System clients
• Relocate the network resource to the same FRD as the computer that is trying to access it

Back to the top | Give Feedback

1. Who should deploy this update?
   
   Answer: For more information about should deploy this update, visit the following Microsoft Web page to see the explanation in the Microsoft Advisory 971888:
   http://www.microsoft.com/technet/security/advisory/971888.mspx

   (http://www.microsoft.com/technet/security/advisory/971888.mspx)
2. Why is this not a bulletin?
   
   Answer: Devolution is a critical behavior for customers who have clients in a child namespace and resources in the parent namespace. This update causes a change in this behavior. This update may cause a problem accessing certain resources for some enterprises. Network administrators are advised to carefully understand the change and then deploy the update in a manner that makes sure that both namespaces are safe and operational.
3. What is the recommended way to install the update?
   
   Answer: This depends on the enterprise network configuration. For organizations where all resources are accessed within the FRD, the update can be rolled out, as-is, to all computers. The following are examples:
   • The FRD is contoso.co.us, and the organization boundary is also contoso.co.us. In this scenario, the update can be rolled out as-is.
   • The FRD is ad.contoso.co.us, and the organization boundary is contoso.co.us. That is, there are some resources such as mail.contoso.co.us, and these resources are accessed by using devolution. In this scenario, an administrator can install the update in one computer, set the Group Policy setting for all to use devolution level of 3, and then roll out the update. For more information, see the "Resolution for potential issues" section.
4. Is there a related security advisory?
   
   Answer: Yes. For more information, visit the following Microsoft Web page:
   http://www.microsoft.com/technet/security/advisory/971888.mspx

   (http://www.microsoft.com/technet/security/advisory/971888.mspx)
5. Is there a way to set (force) the devolution level on the computer regardless of the FRD name and the primary domain suffix?
   
   Answer: For more information, see the "Resolution for potential issues" section.
6. Do I have to update my DNS servers?
   
   Answer: Yes. The DNS client component is affected and must be treated independently from any DNS server issue if the computer is also a DNS server.
7. Do I have to restart the computer or DNS client service every time that the devolution level is manually changed in the registry or set through group or local policies?
   
   Answer: No. There are listeners for these registry changes. DNS is notified when the value changes. Therefore, a system or service restart is not required.
8. How does the behavior change in single label domain FRD scenarios?
   
   Answer: By design, if the number of labels in the FRD is less than 2, the devolution level will be 2. This is the same as the level that was being used before the update is installed.
9. What about devolution level precedence? Knowing that there are two different registry locations that define the devolution level, depending on whether the setting was made locally on the computer by using the registry or by an administrator who used Group Policy, what is the order of precedence for the following two registry entries?
   
   Registry entry 1: Set by manually editing the registry
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DnsCache\Parameters\DomainNameDevolutionLevel
   
   Registry entry 2: Set by using Group Policy
   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DomainNameDevolutionLevel
   
   
   Answer: Registry entry 2 takes precedence, and it overrides registry entry 1. If the local registry entry and the Group Policy are set on a computer, the Group Policy will take precedence.
10. Does an administrator-specified devolution level that is set by using Group Policy or by manually editing the registry work for both joined and non-joined computers?
    
    Answer: Yes, the settings also work for non-domain joined computers.
11. After installation of the update, is the FRD name read from the local computer, or is there a lookup query waiting for a domain controller?
    
    Answer: This is a local operation.

Back to the top | Give Feedback

For all supported 32-bit editions of Windows Vista

Collapse this imageExpand this image

For all supported x64-based editions of Windows Vista

Collapse this imageExpand this image

For all supported 32-bit editions of Windows Server 2008

Collapse this imageExpand this image

For all supported x64-based editions of Windows Server 2008

Collapse this imageExpand this image

For all supported Itanium-based editions of Windows Server 2008

Collapse this imageExpand this image

For all supported 32-bit editions of Windows XP

Collapse this imageExpand this image

For all supported x64-based editions of Windows XP

Collapse this imageExpand this image

For all supported x64-based editions of Windows Server 2003

Collapse this imageExpand this image

For all supported 32-bit editions of Windows Server 2003

Collapse this imageExpand this image

For all supported Itanium-based editions of Windows Server 2003

Collapse this imageExpand this image

For all supported editions of Windows 2000

Collapse this imageExpand this image

How to determine whether you are running a 32-bit or a 64-bit edition of Windows

1. Click Start, and then click Run.
2. Type msinfo32.exe, and then press ENTER.
3. In the System Information window, review the value for System Type.
   • For 32-bit editions of Windows, the System Type value is x86-based PC.
   • For 64-bit editions of Windows, the System Type value is x64-based PC.

Back to the top | Give Feedback

Windows 2000 file information

For all supported editions of Microsoft Windows 2000 Service Pack 4

Windows XP and Windows Server 2003 file information

• The files that apply to a specific milestone (RTM, SPn) and service branch (QFE, GDR) are noted in the "SP requirement" and "Service branch" columns.
• GDR service branches contain only those fixes that are widely released to address widespread, critical issues. QFE service branches contain hotfixes in addition to widely released fixes.
• In addition to the files that are listed in these tables, this software update also installs an associated security catalog file (KBnumber.cat) that is signed with a Microsoft digital signature.

For all supported x86-based versions of Windows XP

For all supported x64-based versions of Windows Server 2003 and of Windows XP Professional x64 edition

For all supported x86-based versions of Windows Server 2003

For all supported IA-64-based versions of Windows Server 2003

• The files that apply to a specific product, milestone (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.
  Collapse this tableExpand this table

  Version	Product	Milestone	Service branch
  6.0.6000. 16xxx	Windows Vista	RTM	GDR
  6.0.6000. 20xxx	Windows Vista	RTM	LDR
  6.0.6001. 18xxx	Windows Vista SP1 and Windows Server 2008 SP1	SP1	GDR
  6.0.6001. 22xxx	Windows Vista SP1 and Windows Server 2008 SP1	SP1	LDR
  6.0.6002. 18xxx	Windows Vista SP2 and Windows Server 2008 SP2	SP2	GDR
  6.0.6002. 22xxx	Windows Vista SP2 and Windows Server 2008 SP2	SP2	LDR

• Service Pack 1 is integrated into the original release version of Windows Server 2008. Therefore, RTM milestone files apply only to Windows Vista. RTM milestone files have a 6.0.0000. xxxxxx version number.
• GDR service branches contain only those fixes that are widely released to address widespread, critical issues. LDR service branches contain hotfixes in addition to widely released fixes.
• The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately. MUM and MANIFEST files, and the associated security catalog (.cat) files, are critical to maintaining the state of the updated component. The security catalog files (attributes not listed) are signed with a Microsoft digital signature.

For all supported x86-based versions of Windows Server 2008 and of Windows Vista

For all supported x64-based versions of Windows Server 2008 and of Windows Vista

For all supported IA-64-based versions of Windows Server 2008

Additional file information for Windows Server 2008 and for Windows Vista

Back to the top | Give Feedback