DNS responding only to nslookup in Windows 7

Question

I have an interesting DNS issue in AD (2008R2) which I can't find a way to debug. Mainly if from commandline I try

ping <machinename>

then I get the reply that the hostr isn't found. But when I do

nslookup <machinename>

I get the correct response from my DNS with proper AAAA and A records. Anyone has an idea what could cause this?

The client machines run Windows 7 Enterprise.

Answer 1

Make sure HOSTS and LMHOSTS doesn't have anything funny in it. nslookup works by talking directly to the DNS server, whereas the name resolution ping uses is done by the operating system. This means that your HOSTS file could be screwed, or there's corruption on Winsock etc etc.

Since we're playing with IPv4 and IPv6, what happens when you ping host -4 and ping host -6?

You may also want to turn off WINS/NetBIOS

Answer 2

Previous comments are right. I would simply add that there MAY be a sequence for name resolution. At least, this exists under Linux as a file named /etc/nsswitch. By default, a local HOST file will resolve names BEFORE invoking a name server. As for the actual IP addresses of the name servers, those are setup in Control Panel -> Network

Usually, the HOSTS file is located under C:\WINDOWS\SYSTEM32\DRIVERS\ETC

This file can be edited using notepad. I use this file all the time on the various virtual Windows servers I have.

Answer 3

I just had exactly the same issue. For me the issue was caused by having multiple DNS servers defined. My IPv4 settings were set to DHCP with the primary DNS set to my router and the secondary DNS set to a Google DNS server. Although the order doesn't matter.
When I switch to use the DNS server provided via DHCP the issue is resolved. Adding the DNS servers back brings back the issue.

I really don't understand the root cause of this. But maybe it's the same issue for you.

Answer 4

I've run into Vista systems caching null dns entries if a dns server was not available. Running "ipconfig /flushdns" cleared them out. Depending on what the root cause is this might only be a bandaid fix but have a look at disabling the caching of negative dns results. There are decent instructions here

Answer 5

I had a similar issue, which I solved by changing the DHCP settings of my router to give my local network a domain and the static DNS entries to put each host in that domain.

However, I found a few forum postings that describe a similar issue that had subtly different symptoms and a different solution (a registry change), so I'm going to describe my problem in detail to distinguish it from that.

My Issue

I had recently gotten a new router (a Mikrotik), and configured it assign each host on my network a static IP and give each host a local DNS hostname (and only a hostname). This worked fine from UNIX/Linux/Mac OS X, but Windows had problems with it.

On Windows, I could not ping some hosts by name, even though I could look them up via nslookup and ping them by IP:

C:\>nslookup router
Server:  router
Address:  192.168.22.1

Non-authoritative answer:
Name:    router
Address:  192.168.22.1


C:\>ping router
Ping request could not find host router. Please check the name and try again.

C:\>ping 192.168.22.1

Pinging 192.168.22.1 with 32 bytes of data:
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.22.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>nslookup overkill
Server:  router
Address:  192.168.22.1

Non-authoritative answer:
Name:    nas_server
Address:  192.168.22.5

But strangely, some others worked:

C:\>ping nas_server

Pinging nas_server [192.168.22.5] with 32 bytes of data:
Reply from 192.168.22.5: bytes=32 time<1ms TTL=64
Reply from 192.168.22.5: bytes=32 time<1ms TTL=64
Reply from 192.168.22.5: bytes=32 time<1ms TTL=64
Reply from 192.168.22.5: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.22.5:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>

I used Wireshark to investigate further, and found that the ping command was not causing any DNS packets to get sent, only NetBIOS Name Service packets. This would fail for my router, but it would succeed for my NAS server (because the NAS was running Samba). The nslookup used DNS, which is why it worked for everything.

Wireshark capture from ping:

The root problem was that Windows uses the NetBIOS Name Service instead of DNS in certain cases (like when the host does not have a domain).

My Solution

Note: the screenshots are from my router's configuration screen, but they illustrate general concepts.

I configured my DHCP server to tell all hosts that they were part of a domain:

Then I configured all my static DNS entries to place all hosts in this domain:

Then I cleared all DHCP/DNS information from Windows:

C:\>ipconfig /release
C:\>ipconfig /renew
C:\>ipconfig /flushdns

And everything worked!

C:\>ping router

Pinging router.localnet [192.168.22.1] with 32 bytes of data:
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64
Reply from 192.168.22.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.22.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>

Answer 6

Out of the box Windows 7 disables Ping response in Windows Firewall. You'll need to switch it on in all of the client machines. Not sure if this can be done via group policy. Here is how to do it on Vista, I'm guessing 7 is the same.