Windows 7 DNS not working (nslookup IS working; ping -4 name.com NOT working)
Solution 1:
We found the answer on edugeek.com and used it as a guide. Our explicit actions are explained below.
The answer on EduGeek is first introduced in post 13 by shoeib who says they got it from that thread, but I see nothing in that thread up to that point that would even hint at that answer.
Post 20 by fencecat42 goes into more detail.
Specifically,
In registry key:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
The following "values" (as MS confusingly terms them, each of which can have "data") are missing
Domain
Hostname
NV Hostname
All three were missing on both fencecat42's and our system.
Now, kudos (well, almost ;) @Kris because there was evidence of this problem in the ipconfig /all that they asked me to post. Notice in my posted output there is no Host Name. This is one and the same Hostname from the registry.
I am hesitant to edit the registry, because one stray keystroke could make your system unbootable, in which case hopefully you have made a system restore or made a copy of your registry (my favorite ways are ERUNT and Tweaking.com Windows Repair All-In-One (which includes a registry save tool) (I found out about these tools at techsupportalert.com))
So to set the Hostname, we simply went into Control Panel -> System. (Often the "Change Settings" link is not visible in the first screen; you have to scroll down. This step requires UAC authorization. After setting it you have to reboot.)
This action sets both the Hostname and NV Hostname "values" in the registry.
We could not find a non-regedit way of editing the Domain "value". (Maybe netdom but we didn't have this on this Windows 7 Home Premium system.) So we used the registry to set Domain to an empty value. We used regedit, navigated to the Tcpip/Parameters key, right click -> New -> String Value. That creates a new "value" and sets you up to type its name, changing the default new name. Then we did not have to create an actual "data" for this "value" (again pardon MS's counter-intuitive terms). Just created it and left its "data" uninitialized.
Note: we tried networking after setting JUST the Hostname's. Did not work. the Domain (even empty) was required. We did not try with Domain created (and empty) but without creating and setting the Hostname's. But I think that's an interesting experiment.
Reflections
First,
I don't remember now, but I suspect we tried Microsoft's "How to reset TCP/IP by using the NetShell utility" which is
netsh int ip reset c:\resetlog.txt
(or whatever path and filename you want for the log file).
And that MS page says this:
When you run the reset command, it overwrites the following registry keys, both of which are used by TCP/IP:
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters SYSTEM\CurrentControlSet\Services\DHCP\Parameters[Seems like the same registry key we changed, MS is just not showing all of its hierarchy. --john v kumpf]
This has the same effect as removing and reinstalling TCP/IP. To run the manual command successfully, you must specify a name for the log file in which the netsh actions will be recorded. (This log file is referred to as "resetlog.txt" in the manual procedures earlier in this section.)
Perhaps, this reinstall process overwrites those registry keys, and fails to write the Hostname's and Domain? Maybe?
If so, then what really worked for us is doing the MS ip reset, THEN setting those registry keys.
Second,
Our problem appeared after rebooting after a crash due to heat. Hard to connect that event to the problem. One possibility is that the heat crashed a small number of blocks of the disk and one of those block happened to be holding part of the Tcpip registry key values. Unlikely, but I guess possible.
Or, if that re-installing TCP/IP was necessary, that the disk blocks corrupted the TCP/IP service, and we had to re-install it and then fix it up after.
Third,
This is quite an interesting result. What this means is that the Windows DNS Client looks for either Domain or 2 or all 3 of these "values" in the registry. And if it finds it (them), it's fine. If it doesn't find them, specifically if it does not find the Domain, it errors out and simply fails. No error report [1].
I think we can conclude from this evidence that this is a bug in the Windows DNS Client. We can prove this because it works with an empty Domain value, that means the software can't really be using it, which means why would it require it to exist (even empty) to function properly? That's a bug.
[1]Fourth,
There might have been an error report, but not in the Event Viewer in the common places (under the hierarchy: Event Viewer (Local) -> Windows -> Application, and System). There are other logs, many not turned on by default, that might have had some output, especially
- Event Viewer (Local)
- Applications and Services Local
- Microsoft
- Windows
- DNS Client Events
- Microsoft-Windows-DHCP Client Events/Admin
- Microsoft-Windows-DHCP Client Events/Operational
but also possibly
- Event Viewer (Local)
- Applications and Services Local
- Microsoft
- Windows
- Dhcp* -> *
- Diagnostics-Networking -> Operational
- Iphlpsvc -> Operational
- NCSI -> Operational
- NDIS -> Operational
- Network Access Protection
- Operational
- WHC
- NetworkProfile -> Operational
- NlaSvc -> Operational
- NTLM -> Operational
- WebIO -> NDF/Diagnostic
- Winsock Catalog Change -> Operational
- Winsock Network Event -> Operational
- Wired-AutoConfig -> Operational
- WLAN-AutoConfig -> Operational
Fifth,
After MANY hours surfing this problem, it seems this problem is usually hard to debug and is something "weird".
For example in this post at spiceworks, the problem was an expired certificate in a DNS server.
Poster "Galen in Laguna" at spiceworks suggested a way to completely uninstall the TCP/IP stack in Windows 7 and let Windows reinstall it. I suspect that would have worked in our case, because it would have restored the Tcpip registry key. (But see the MS post above.)
Poster ILS at spiceworks suggested that the afd.sys driver might have a Trojan or be corrupted in some way, and suggested how to replace it. (afd stands for "Ancillary function driver" for Winsock.)
This superuser post Why is 'ping' unable to resolve a name when 'nslookup' works fine? where the question had 35 upvotes and the best answer 27, is a good reference. There, people reported "other solutions for them" including:
- multiple default gateways
- two PC's having the same IP address on the network
- Windows 7 Multi Label DNS Query issue (whatever that is)
Also, people report this problem can be caused by "rootkits". I would suggest anyone struggling with this problem to run a few rootkit scanner/removers. bleepingcomputer.com is a good place to get advice. Or read Gizmo's Best Free Rootkit Scanner/Remover at techsupportalert.com
Sixth,
There's evidence in forums that this problem goes unsolved most often.
One of those posters, "Galen in Laguna", at spiceworks said that's what they usually have to do.
That same superuser post Why is 'ping' unable to resolve a name when 'nslookup' works fine? where the question had 35 upvotes and the best answer 27, the best answer author said, "Some sites also recommend uninstalling and reinstalling SP3 in this case."
And, This poor superuser who tried everything, got no answer, and after 18 days had to repair install
Seventh,
Helpful hint if this does not solve your problem: When searching the internet for Windows DNS problems, be aware that a lot of posts are talking about a Windows server functioning as a DNS server. Our issue was that we had a plain old PC connected via a router to the internet and our DNS client software was not working. Sometimes reading posts I missed that distinction.
Eighth,
Another helpful hint if you go searching: many problems of this sort we found posted had attributes we did NOT have:
- local DNS server within the building (ours was public DNS server, eg, google's 8.8.8.8).
- failure to translate names of local nodes within the building (we were trying to access public internet sites, like www.google.com)
- part of a Windows domain and/or using Active Directory, eg in a corporate environment (we just had our PC connected to a wireless router)
I hope our answer helps someone else.
Solution 2:
I would reinstall all network drivers and set a static dns to 8.8.8.8 and 8.8.4.4 (google primary and secondary dns servers).