Have you ever noticed that ping and nslookup give different results when resolving a name? This happened to me many, many times and it caused me some frustration before I made the effort to understand why it was okay for the results to be different. Let’s look at some of the reasons that nslookup results can be so different from ping results.

There are really three important things to understand I think:

  1. How the Windows client resolver works (at least at a high level).
  2. What ping is intended to do and how it does it.
  3. What nslookup is intended to do and how it does it.

The Windows Client Resolver

I am not going to spend a lot of space explaining the resolver because Microsoft has done an excellent job of documenting this for us. A detailed explanation can be found here. To save you from clicking over to the full article now, I am including the section that is immediately important to us.


  1. Windows checks whether the host name is the same as the local host name.
  2. If the host name and local host name are not the same, Windows searches the DNS client resolver cache.
  3. 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.
  4. 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.
  5. If Windows cannot find the NetBIOS name in the NetBIOS name cache, Windows contacts its configured WINS servers.
  6. 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.
  7. If there is no reply to the NetBIOS Name Query Request messages, Windows searches the local Lmhosts file.


The purpose of ping is not to see if it can resolve a name to an IP address but rather to see if it can reach a destination device via ICMP ECHO. For ping, as for most other applications, name resolution is simply a necessary part of communication. Ping will use the standard client resolver process listed above. It will start with the client resolver cache, attempt resolution via DNS, and if unsuccessful, move through the NetBIOS name resolution process.

So ping may come back with an IP address that was resolved via DNS or NetBIOS. Though there are exceptions, typically you can tell which method was used to resolve it by the response. If a name is resolved via hostname, ping will respond that it is pinging the partially qualified domain name:

Pinging xp01.fed.gov [] with 32 bytes of data:

If a name is resolved via short name, ping will respond that it is pinging the short name:

Pinging xp01 [] with 32 bytes of data:

Before we even get into nslookup, we should note that because ping can use both name resolution paths, we may get a different answer between two different attempts or clients depending on circumstances.


Though some Microsoft articles state that nslookup is “is a useful tool for troubleshooting DNS problems, such as host name resolution” that’s somewhat misleading. NSLookup is useful for troubleshooting DNS issues but not full host name resolution. The tool is meant to troubleshoot name resolution via DNS. It’s a subtle difference but an important one.

When you launch nslookup you’ll notice that it immediately attempts to connect to a DNS server – typically the ones configured in your IP settings. If there isn’t a pointer (PTR) record in a reverse lookup zone that covers the DNS server IP address then you are going to see a message like this:

DNS request timed out.

Timeout was 2 seconds.

*** Can’t find server name for address Timed out

Default Server: UnKnown <– I love the capitalized ‘K’ here 😉


The behavior of nslookup is very well documented by Microsoft here .  Beyond that, what is important to know is that nslookup does not do a few things that a client would normally do during resolution:

  1. Check the DNS resolver cache. This is true for records that were cached via a previous name query or records that are cached as part of a pre-load operation from updating the hosts file.
  2. Attempt NetBIOS name resolution.
  3. Append all suffixes from the suffix search list.
  4. When a Primary Domain Suffix is used, nslookup will only take devolution 3 levels.

Now we can see how our results with nslookup can be dramatically different from ping. If we had a hosts file configured, nslookup would provide us with a DNS address if available where ping would attempt to reach the device by the IP configured in the hosts file. There are also some differences in how each of these tools treat devolution depending on the type of lookup.  We’ll talk about this more in a future post.

I have heard it said many times, and I want to echo it here, every problem is a name resolution problem until you prove differently. Knowing the client resolver process and how our troubleshooting utilities resolve names goes a long way to help us reach root cause.