8

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 (150.101.213.160) 56(84) bytes of data.
64 bytes from 150.101.213.160: 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 150.101.213.160 -c 1
PING 150.101.213.160 (150.101.213.160) 56(84) bytes of data.
64 bytes from 150.101.213.160: icmp_seq=1 ttl=61 time=14.5 ms

--- 150.101.213.160 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.

6
  • 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
    Commented May 15, 2014 at 16:41
  • @Ramhound No, look at the time at the bottom of the output. It's 5 seconds.
    – Sparhawk
    Commented May 15, 2014 at 16:42
  • You cleared out the DNS cache before each test right? Otherwise your test is invalid.
    – Ramhound
    Commented May 15, 2014 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
    Commented May 15, 2014 at 16:55
  • You can clear the dns cache by using ipconfig.
    – Ramhound
    Commented May 15, 2014 at 17:33

2 Answers 2

16

The delay is caused by ping trying to resolve the IP address back to a name1, by looking up 160.213.101.150.in-addr.arpa (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. http://150.101.213.160 would be an URL too.

3
  • 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
    Commented May 15, 2014 at 13:10
  • 3
    @Sparhawk: Because ping is asking it to. As far as DNS servers are concerned, google.com. and 160.213.101.150.in-addr.arpa. 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 1.2.3.4, it could be that 4.3.2.1.in-addr.arpa./PTR 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.) Commented May 15, 2014 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. Commented May 15, 2014 at 13:18
0

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

You must log in to answer this question.

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