I've noticed that pinging by hostname is slower than using the IP address. For example, in the Linux command line:

$ time ping google.com -c 1
PING google.com ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=61 time=14.4 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.425/14.425/14.425/0.000 ms

real    0m5.251s
user    0m0.003s
sys 0m0.005s

$ time ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=61 time=14.5 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.537/14.537/14.537/0.000 ms

real    0m0.019s
user    0m0.001s
sys 0m0.004s

I thought at first it was the DNS server taking a while to resolve, but when I ping by hostname, the first line appears almost immediately, showing that the IP address has already been determined. The five-second pause is after this DNS resolution, just before the (first) ping is received.

  • Are you really worried about a .100 ms rtt difference and a .001 sec system difference? You would need to repeat this test about a tne thousand times to actually determine once is faster then the other.
    – Ramhound
    May 15 '14 at 16:41
  • @Ramhound No, look at the time at the bottom of the output. It's 5 seconds.
    – Sparhawk
    May 15 '14 at 16:42
  • You cleared out the DNS cache before each test right? Otherwise your test is invalid.
    – Ramhound
    May 15 '14 at 16:44
  • @Ramhound I'm not sure how to do that. I did test it several times, but I'm not sure if the cache applies to both types of test.
    – Sparhawk
    May 15 '14 at 16:55
  • You can clear the dns cache by using ipconfig.
    – Ramhound
    May 15 '14 at 17:33

The delay is caused by ping trying to resolve the IP address back to a name1, by looking up (reverse DNS).

Normally the reply (whether success or nxdomain) should be instant, but it could be that it wasn't cached by your ISP and the authoritative servers for 213.101.150.in-addr.arpa were having problems at that time.

It might also be caused by misconfiguration or just bugs in certain DNS servers. If you see this delay happening every single time, it might be that your DNS resolver isn't properly caching replies when it should (even negative replies are cacheable).

When using the ping from iputils, add the -n option to avoid reverse-DNS lookups.

1 It's a domain name or a host name, not an URL; it doesn't specify any particular protocol or resource. http://google.com would be an URL. would be an URL too.

  • My ISP's DNS server has certainly been buggy, and this is more information for them, I think. -n makes it almost instant, but I still don't exactly understand why the DNS server would need to reverse DNS since I've already given it the domain name in the first place?
    – Sparhawk
    May 15 '14 at 13:10
  • 3
    @Sparhawk: Because ping is asking it to. As far as DNS servers are concerned, google.com. and are absolutely independent – they're even delegated by different organizations – and there is no requirement that they point to each other. For example, if mail.example.com./A has, it could be that has travis.example.com (server's actual name). So, for convenience, ping tries to reverse-lookup the IP address of whoever the ICMP reply was received from. (It might even be a router in the middle, sending an error reply.)
    – user1686
    May 15 '14 at 13:16
  • 2
    @Sparhawk: Also – multiple domains may point to the same IP address, and in rare cases the rDNS of one IP address may even point to several domains. Therefore, when ping does a reverse lookup, the DNS server cannot make any assumptions based on forward lookups it has seen, and vice versa. The only thing it can re-use is the cached results of the exact same query.
    – user1686
    May 15 '14 at 13:18

It's an IPv6 problem of the router, same as here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.