Spent some time recently with a Windows XP laptop that would see networks fine (although IP address acquisition via DHCP seemed slower than I’d expect), but which was unable to resolve names with DNS. This was affecting IE, Firefox, ping, basically anything that used the built-in Winsock calls such as gethostbyname(). NSLookup, on the other hand, worked just fine.
The first thing to do when facing any computer problem is to figure out where the problem lies, so it was time for a bit of sleuthing.
These days the first thing to run on any general-use computer with networking problems is standard anti-spyware / anti-malware / anti-virus software. Some malware infections wedge themselves into the network stack so they can intercept and redirect traffic, and redirecting DNS queries is one approach to send traffic to either advertising that they get paid for or phishing sites where they can steal banking or credit card information. Even if an infection has been cleaned, it’s possible that a part of it was left behind and could still be causing problems. Antivirus boot/rescue CDs are great for this for two reasons: first, they clean the system of many of the more obtrusive problems and second, if they’re able to update over the Internet then it indicates that there’s not a hardware problem – just a Windows problem. Result: Nothing Found, possibly because I wasn’t the first person to look at it.
While those scans were running, I also checked whether it was a firewall issue though that seemed unlikely since nslookup was working. I have seen a major brand of “Internet Security Suite” decide to block DNS queries in the past, so I always check that. Result: Not the firewall
Microsoft has a couple of options for doing repairs to the TCP/IP stack and Winsock, both of which can be damaged by some malware. Assuming that you’re reasonably up-to-date, you can look at How to reset Internet Protocol (TCP/IP) (KB299357) and How to determine and to recover from Winsock2 corruption (KB811259), both from Microsoft. Both of these apply to Vista and Server 2003 as well as XP. Read the cautions in these, you may need to reinstall some software that works with the Internet after using these. Result: these didn’t help either.
Windows does some caching (saving copies) of DNS lookup results, but the service that provides that isn’t critical – it just sometimes makes things faster. To see if that was the problem, I tried queries with the “DNS Client” service (as listed under Control Panel, Administrative Tools, Services) running and stopped. To start or stop it from the command line, use net stop dnscache and net start dnscache. Result: Not the DNS Client/dnscache
In the category of things I don’t expect most people to try, I checked the network traffic to and from the PC using Wireshark (formerly Ethereal, the portable version). The network traffic looked fine, but only DNS queries from nslookup were making it out – no other queries were being attempted. This is an advanced thing to check and for most users the results of using this tool will not make any sense, so unless you know what a packet sniffer is just ignore this step.
Finally, if nothing else has done the trick, you can try Winsock XP Fix. This depends on the fact that some important registry items are the same between different installations of Windows, so it’s able to completely remove those items and re-add them. In some ways this is a last resort because it’s kind of like taking a hammer to the problem, but it can do the trick when nothing else has worked. I’m also only going to suggest using it on Windows XP or older systems – it hasn’t been updated since before Windows Vista came out, so it’s quite possible that running it on Vista, Windows 7 or server operating systems would break things.The Microsoft links above both apply to Vista as well as XP, so try those first.
Update: What’s Happening?
(Added November 29, 2009) Since I neglected to include details of what’s actually causing these symptoms, here are my suspicions.
All of the items that I tried for diagnosing the problem (including a simple Python program that I didn’t mention) are using the standard gethostbyname(name) call, which is part of the standard WinSock API. If you’re a developer you may note that it accepts only the name to be looked up with no way to specify name servers, because it uses the name servers specified for your current network connection. You can see what those name servers are by running the command “ipconfig /all” from a command prompt.
NSLookup is a tool that allows you to check what results a specific name server returns, using the default name server(s) if you don’t specify one. The advantage of the tool is that if you’re in an environment with multiple name servers, you can use nslookup to confirm that Name Server B is actually returning the correct values when queried. “dig” is another tool that can be used this way, but is not normally found on Windows systems.
Because nslookup allows you to specify what name server to use, it can’t just use the built-in gethostbyname() API call since that doesn’t allow you to specify a name server. For that reason, nslookup in effect has its own internal implementation of that same call which is unaffected by many problems with the WinSock portion of Windows as long as the lowest-level network communications are still working.
For a cooking analogy, nslookup always makes its own bread from scratch rather than buying a loaf at the bakery, so when the bakery’s oven fails nslookup is unaffected.
2010-03-18 Added mention that the Microsoft Knowledgebase links apply to Vista and Server 2003, which the final solution does not do.
[contact-form 2 “Was This Useful”]