TCP/IP Name Resolution Order

May 30, 2006 · 2 min read  ·
Share on:

Update: Seventeen years later. Who knew that protocols would evolve? Seems that Microsoft changed the order at some point or maybe Addison Wesley and O'reilly were both wrong? Seems unlikely.

Anyway, this is the order that feels right and is documented by Microsoft in the undated reference, Microsoft TCP/IP Host Name Resolution Order

Host name resolution generally uses the following sequence:

  1. The client checks to see if the name queried is its own.
  2. The client then searches a local Hosts file (C:\Windows\System32\drivers\etc\hosts)
  3. Domain Name System (DNS) servers are queried.
  4. If the name is still not resolved, NetBIOS name resolution sequence is used as a backup. This order can be changed by configuring the NetBIOS node type of the client.

This lines up with my experience.

OLD, OUTDATED POST:

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.

Old 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.