On my Windows XP workstation, I can find the machine I want to connect to in DNS with nslookup:

nslookup wolfman
Server: dns.company.com

Name: wolfman.company.com

But, when I try to connect to that machine, I get an error telling me that the machine can't be found (i.e., can't be looked up in DNS):

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

I am able to connect if I use the IP address directly:

C:\> ping

Pinging with 32 bytes of data:

Reply from bytes=32 time=41ms TTL=126
Reply from bytes=32 time=41ms TTL=126
Reply from bytes=32 time=44ms TTL=126
Reply from bytes=32 time=38ms TTL=126

I could work around this by adding an entry to my hosts file, but I would rather find out why this is happening. The problem is transient, most of the day I can connect to the machine just fine.

How is this possible?

ETA: I left this out for brevity, but it was asked for:

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

ETA: Other applications get the same results. I only tried ping to simplify. telnet can't connect, Cygwin apps print a "unknown host wolfman" message.

Update: Using wireshark, I found that my workstation is not attempting a DNS lookup. It's just reporting the "could not find host" error message.

  • You could add a default DNS suffix for .company.com.
    – billc.cn
    Commented Oct 29, 2012 at 20:25
  • @billc.cn I already have that DNS suffix.
    – skiphoppy
    Commented Oct 30, 2012 at 16:35
  • What I think's happening is that ping isn't looking up the FQDN of the host, unlike nslookup which uses the search domain parameter of a DHCP offer (or whatever you specify for a static IP configuration). Confirm this by doing what @SLaks has said and pinging the FQDN of the host :)
    – jackweirdy
    Commented Nov 19, 2012 at 17:57
  • 1
    Possible duplicate of: superuser.com/questions/220471/… Commented Nov 19, 2012 at 17:57
  • What happens when you run ping -4 wolfman? Commented Nov 19, 2012 at 18:00

23 Answers 23


I believe that nslookup opens a winsock connection on the DNS port and issues a query, whereas ping uses the DNS Client service. You could try and stop this service and see whether this makes a difference.

Some commands that will reinitialize various network states :

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
(Caution: this will remove all your routes and gateways until you restart!)

  • 1
    I would bet Active Directory is probably active, but I do not know how to test.
    – skiphoppy
    Commented Nov 20, 2012 at 14:51
  • 11
    I disabled the DNS Client service, and the problem appeared to go away! Not sure yet if it was a fluke. The problem didn't come back when I restarted the service.
    – skiphoppy
    Commented Nov 20, 2012 at 14:55
  • 7
    Sometimes just stopping and restarting the service fixes DNS problems (don't ask me why). The question is how long this will last. Some unlucky people need to repeat it again and again.
    – harrymc
    Commented Nov 20, 2012 at 16:06
  • 1
    sfc /scannow in case the dns client service system files are corrupt subtly? I've also seen some people with similar problems caused by a virus. Commented Nov 26, 2012 at 5:27
  • 3
    use "route /f" with caution! It has just ruined my life!!! Commented Apr 20, 2017 at 15:49

Try ping with hostname followed by a dot. So instead of ping wolfman use ping wolfman.

That should get you resolving without having to do workarounds with hosts file, etc.

  • wow, this worked for me as well. My guess is that something expects a domain name which is not configured
    – user1190
    Commented Aug 10, 2016 at 20:46
  • 3
    OK, this works ... why?
    – Daniel B.
    Commented Sep 8, 2016 at 2:00
  • 6
    any suggestions why this is working and how to rather use locally names without trailing dots?
    – Ruberoid
    Commented Mar 6, 2017 at 20:01
  • 2
    Thanks - this worked for me but would also know why this would be working
    – Frank Fu
    Commented May 1, 2017 at 0:09
  • 2
    @Ruberoid Please see my answer for how to do this automatically. Commented Oct 9, 2017 at 11:54

Try adding . to the DNS suffixes for that connection. I.e, go to:

  1. Ethernet Status
  2. Click Properties
  3. Internet Protocol Version 4
  4. Click Properties
  5. Click Advanced
  6. Append these DNS suffices (in order)
  7. Add . as a suffix.

The same steps are illustrated in the following screenshot:

This should make ping wolfman work.


nslookup wolfman (name server lookup: wolfman) sends the hostname (wolfman) to the DNS (domain name system) to obtain the corresponding IP address. This is the sole purpose of the nslookup command. This works already, so we have verified that the DNS works and that wolfman indeed corresponds to an IP address.

In contrast, ping wolfman needs to do two things:

  1. Get the IP that the hostname (wolfman) corresponds to.
  2. Send packets to the IP and listen for the response

On Windows (even recent versions such as Windows 10), the first step can easily fail. For the sake of backwards compatibility, Windows supports various methods of hostname resolution (hosts file, DNS, NetBIOS/WINS, LMHOST file).

Unfortunately, it seems that Windows' ping command doesn't always attempt a DNS lookup. I don't know the specific conditions that triggers this behaviour.

Fortunately, we can force Windows to do a DNS lookup by using a FQDN (fully qualified domain name). In practice, we do this by suffixing a . dot to the hostname: wolfman.. Try ping wolfman. and verify that it works.

The final step is to force Windows to append this dot itself. I've already shown how to do this in the beginning of this answer.

  • 1
    Just want to say that this turned out to be the factor that succeeded on a machine I was working on. Stupid though it seems. And not just for ping, but for other applications too. I'm not sure your explanation of what's tried when is quite right (but you acknowledge you're uncertain on that). But a big plus for mentioning that this failure can be easily diagnosed by attempting ping with the domain name with a dot suffix manually added.
    – gwideman
    Commented Jun 28, 2018 at 9:55
  • This doesn't make sense. You're positing that, "Windows' ping command doesn't always attempt a DNS lookup," but then recommend changing how DNS lookups are performed to solve that? It seems more likely that ping is performing a DNS lookup(s) but is doing them incorrectly, and that's why this fix works. Commented Jan 14, 2019 at 13:57
  • 1
    @TwistyImpersonator I understand your confusion. The point is that Windows will attempt several methods of hostname resolution if given wolfman and a DNS lookup is (apparently) not a top priority among said methods. Now, if you use wolfman. instead, Windows will prioritize a DNS lookup over the other methods because wolfman. is a FQDN that (obviously) requires a DNS lookup. Commented Jan 14, 2019 at 14:24
  • So I think you're saying if ping got to the point of doing a DNS lookup in the course of its normal lookup workflow, it would work. However, ping should end up trying DNS if the other lookup methods don't return an answer, implying the reason ping fails on its own is because another method it's trying before DNS is returning an answer. That explanation doesn't fit the fact of ping not being able to find the host though. Commented Jan 14, 2019 at 16:58
  • @TwistyImpersonator "So I think you're saying if ping got to the point of doing a DNS lookup in the course of its normal lookup workflow, it would work": Yes. "However, ping should end up trying DNS if the other lookup methods don't return an answer, implying the reason ping fails on its own is because another method it's trying before DNS is returning an answer": Apparently not. Maybe ping just gives up after trying a couple of methods. Maybe ping gives up after a timeout. Maybe ping never tries a DNS lookup because it thinks the hostname is not DNS-like. Commented Jan 14, 2019 at 19:41

Try ipconfig /displaydns and look for wolfman. If it's cached as "name does not exist" (possibly because of a previous intermittent failed lookup), you can flush the cache with ipconfig /flushdns.

nslookup doesn't use the cache, but rather queries the DNS server directly.

  • 1
    I tried: it's not cached. And clearing the cache doesn't fix the issue, either.
    – skiphoppy
    Commented Nov 20, 2012 at 14:46
  • Can you post the output of nslookup -all? Is novc listed?
    – craig65535
    Commented Nov 20, 2012 at 18:22
  • Helpful, but for another problem diagnostic. Couples nicely with arp table! Commented Mar 28, 2022 at 16:19

nslookup works different to other commands when resolving names/ip addresses on Windows.

The normal resolution method on Windows is as follows:

  1. The client checks to see if the name queried is its own.
  2. The client then searches a local Hosts file, a list of IP address and names stored on the local computer.
  3. Domain Name System (DNS) servers are queried.
  4. If the name is still not resolved, NetBIOS name resolution sequence is used as a backup. This order can be changed by configuring the NetBIOS node type of the client.

nslookup on the other hand is used for testing Domain Name Servers.

  • 4
    Are there any settings that can move the NetBIOS query higher up in that list? I have the gut feeling that the NetBIOS lookup is involved somehow, but since the DNS query is definitely working I can't see how it would ever get to that step, if the sequence above is immutable.
    – skiphoppy
    Commented Nov 20, 2012 at 14:49
  • So ping would do more than nslookup to find the name. Why does it fail then? Commented Jun 1, 2023 at 22:17

I've struggled with a similar issue and have tried the solution suggested by @harrymc. I found what eventually seems to (at least somewhat) work at the microsoft technet forum (nslookup works but nothing else has DNS on standalone Win7 PC)

Here's the quote:

... try to use the command below to flush and reset a client resolver cache for test.

ipconfig /flushdns

ipconfig /registerdns

Please refer to the link below for more details. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

So basically what was missing for me was ipconfig /registerdns

  • 2
    original answer by @harrymc now reflects the missing /registerdns command Commented Jun 29, 2015 at 10:35
  • 1
    I've been playing whack-a-mole with this issue on Win10 for about a year. When my laptop wakes up it can't find any corp servers, but external sites like microsoft.com do work. It seems to happen when changing WiFi networks (home/VPN vs office). flushdns solves the issue sometimes but not always. Today I tried the registerdns and that immediately corrected the problem. Tomorrow I'll try adding . to the end of a name (but ping already fails with FQDN for internal servers). It's very frustrating. And to top it off - if I wait a while the problem will resolve itself.
    – ripvlan
    Commented Aug 14, 2018 at 13:51

Just today we had the same issue, but the solution was different. So I thought, I'd add it for reference as this was the top most search result.

  • Problem: ping will not resolve a host name, but nslookup can. (Observed on 2 different Windows Server 2012 R2 hosts.)
  • Cause: (For each host) The host has more than one NIC connected and there are multiple default gateways configured.
  • Solution: (For each host) Remove default gateway from configuration of all NICs but one, so there reamains only one default gateway.
  • ah this did it for me. Perfect. Commented Jan 26, 2016 at 0:39
  • Short and simple
    – Frank Fu
    Commented Mar 12, 2018 at 11:37
  • How can I see all of the default gateways without using the UI? Commented Apr 28, 2020 at 19:03
  • That is exactly what happens on me. Installed a VPN software and it added an NIC with a hardcoded IP. Commented Jul 29, 2022 at 15:55

I had the same problem on a Windows 2012R2 (=8.1) system, and tried all the above suggestions, but none of them would fix it:
- Pinging the fully qualified name worked.
- Pinging the unqualified name did not.
- Both worked on several other systems, that had the same OS and apparently the same configuration.
- All the necessary suffix search strings were there.
(Note that some of the proposed fixes, like the workaround for the multi-label queries, are obviously irrelevant, as the unqualified name has only one part.)

Then I noticed that the target system I was trying to ping did NOT have an IPv6 address. So I tried "ping -4 unqualified_name", and bingo! this worked.
So for some reason, on this system only, ping only tried to resolve unqualified name->IPv6 address, and not unqualified name->IPv4.
For me the fix was to disable IPv6 completely as I don't need it at all. But I'd be really interested to find a more gentle way to tell ping (or presumably the DNS client service) to try resolving both IPv4 and IPv6 addresses.


Maybe wolfman.company.com is listed in C:\Windows\system32\drivers\etc\hosts ?

nslookup bypasses that file and always asks DNS, while ping and other tools first of all look up in "hosts" file, then in DNS.

  • Good thought! But I checked, and neither of the machines I've seen this issue with are listed in hosts.
    – skiphoppy
    Commented Nov 20, 2012 at 14:47

I was trying to figure out why on one win 7 computer I can use ping server which works, and the other it can't resolve server. However both could ping server.lan which I didn't quite understand.

Turns out I had messed with some settings (DNS suffixes) to not have to use FQDNs while using the work VPN. I had to go add my local .lan to those suffixes in order to get both computers acting the same.

Go to Control Panel > Network and Internet > Network Connections and right click on your network connection and hit Properties. Click Internet Protocol Version 4 and hit the Properties button. Then the Advanced... button in this new window. Go to the DNS tab, this is where I had added a DNS suffix for my work but also needed one for my normal home connections.

Advanced TCP/IP Settings

  • I ran into a similar situation on a server with a static IP address. The first entry in the "Append these DNS suffixes" was blank AND the "DNS suffix for this connection" was blank. Other servers where it worked had the same blank "Append these DNS suffixes" BUT the "DNS suffix for this connection" populated.
    – Tim Lewis
    Commented Apr 7, 2016 at 17:29

I came across this issue as well. The "easiest" way to fix it for me was to simply add a . to the end of the hostname. However this is rather annoying. Most networks don't require this. I'd rather not have to tell everyone else on the network to do this when they need to access the same resource.

I was looking at the suggestion from Frederik Aalund as a possible solution and noticed that they suggested switching from the default "Append primary and connection specific DNS suffixes" option. This made me think maybe my network was simply slightly missconfigured.

Looking at my DD-WRT settings, the "LAN Domain" was left unset. Setting that to an arbitrary string seems to have fixed this issue for all clients on my network without having special configuration on each machine, the solution I wanted! :)


I'm picking this up because it bothered me the last year and maybe I found a workaround.

For me it seemed some dns-caching-system within the windows client is faulty. Windows 7 and 8.1 are affected by this... cannot say much about Windows XP anymore. ping doesn't resolve the name. it's not the icmp-part which is important but the name resolving part). nslookup is designed to query the nameserver and does exactly that and no windows name-hierarchy-resolving.

Restarting the dnscache service helped everytime. But since I disabled IPv6 on all client-interfaces the problem didn't occured anymore.


  • Disabling IPv6 may not be a viable solution for everybody (and it sounds anecdotal at best, anyway). Everything else you say seems to have been said already in this thread (e.g., harrymc’s comment “Sometimes just stopping and restarting the service fixes DNS problems”, two years ago). Commented Nov 3, 2014 at 15:31

I might be wrong on this because its based on my long-forgotten NT4 ressource-kit days.

As fare I can recall PING uses Netbios/WINS and DNS (in that order, at least if you don't specify a FQDN).

WINS is gone many year ago but you might still have Netbios enabled on your interface and PING therefore might use netbios that might not give you any result. Especially if traffic is passing a router somewhere.

Just disable Netbios and Ping will use DNS as first priority and append the registered DNS Surffic on the interface to your hostname.


None of the solutions here worked for me. What did work for me was reconnecting to my work's vpn using OpenVPN. Then after disconnecting everything continued to work.

I believe the issue was related to the power going out while my computer was connected with openVPN. The only way I figured this out was by using WireShark. I noticed that the destination IPs for all the queries were going to IPs on my work's internal network.

  • OpenVPN was the problem for me as well. Very strange
    – jle
    Commented Sep 17, 2020 at 1:03

Just had this issue on a Windows 7 client joined to a domain it turned out to be incorrect DirectAccess settings in the registry.

Try clearing the contents of the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig

and then restarting the 'DNS Cache' service.

Example of OpenVPN entry not cleaned up causing the issue

If that helps, look under the Group Policy Management Console for two policies called 'DirectAccess Client Settings' and 'DirectAccess Server Settings'. Check if they are configured correctly or even needed in your scenario. They are sometimes created automatically with certain settings for the Routing and Remote Access role on a server, and this was the cause of the issue on our part.



I have encountered this when we migrated to Windows 7 from windows XP, the issue was related to a Windows 7 Multi Label DNS Query issue.


Enable the following Group Policy:

Computer Configuration/Administrative Templates/Network/DNS Client/Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries

Or in the Registry (1 enables, 0 disables):

REG add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v AppendToMultiLabelName /t REG_DWORD /d 1 /f

Hope this helps

  • 2
    Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. Commented Mar 21, 2014 at 17:40

If on mac os x it might be an DNS Cache problem:

Dump the cache

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache
  • 1
    OP asks about Windows XP and question is tagged Windows.
    – P-L
    Commented Oct 20, 2017 at 15:38
  • Maybe it is helpful to others. I will leave it, the answer was here now for more than 3 years. Why delete now?
    – Christian
    Commented Oct 24, 2017 at 11:12
  • I'm on a Mac, but this didn't help.
    – Chris F
    Commented May 11, 2023 at 18:12
  • 9 years ago it helped. Maybe something changed or your problem is maybe not related to caching. Don't downvote 9 years later. Also the answer clearly states "if on mac" ... "it might be a DNS cache problem".
    – Christian
    Commented Jan 29 at 13:48

I have just had this problem, and found something quite peculiar, and managed to fix it Lol

Basically, if you have any entries in your hosts file, that are the same as the IP your ping is trying to resolve to, it will fail.

For example, if in your DNS, you have a record for www.example.com -, but then you have an entry in your client's hosts file, somethingelse.com, you will not be able to ping www.example.com

Strange huh


In my case what solved this problem was to add the domain of the host I was trying to ping to a group policy option named "DNS Suffix Search List".

The procedure in short is this: Open gpedit.msc and navigate to Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, set it to "Enabled" and add the domain name to the list (the list is empty by default).

A more detailed description of these steps can be found here


I had the same problem and turns out another machine had the same IP address, and that was causing it.

Changed IP back to DHCP and everything was working fine.

  • nslookup worked because it doesn't need to communicate with the other host. ping does need to communicate and obviously breaks.
    – ndemou
    Commented Feb 13, 2019 at 17:02
  • @ndemou: That explanation doesn't make any sense.  Yes, it is ping's job to try to communicate with the other host, but the first step in that process is to get the other host's IP address.  If it gets the other host's IP address, it tells you so; if it then cannot communicate with the other host, it ultimately reports "100% loss".  But, in the question, ping is failing even to get an address.  (Try ping bbbbbbb.com and ping bbbbbb.com for comparison.) Commented Feb 13, 2019 at 17:57
  • You are right @Scott. I was editing Klaus' answer and while reading his description of the problem I forgot that this questions particular problem with ping is that it doesn't resolve. Can't be sure but I would bet now that Klaus was just not getting replies.
    – ndemou
    Commented Feb 14, 2019 at 7:37

I have the same issuer in Windows 10. To fix it I remove registry folder: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache and restore it with backup from another computer where dnscache service (DNS Client) works fine.


There is a bug on the ping command from Microsoft.

If you try to ping a hostname without a route for it, the command returns "Ping request could not find host", instead of showing failure pinging the IP address of the host.

Example: Setup a DNS server with address. Create an A record called HOST1 pointing to Create an A record called HOST2 pointing to

Configure a windows client with IP address, without default gateway and DNS .

Ping HOST1 will resolve the ip adress. Ping HOST2 will result in "Ping request could not find host"


In my case, no one of the mentioned methods here helped. As appeared, the problem was with the missing HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain entry in the registry which had to be added manually (with just an empty string value). After I did this - the ping by hostnames started to work straight away even without reboot.

The answer was found at Windows 7 DNS not working (nslookup IS working; ping -4 name.com NOT working).

  • If there is already an existing answer, then this question should be flagged as a duplicate, instead of submitting an answer that simply points to another answer.
    – Ramhound
    Commented Mar 22, 2021 at 18:51
  • Looks like this is one of those cases where the same symptoms may have many root causes. I just point out one of those root causes which took me many hours to find out.
    – Andriy
    Commented Mar 22, 2021 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .