Dilemma of Name Resolution Process with PING vs NSLOOKUP
Introduction
For a long time I wanted to write on this Topic as I have seen that it is still a Grey Area for most of the IT Professionals.
DETAILS
While troubleshooting most of the Technical issues we use the following tools to check the name Resolution and connectivity:
1) PING
2) NSLOOKUP
Do we all really know what's the difference between the way the PING tool does the name resolution as compared to the way the NSLOOKUP does it?
And that's what precisely I am going to discuss here in the POST today.
A. Lets look at how PING does the name resolution. We tried to PING www.bing.com and here is what we see in the Network Trace:
As you can see above, when we tried to PING the name with its FQDN, it just tries to resolve it with the name provided.
More about the way WINDOWS resolves the HOST names:
If NetBIOS over TCP/IP is enabled, Windows by default attempts to resolve host names using NetBIOS methods when standard methods fail. NetBIOS name resolution methods include the NetBIOS name cache, configured WINS servers, NetBIOS broadcasts, and the Lmhosts file. For more information about NetBIOS over TCP/IP name resolution, see Chapter 11, "NetBIOS over TCP/IP."
When an application uses Windows Sockets and either the application or a user specifies a host name, TCP/IP for Windows XP and Windows Server 2003 attempts to resolve the name in the following order when NetBIOS over TCP/IP is enabled:
Windows checks whether the host name is the same as the local host name.
If the host name and local host name are not the same, Windows searches the DNS client resolver cache.
If the host name cannot be resolved using the DNS client resolver cache, Windows sends DNS Name Query Request messages to its configured DNS servers.
If the host name is a single-label name (such as server1) and cannot be resolved using the configured DNS servers, Windows converts the host name to a NetBIOS name and checks its local NetBIOS name cache.
Windows creates the 16-byte NetBIOS name by converting the host name, which must be less than 16 bytes long, to uppercase and padding it with space characters if needed to create the first 15 bytes of the NetBIOS name. Then, Windows adds 0x00 as the last byte. Every Windows-based computer running the Workstation service registers its computer name with a 0x00 as the last byte. Therefore, the NetBIOS form of the host name will typically resolve to the IPv4 address of the computer that has a NetBIOS computer name that matches the host name.
If the host name is 16 characters or longer or an FQDN, Windows does not convert it to a NetBIOS name or try to resolve the host name using NetBIOS techniques.
If Windows cannot find the NetBIOS name in the NetBIOS name cache, Windows contacts its configured WINS servers.
If Windows cannot resolve the NetBIOS name by querying its configured WINS servers, Windows broadcasts as many as three NetBIOS Name Query Request messages on the directly attached subnet.
If there is no reply to the NetBIOS Name Query Request messages, Windows searches the local Lmhosts file.
The name resolution process stops when Windows finds the first IP address for the name. If Windows cannot resolve the host name using any of these methods, name resolution fails, and the only way to communicate with the destination host is to specify either its IP address or another name associated with the host that Windows can resolve to an IP address.
The above Description and much more about “Host Name Resolution” is given in a very nice TechNet Article mentioned below:
https://technet.microsoft.com/en-us/library/bb727005.aspx#EDAA
For a detailed description of how DNS query works, please Refer to the Article below:
https://technet.microsoft.com/en-us/library/cc775637(v=ws.10).aspx
B. Next we tried to PING the name with just its Host name “bing” and here is what we see in the Network Trace:
So, now as we can see above, when we tried just with the Host name, it does devolution to just One Level, with the Primary DNS Suffix of that machine and add it in after “Bing”.
C. Now lets see what happens when we use NSLOOKUP to resolve the name:
As you can see above in NSLOOKUP, it does devolution for the all Suffixes in the DNS Suffix search list and finally, it tries www.bing.com and resolve it.
NOTE: There is another important point to be noted here about “Devolution”. If you want the Appending of DNS Suffixes to be completely skipped, then you can PING or NSLOOKUP a name with a “.” at the End of the name. For Example: PING www.Bing.com.
The main point to remember in NSLOOKUP is that it never looks into the DNS Resolver Cache, nor does it look for the name in the HOST file. It directly reaches the DNS server configured on the Network Card Properties of that machine.
NOTE: If there are multiple NICs on the machine, then it will by Default go to the DNS configured on the NIC which is at the Top of the Binding Order. Binding Order can be checked in the Network Connections:
First we need to get the Menu Bar at the Top like this:
Then, once you get the Menu Bar, we need to go to Advanced and then click on Advanced Settings:
Then you will see the Window where you can change the Binding Order of the Network Cards:
As we have used the term “Devolution” many times in this Blog Post, it becomes important for us to understand the meaning of this Word. You can find out more information on Devolution in the Article below:
https://technet.microsoft.com/en-us/library/ee683928(v=WS.10).aspx
Some more Reference on Name Resolution is given below:
https://technet.microsoft.com/en-us/library/bb457118.aspx
ACKNOWLEDEGEMENTS
This Post can not be complete without acknowledging a couple of names here. I would like to specially thank my fellow colleagues Krishna and Raghuraj for providing their valuable Inputs while writing this BlogPost.
Blog Written By
NITIN SINGH
SUPPORT ESCALATION ENGINEER, FOREFRONT EDGE SECURITY, MICROSOFT
Technical Reviewer:
RAGHURAJ KISHORE
Technical Support Lead, Platforms Networking Team, Microsoft