Castlewood
asked on
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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Imtiaz Hasham
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?
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
... Thinkpads_User
None of my servers hosts files have any static entries.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
But DHCP is involved in the process of registering the PTR record, as previously mentioned.
Alicain, thanks for enlightening us :)
I will try the Packet Capture
I will try the Packet Capture
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.
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... meh
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... meh
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.
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.
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.
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.
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"
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.
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"
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.
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.