Why is the command "ping -a" not able to resolve host names?

We have all windows 7 computers in our LAN. Got a question about resolving DNS:

When trying to use "ping -a" to resolve host names, I found it just doesn't return the host name for some computers, even they have an A record in the DNS server. Why could that happen? How to fix?
CastlewoodAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Imtiaz HashamTechnical Director / IT ConsultantCommented:
It depends if the device is responding with it's hostname and if it registers the hostname in the DHCP Server address?
0
JohnBusiness Consultant (Owner)Commented:
I am not sure where Ping looks for DNS, but I expect just publicly and not at your server.

So ping google.com works just fine, and ping servername works if servername is in your HOSTS file.

... Thinkpads_User
0
Imtiaz HashamTechnical Director / IT ConsultantCommented:
Thinkpads, wouldn't ping respond with the hostname if registered in the DNS via the DHCP server and because the hosts file is static, it wouldn't have anything about the PC which is dynamically assigned?
0
Redefining Cyber Security w/ AI & Machine Learning

The implications of AI and machine learning in cyber security are massive and constantly growing, creating both efficiencies and new challenges across the board. Join our webinar on Sept. 21st to learn more about leveraging AI and machine learning to protect your business.

JohnBusiness Consultant (Owner)Commented:
I cannot be sure because for the servers I use (small business), I have the server names in my HOSTS file.  So it may work locally. Ping certainly works everywhere else I tried.

... Thinkpads_User
0
Imtiaz HashamTechnical Director / IT ConsultantCommented:
None of my servers hosts files have any static entries.
0
JaniLSCommented:
I believe Ping -a uses netbios to resolve the name not DNS. **It may use dns after trying netbios resolution...? Surely someone here will enlighten me politely if it does**

If you ping -a any switch, printer or router that doesn't have a dns record, you may still recieve a name. I do not have any referance material to back it up but my take has always been that it uses the same mechanisms as a 'net view' command and showing the map of your network in 'network and sharing' center.

The non responding devices may not have network discovery enabled (most likely culprit). To check in Vista, 7 or 8... type network in the start menu and choose 'network'... when it opens up a yellow banner, much like internet explorer when it blocks a file download, will show in the title bar asking if you want to turn on network discovery. Network discovery is off by default as well as when on a public network
You can attempt to map your network from a non responding pc through 'network and sharing center' which would inform you if network discovery is turned off.
The non responding devices may not have netbois enabled
XP equivilent would be to check the firewall
I have also noticed that the -a must proceed the ip you are pinging?Im not a fan of picky syntax
0
alicainCommented:
Hello,

The -a switch initiates a "Reverse DNS lookup" to resolve an IP Address to a hostname.
To do this a PTR record is request in the relevant "reverse lookup zone"
The fact that you have an A record for the client defined, is not enough to do the reverse lookup of the IP address to host name.

If we consider an enterprise environment, with say a 192.168.0.1 subnet, your DNS server needs to have a reverse lookup zone configured for 192.168.0.0.  The procedure for how to do that is in the following article : http://support.microsoft.com/kb/323445

Once the zone exist, how the PTR record for the client gets into DNS depends on a number of factors, if the client or server has a statically assigned IP address, it will register the PTR record.
If the client gets its IP addresses via DHCP, there are choices that can be made on how it is configured. For more info see here : http://technet.microsoft.com/en-us/library/cc787034(v=ws.10).aspx

For other devices like routers or switches, it would depend on whether they are designed to do so...I don't know if modern ones do this, but if not the PTR record can be statically added to DNS.

Regards,
Alastair.
0
Imtiaz HashamTechnical Director / IT ConsultantCommented:
Hi Alicain,

I have to disagree with the PTR issue because we don't have a PTR on our client SBS networks and yet it resolves hostnames to most devices, except the ones that don't register their hostname - in my opinion - on the DHCP Server <- Where the DNS Server picks it up from.
0
alicainCommented:
Ihasham,

Which bit do you disagree with?

Here is an article from Microsoft that discusses the use of the GetHostByName API that is used by PING : http://support.microsoft.com/kb/822713
And this is the page for GetHostByName on MSDN : http://msdn.microsoft.com/en-us/library/windows/desktop/ms738524(v=vs.85).aspx

It is very easy to see this in action by download your favorite program from network tracing such as Wireshark or Netmon.  In here you will see the in-addrarpa. DNS name queries.  I needed to do that just the other day to answer a question on here as to why tracert was slow to resolve addresses to names.

If the IP address to name is not sucesfully resolved via a PTR record in DNS then yes, the resolver will continue to attempt other mechanisms based on the Node Type, and ultimately may resove it via a broadcast.

But...having the relevant reverse lookup zones configured and populated is the most reliable way.

Regards,
Alastair.
0
alicainCommented:
I should have also said...there is no method for DHCP to be resolving the IP address to name.

But DHCP is involved in the process of registering the PTR record, as previously mentioned.
0
Imtiaz HashamTechnical Director / IT ConsultantCommented:
Alicain, thanks for enlightening us :)

I will try the Packet Capture
0
JaniLSCommented:
Hymm... you are making it more difficult than it needs to be with the dns and reverse lookup stuff.

ping -a may eventually attempt to use dns to resolve an ip, as I said I cannot definatively say that it won't. Ping -a does however work without dns at all.
remove your dns entries from your nic, run ipconfig flushdns, and then ping -a an ip on your subnet
Do the same sequence and run a 'net view' command

Other mechanisms than dns are at play here. If some devices on your network are not resolving their names using ping -a then they do not have 'network discovery' (microsoft terminology) turned on. log into the PC which will not give up its name and open 'network and sharing'. Use the make network map function and you will recieve a message about network discovery being turned off. Turn it on... now it will advertise its name on the network as well as be available to browse through explorer.

I previously mentioned the little yellow bar. here is a screen shot from a Vista laptop... Yes I still have a pc with Vista... and I like it.

Note: it is a blue bar in Vista... yellow, blue... mehcapture of network discovery warning
0
alicainCommented:
JanilLS,

The key words in your description are "ping -a an ip ***on your subnet***"

In a flat LAN with a single subnet, yes this will fall back and eventually resolve successfully via a broadcast.  If you are in an enterprise environment, the broadcast will not resolve it and if DNS with PTR records are not available, the name will not resolve...which is the symptom that the OP has described.

Regards,
Alastair.
0
JaniLSCommented:
Negative.

I only work in enterprise environments and my experience tells me that if you do not turn on 'network discovery' on a new out of box win7 pc, you can ping by ip but not get a name from ping -a. Other symptoms include not showing up in a net view command as well as not showing up when browsing the network in windows explorer.

This will manifest when installing a network app on a new PC which wants you to point it to a shared directory. Until you turn on network discovery, nothing appears when you expand 'Network' in the explorer browser.

Additionally, if the PC / Laptop identifies the network you are on as 'public' it will not advertise either because 'network discovery' is turned off on public networks.

Additionally, yourdo not require reverse ip lookup zones in an enterprise network. ping -a, net view, and network discovery all work regardless. I manage dozens of enterprise networks that do not have reverse lookup zones.

Additionally, the commands do not care that I am on a domain network or public LAN when executed, they work exactly the same way in the background. It doesn't run one way if on a domain and another if not. The commands run at a lower level in the stack. Windows and firewall rules block the operations based on firewall settings and network location awareness (NLA) rules. Simply make sure NLA services says anything other than 'public' network and turn on network discovery.
0
alicainCommented:
Hi JaniLS,

This is turning into an interesting conversation...

The original poster's question is regarding the fact that the reverse name resolution from IP address to Name is not occuring for some clients.

You make good points about Network Discovery but for others reading, Network Discovery is about connectivity to the device (NetBIOS, UPnP, firewall rules etc), there is a good blog here : http://blogs.technet.com/b/networking/archive/2010/12/06/disabling-network-discovery-network-resources.aspx

I stick to what I said in the earlier post about PTR records and would politely disagree with you about not needing reverse lookup zones in the enterprise.  The following is taken from here and supports that : http://technet.microsoft.com/en-us/library/cc959303.aspx

"
Testing for Reverse Lookup Zones and PTR Resource Records
 
You do not need reverse lookup zones and PTR resource records for Active Directory to function. However, you need them if you want clients to be able to resolve FQDNs from IP addresses. Also, PTR resource records are commonly used by some applications for security purposes, to verify the identity of the client.
"

We could debate for ever the "You do not need..." in that quote and I carefully chose my words to say "having the relevant reverse lookup zones configured and populated is the most reliable way.

In mentoning "Enterprise environment" I was refering to the network, where name resolution would eventually falling back to a broadcast and would fail if on different network segments.

I have just taken a wireshare trace of a "ping -a SomeIPAddressOnTheNetwork" and the first packet on the wire is a standard query to DNS for a PTR record of the IP address in the .in-addr.arpa zone.  That's good enough to convince me...

If the OP had a PTR record for this host in his DNS server, then the ping -a would resolve the name.  The ICMP ECHO/REPLY may fail - for whatever reason firewall/network/etc - and he may not be able to connect to it for reasons like firewall enabled/network discovery being off/etc .... but the ping would do what was originally asked for...

It is  interesting how a seemingly simple question can result in such a long answer...

Regards,
Alastair.
0
JaniLSCommented:
I dont disagree with most of what you say, I just think you are making it more tech than it needs to be.

ICMP will use dns but it doesn't have to. When I tracert an internet address, I assume that the router names etc are derived form reverse dns lookup. OK

I am simply saying that in an unrouted connection from pcA to pcB icmp doesn't need dns. Heck it may not need it for routed connection as I never tested. What I do know is that Windows blocks your PC from giving its name on public network. (Public as defines by NLA) By default a new PC has Network discovery turned off which will not allow your PC to advertise its name either.

Your throwing around a lot of technicals and you could be right, but I would rather refrain from quoting white papers and technet articles when I have already tested this simple solution ... Turn on network discovery... it will basically tell windows that it is ok to advertise your name when asked.

By default this function is turned off on every OS since Windows Vista. Unless your domain has group policies specifically enabling network discovery, you will need to turn it on.

The OP can test this simple resolution and let us both know.

Regards
0
footechCommented:
Ping uses normal host name resolution.  By normal I mean it will try in order
 - DNS cache/HOSTS file
 - DNS
 - WINS
 - NetBIOS broadcast
The same applies whether for name-to-IP or IP-to-name.  The reason turning on Network Discovery works (at least within a broadcast domain) is that it enables the firewall rule to allow NetBIOS name resolution.

In my opinion DNS should be relied upon wherever possible and we shouldn't rely on NetBIOS.  DNS will work in scenarios where NetBIOS won't.  However, this isn't to say that NetBIOS doesn't work just fine in a number of scenarios (probably even the majority).  It just won't work across routers or VLANs.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.