Fencepost Software & Consulting



« | »

(Fix) When DNS and ping Fail but nslookup Works (Windows)

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.

Winsock XP Fix is available from multiple locations, including Winsock XP Fix at PCWorld.com, Winsock XP Fix at Ramesh/MVPS, or other locations by searching for the name. Result: This did the trick.

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.

Updates:

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-7 404 "Not Found"]

Posted by on November 2, 2009.

Tags: , , , ,

Categories: Fixes & Troubleshooting

6 Responses

  1. Thanks for the info.

    I have this problem occasionally on the workstations of our network, where I am unable to ping by hostname or fqdn, but an nslookup works. (xp workstations, windows server 2003 r2 dhcp/dns server)

    restarting the workstation’s dns client sorts it, or an ipconfig /renew. In my case netbios is disabled on our network cards and I wonder if ping.exe switches to netbios sometimes, I guess i’d have to re-enable netbios on the network to find out.

    The winsock fix doesn’t solve it for me (though I have used winsock fix in the past to fix problems left by malware, successfully)

    Thanks, Rich

    by Rich on Dec 9, 2009 at 12:39 pm

  2. look at dns devolution. If you can ping the fqdn it is propbably the way dns devolution is setup on the client.

    by lenny on Jan 4, 2011 at 4:05 pm

  3. I had same problem on Windows 2003 active directory domain. The netsh interface reset all seemed to work. So did putting just a . in the DNS suffix search order. That is a workaround but was faster than having to redo the IP settings on all the machines.

    by Philip on Nov 2, 2011 at 1:26 pm

  4. Thanks Philip. Your trick of putting a . in the DNS suffix search order worked like a charm for some lab machines.

    by Darryl Kraemer on Mar 6, 2012 at 3:39 pm

  5. THANKS! the . in DNS suffix worked! I’ve been having the problem on one workstation for over a year. Seems FLUSHDNS usually provides a temporary fix. Today decided to do more research. I did DISPLAYDNS and was surprised to find my problem host was not in local DNS Cache. Still curious what’s going on here, but out of time for today. Thanks again.

    by Shawn Hughes on Mar 22, 2012 at 11:24 am

  6. Have this issue occasionally on my Windows 7 64b clients.
    Have used the . suffix to fix other problems successfully but was still having this issue.
    Isolated issue to clients dns cache and an unsuccessful client query for the host at boot.
    In my case the effected host is a Samba server named vm1
    In Windows Explorer, typing \\vm1 would fail to find shares even though the host was online.
    Checking the local dnscache indicated the host was not found. i.e. an entry for vm1 existed with no address.
    clearing cache, closing and reopening explorer rectified problem.
    In my case I was not able to rectify the host host look-up issue as the name server is a virtual machine that is powered off over night.
    I decided to reduce the TTL for the dns cache on the local machine to 5 mins and this clears up the problem quickly if it occurs.

    by Rob on Aug 6, 2013 at 5:45 pm

Leave a Reply

« | »




Recent Posts


Pages



About Fencepost Software & Consulting

Fencepost Software is Alan Miller, an IT consultant providing decision support, IT support and custom software and website development for small to midsize medical practices in the northwest suburbs of Chicago. He works with multiple practice management and electronic medical records (EMR) systems as well as email, groupware, messaging, networking and office applications. IT support […]more →

Switch to our desktop site