In Windows, the DNS Client service is the client component that resolves and caches Domain Name System (DNS) domain names. When the DNS Client service receives a request to resolve a DNS name that it does not contain in its cache, it queries an assigned DNS server for an IP address for the name. All computers that use DNS to resolve domain names (including DNS servers and domain controllers) use the DNS Client service for this purpose.
To extend or revise the DNS search capabilities, in Windows you have DNS domain suffix search list. By adding additional suffixes to the list you can search for short, unqualified computer names in more than one specified DNS domain. If a DNS query fails, the DNS client service can use this list to append other name suffix endings to your original name and repeat DNS queries to the DNS server for these alternate FQDNs (Fully Qualified Domain names).
When the suffix search list is empty or unspecified, the primary DNS suffix of the computer is appended to short unqualified names and DNS query is used to resolve the resultant FQDN. If no connection-specific suffixes are configured or queries for these connection-specific FQDNs fail, the client can then begin to retry queries based on systematic reduction of the primary suffix (also known as devolution). For example, if the primary suffix were "ad.contoso.corp", the devolution process would be able to retry queries for the short name by searching for it in the "contoso.corp".
When the suffix search list is not empty and has at least one DNS suffix specified, attempts to qualify and resolve short DNS names is limited to searching only those FQDNs made possible by the specific suffix list.
A change with respect to the DNS queries for multi-label names has been made in the default behavior of Windows Vista as compared to that of Windows XP. The change is as follows:
Windows XP: When a Windows XP machine attempts to resolve an unqualified multi-label name, the DNS client will attempt to resolve the name as specified, then will append the domains that are listed in the DNS suffix search order.
Windows Vista: When a Windows Vista machine attempts to resolve an unqualified multi-label name, the DNS client will attempt to resolve the name as specified. The DNS suffix search order will NOT be used.
Suppose you have a domain structure where you have the following DNS Suffix Search List:
From a command prompt, ping the hostname of a machine using the following unqualified multi-label syntax:
XP will attempt to resolve:
1. <hostname>.site1 2. <hostname>.site1.ad.contoso.com 3. <hostname>.site1.contoso.com
When viewed in a network capture:
192.168.1.1 192.168.1.5 DNS Query for hostname.site1 of type Host Addr on class Internet
192.168.1.5 192.168.1.1 DNS Response - Name Error
192.168.1.1 184.108.40.206 DNS Query for hostname.site1.ad.contoso.corp of type Host Addr on class Internet
192.168.1.1 220.127.116.11 DNS Query for hostname.site1.contoso.corp of type Host Addr on class Internet
192.168.1.5 192.168.1.1 DNS Response - Name Error
Vista does not attempt name resolution any further.
When viewed in network capture:
This registry entry works for both Windows XP and Windows Vista
Type = DWORD
If the registry entry is not present, the default in Windows XP is 1, and 0 in Windows Vista.
This registry changes and its effect apply only to the ping command, they do not apply to the Nslookup tool. This is because Nslookup contains its own DNS resolver and does not rely on the resolver built into the operating system (DNS Client). The DNS (multi-label) query packets sent by the nslookup tool will append the domains listed in the suffix search order irrespective of the registry key settings mentioned here.
Group Policy location (for Windows Vista only) - (run gpedit.msc):
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> “Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries”
Note: As with other GPOs, if you change the registry and there is also a GPO configured then GPO will override this registry value.
- Sneh Shah with additional information from Kapil Thacker
PingBack from http://sixthsenses.net/?p=744
this is very helpful most especially to first timers. im starting to make my own website and it's good that i read this article.
That's an interesting tidbit, but can anyone put this in context and explain the reason for the change between XP and Vista?
I imagine it's to speed up negative name resolution by discarding queries that are very unlikely to produce a positive response (appending the search list to a name that's already multi-label).
I put the registry entry with DWORD=0 into Win XP Pro, however it seems that the DNS suffix search list is still being traversed to append DNS suffixes. Do you have any futher info to turn this off?
Stefan: Please try rebooting the XP machine and see if that helps
Also how are you checking that the XP machine is appending the suffix list?
Please do not use nslookup as a test.
windows xp explained what I did something very nice thank you
With windows server 2008 and Windows 7, does DHCP now have the ability to push dns suffix search lists instead of using GPO's?
I could'nt understand why my XP PC's could resolve my internal owa domian name, but the Vista business machines couldn't find the site by name. Thanks VERY much, very useful info. problem now sorted.
Thanks for the pointer.
In our case, 'ping <host>' on Windows XP was working fine, but on Windows 7 was giving 'Unknown host'. I could explicitly ping '<host>.y.ac.uk' though.
"ipconfig /all" on Win XP showed 'DNS Suffix Search List' = "x.y.ac.uk, y.ac.uk, ac.uk" but same on Windows 7 only showed "x.y.ac.uk" although both OS get thier IP in same way from our MS DHCP.
None of the "DNS Client" GP settings such as the one you mentioned above or the '...Suffix Devlolution' one worked for us but setting GP "Computer Configuration -> Administrative Templates -> Network -> DNS Client -> DNS Suffix Search List" to "x.y.ac.uk, y.ac.uk, ac.uk" fixed it. "ipconfig /all" DNS Suffix display now matches our Win XP one, and 'ping <host>' now works fine on 7.
Still unclear where XP is getting its suffix search list from and why 7 is not getting same, but at least I can now make 7 work using this GP setting.
... in our case, it could simply be that Windows Vista and 7 do not respect the DHCP option 135 "Domain suffix search order" which we have set in our DHCP, whereas Windows XP always has?