Domain computer cannot resolve internal hostnames, but nslookup can

I have a Windows 7 computer on my domain that is behaving oddly.

• It is possible to ping www.google.com
• It can ping internal hosts using their IP address
• It can ping the local Domain Controller/DNS server for that office using its hostname and IP address
• It cannot ping other internal hosts by their hostname or FQDN
• The client has not registered itself in DNS
• nslookup can resolve internal host names to their correct IP addresses and uses the correct DNS server
• The client gets its IP settings via DHCP the same as other clients - it has an address in the correct subnet, the correct DNS servers applied and has the correct suffix added to resolve hostnames
• The Local Area Connection network connection shows a SSID name that was previously used in the space that would be used to show the domain name or the WiFi status - see image

I'm really baffled as to why this might be happening. Because internal DNS resolution is not happening, the computer is not able to communicate with the domain properly, so Group Policy can't be applied and I doubt authentication is working properly.

I have tried clearing the DNS cache with ipconfig /flushdns, disabling/restarting the cache with netsh stop dnscache. I've reset Winsock and the IP stack, and rebooted numerous times with no difference. Other clients in the same network are working just fine.

The current workaround is to put entries in the hosts file for the most important hosts for services the user may need to use. This has worked ok, but isn't really sustainable long term, and doesn't address communication with Active Directory.

Any idea how to fix this, before I rebuild the thing?

Update I have installed Wireshark on the effected computer. When I do nslookup domain.local I see all the DNS traffic as expected. When I do ping domain.local I don't see any DNS traffic at all - no request and no reply. When I do ping www.google.com I see both DNS request and reply.

Also, this is a laptop with both Wired LAN and Wireless. I get exactly the same issue when connected via Wired LAN or via WiFi to the internal network.

An odd thing I noticed is that under the name of the network connection (Local Area Network) rather than displaying the domain name as I would expect, but rather the name of a VLAN we used to use. I'm hesitant to remove the computer from the domain, in case I cannot join it again. I'd rather try some other things before I go down a route that might involve reinstalling Windows.

Update this looks relevent

Update I have tried netsh winsock reset catalog, netsh int ip reset, and sfc scannow none of which have fixed the behaviour. The computer cannot leave and rejoin the domain, as it can't communicate with a domain controller. ifconfig /registerdns also doesn't work for the same reason. I've also tried stopping the dns client service to no avail.

Solution 1:

TLDR;
1. hosts file overrides DNS.
2. Reset, refresh, reset.
3. Backup data, format, re-install

This could be caused by a bad entry in the hosts file which is located here:

C:\Windows\System32\drivers\etc\hosts

Make sure you don't have an entry in the hosts file overriding domain.local

nslookup domain.local will check the DNS Server for an address associated with domain.local - however if you have an entry in your hosts for domain.local then ping domain.local would use that address and not the one from DNS.

It may also be worth your time to reset a few things:

Reset WINSOCK entries to installation defaults : netsh winsock reset catalog
Reset TCP/IP stack to installation defaults : netsh int ip reset reset.log
Flush DNS resolver cache : ipconfig /flushdns
Renew DNS client registration and refresh DHCP leases : ipconfig /registerdns
Flush routing table : route /f (reboot required)
Check for corrupted system files : sfc /scannow

Also, if this is really the same machine from the original issue you posted in November 2014 then it may also be worth the time and effort to just format the hard drive and reinstall the OS. This will get you back to a known state that should work.

Solution 2:

This issue is excatly what I had. Turns out my certificate for https://nls.my.domain.com for DirectAccess connectivity has been revocked. Hence my clients used Name Resolution Policy Table (NRPT) from within my LAN and blocking all connections to internal resources.

Just wanted to share this info as it might be the same for some of you.

Solution 3:

I had the same problem.

I found out that the cooporate implementation of Microsoft DirectAccess Connectivity, was the reason.

Right clicked on the taskbar icon and chose "Use local DNS resolution" and then ran a gpupdate and my problems where solved.

If this is not your problem, the nature of an assisting connectivity software (there are many) beeing flawed, is most likely though.

Best regards

Keiko

Solution 4:

I had a very similar problem with my laptop in the domain network. I was unable to connect to the domain but was able to ping and work with other devices using ip addresses (hostnames were no-go). Editing the hosts file was a temporary solution, but doing this for every network device and being unable to /gpupdate was kinda frustrating.

In the end my problem (and my situation, might not be applicable for yours) was resolved by this particular blog: http://setspn.blogspot.nl/2015/05/corrupt-local-gpo-files.html

• Rename (or delete) C:\Windows\System32\GroupPolicy\Machine\Registry.pol
• Start > run > cmd (as admin)
• Gpedit.msc
• Below administrative templates change a (not matter which) setting and then revert it. This will trigger the creation of a new registry.pol file
• gpupdate /force
• Gpo’s should process correctly now.

The problem lies with a fault Registry.pol, generating a new one fixed my problem and I was able to gpupdate! Hope this helps people troubleshooting. Make sure you have removed all the manual entries in the hosts file though.

Solution 5:

TL;DR; - Make sure if your network DHCP is publishing IPv6 as well you put the DNS' IPv6 address too - since that takes precedence over IPv4 static configurations on Windows 10.

I ran into this problem yesterday and wanted to share another possible problem and solution.

I was re-configuring the network and hooked up to a newer router. I ran into the same issue - all my existing systems couldn't reach the AD anymore using mydomain.local - it worked fine before.

Scouring the internet I tried a couple different things - the DNS was running fine. When I would do nslookup it would throw an error say non-existent - but when I ran

nslookup mydomain.local {LOCAL-DNSSERVER-IP} it would resolve.

The issue came down to I saw the resolution but I missed it was returning an IPv6 address as well when doing that.

The new router by default was publishing its own IPv6 DNS address (inherited from modem) which even though I had static DNS assigned for IPv4 it was using the IPv6 one which was going to to pub-internet to resolve hence the doesn't exist.

I took the Domain Controller Servers IPv6 address and added to the routers DHCP for IPv6 DNS and voila resolution!