TCP/IP Name Resolution Order
I found this gem in Addison Wesley's Inside WIndows Server 2003:
A simple way to remember the order in which TCP/IP uses these tools is the phrase "Can We Buy Large Hard Drives?" The first letters are keys for cache, WINS, Broadcast, Lmhosts, Hosts, and DNS.
Update: I just found the DNS query resolver behavior in the O'reilly book "DNS on Windows Server 2003":
1.The resolver first checks its local cache, which is systemwide (and therefore shared by all applications calling the resolver). If the desired record is not in the cache, the resolver has to send at least one query to a name server.
2. The resolver queries the first name server of the preferred network adapter and waits just one second.
3. If no answer is received, the resolver resends the query simultaneously to the first name server configured for each network adapter and waits two seconds. If the host has only one network adapter, this step is skipped.
4. If no answer is received, the resolver resends the query simultaneously to all name servers configured for all adapters and waits two seconds.
5. If no answer is received, the resolver resends the query simultaneously to all name servers configured for all adapters and waits four seconds.
6. If no answer is received, the resolver resends the query simultaneously to all name servers configured for all adapters and waits eight seconds.
7. If after all this time no name server has returned an answer, the resolver gives up and an error is returned to the application.



May 31st, 2006 - 09:34
I thought i depends on node type, typically assigned by DHCP or H [Hybrid] by default.
May 31st, 2006 - 18:06
Hmm, I’ll look into that. I’m not very knowledgeable on TCP/IP — this was something I read in the book “Inside Windows Server 2003.” Do you know of any flowcharts that describe, in detail, name resolution? Something that would even include references to Secondary DNS/WINS servers?
June 2nd, 2006 - 07:50
Luckily found one at http://www.extralan.co.uk/Infolinks/on-site-links/Netbios-flow-chart.htm
I guess it self-explanatory
August 1st, 2006 - 15:54
This is the phrase I remember!!! Works for me!!”
“No Way Baby – Lets Have Dinner”
“NetBIOS name cache, WINS, Broadcast, Lmhosts, Hosts, and DNS”
August 24th, 2006 - 12:25
Alexander, thanks so much!!
October 5th, 2006 - 08:37
Mark Minasi’s book for Windows NT 4 has flow diagrams and explanations in the rather large 200 page chapter. This was all I read for the NT4 TCP/IP exam many moons ago.
Check out Mark’s other books at…only joking:-)
February 9th, 2009 - 09:54
I’ve been told another on a microsoft course:
C owboys
W ith
B ig
L egs
H ate
D rainpipes
July 7th, 2009 - 18:59
There are 2 types of name resolution: NetBIOS and HOSTS/FQDN and they resolve differently
Hosts/FQDN
—————————————————————
Local Host Name
Cache (seen by ipconfig /displaydns and flushed by ipconfig /flushdns)
Hosts file (c:\windows\system32\driver\etc\hosts)
DNS
WINS (if DNS is configured)
LMHOSTS file (see HOSTS file location)
Broadcast
NETBIOS
——-
Cache
LMHOSTS
WINS
Broadcast
HOSTS
DNS
The Node type determines the order of 2,3 & 4 of NetBIOS. I believe it goes like this
Hybrid – as above
Mixed – no broadcast
another i don’t remember – WINS first then LMHOSTS
July 15th, 2009 - 13:26
Just stumbled across this and needed to make a quick correction.
The provided name resolution order….
“Cache, WINS, Broadcast, Lmhosts, Hosts, and DNS”
… is only correct when referring to NetBIOS name resolution.
Actual Hostname resolution is slightly different.
“Cache (DNS), Hosts, DNS server, NetBIOS cache, WINS, Broadcast and Lmhosts”
And by the way.. the local HOSTS file actually pre-populates the local DNS cache. So even if you clear the local dns cache (ipconfig /flushdns) it’ll still repopulate it unless you check the local HOSTS file.
Now… can anyone come up with an easy to remember phrase for
C-H-D-N-W-B-L ??
thnx
April 12th, 2010 - 06:11
Just stumbled across this too, and so far this is the only page that even approaches a description of my problem: NT 5.02 (Windows Server 2003/XP x64) frequently tries broadcast to non-IP networks before realizing a name is in DNS on the IP protocol, causing annoying slowdowns on any machine supporting multiple protocols.