-1

I have couple questions.

Firstly, this morning I was running ping against google.com and it returned me an address 216.58.220.14.

Now what strange happened was, any time after the first ping all attempt to ping resulted in same address i.e 216.58.220.14 (I was expecting different address at least some time considering google would be load balancing them)

So, I ask my friend (my colleague) sitting next to me(over the same network) to ping google.com and as I was expecting, it returned a different addresses.

Question 1: Does Ping uses machine DNS cache.

Question 2: How to display DNS caches entries of Linux(Ubuntu).

6
  • 3
    We have no way to know how the resolver is set up on your machine. Feb 18, 2016 at 9:06
  • @DavidSchwartz you want my resolv.conf it has google dns entries. 8.8.4.4 and 8.8.8.8
    – Viren
    Feb 18, 2016 at 9:16
  • Many commands and probably ping as well only resolve once and will use the resolved ip-address afterwards for their whole run, they won't resolve the hostname again before transmitting each subsequent ping packet.
    – HBruijn
    Feb 18, 2016 at 9:18
  • @HBruijn can you link me to original source. If possible.
    – Viren
    Feb 18, 2016 at 9:19
  • @Viren Well, nsswitch.conf would probably be more useful. We need to know what name services you're using. Feb 18, 2016 at 9:35

2 Answers 2

6

Which database will be used by the system to resolve a host name in a modern Linux system is defined in nsswitch.conf. https://www.oreilly.com/openbook/linag2/book/ch06.html

The Resolver Library

The term resolver refers not to a special application, but to the resolver library. This is a collection of functions that can be found in the standard C library. The central routines are gethostbyname(2) and gethostbyaddr(2), which look up all IP addresses associated with a host name, and vice versa. They may be configured to simply look up the information in hosts, to query a number of DNS name servers, or to use the hosts database of Network Information Service (NIS).

The resolver functions read configuration files when they are invoked. From these configuration files, they determine what databases to query, in which order, and other details relevant to how you've configured your environment. The older Linux standard library, libc, used /etc/host.conf as its master configuration file, but Version 2 of the GNU standard library, glibc, uses /etc/nsswitch.conf.

Assuming there is no entry for google.com in /etc/hosts file, every time the ping command is run, it will contact the dns server to resolve the hostname. So it all depends on how the dns server is returning the query. I have tested here with a test VM running Ubuntu 14.04, and using google dns server (8.8.8.8) and here are the results of ping command and corresponding tcpdump capture:

First ping and corresponding tcpdump:

root@testvm:/home/testuser# ping google.com
PING google.com (80.149.20.99) 56(84) bytes of data.
64 bytes from 80.149.20.99: icmp_seq=1 ttl=59 time=19.0 ms
64 bytes from 80.149.20.99: icmp_seq=2 ttl=59 time=18.7 ms
64 bytes from 80.149.20.99: icmp_seq=3 ttl=59 time=20.4 ms
64 bytes from 80.149.20.99: icmp_seq=4 ttl=59 time=18.7 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 18.733/19.261/20.467/0.715 ms

11:23:10.439152 IP 10.11.1.33.45008 > google-public-dns-a.google.com.domain: 48602+ A? google.com. (28)
11:23:10.482544 IP google-public-dns-a.google.com.domain > 10.11.1.33.45008: 48602 16/0/0 A 80.149.20.99, A 80.149.20.88, A 80.149.20.108, A 80.149.20.93, A 80.149.20.104, A 80.149.20.94, A 80.149.20.114, A 80.149.20.103, A 80.149.20.98, A 80.149.20.89, A 80.149.20.113, A 80.149.20.119, A 80.149.20.109, A 80.149.20.118, A 80.149.20.123, A 80.149.20.84 (284)
11:23:10.483370 IP 10.11.1.33 > 80.149.20.99: ICMP echo request, id 2397, seq 1, length 64
11:23:10.502433 IP 80.149.20.99 > 10.11.1.33: ICMP echo reply, id 2397, seq 1, length 64

2nd ping and corresponding tcpdump:

root@testvm:/home/testuser# ping google.com
PING google.com (80.149.20.98) 56(84) bytes of data.
64 bytes from 80.149.20.98: icmp_seq=1 ttl=59 time=18.1 ms
64 bytes from 80.149.20.98: icmp_seq=2 ttl=59 time=18.4 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 18.173/18.326/18.480/0.204 ms

11:25:34.118450 IP 10.11.1.33.51623 > google-public-dns-a.google.com.domain: 60862+ A? google.com. (28)
11:25:34.146881 IP google-public-dns-a.google.com.domain > 10.11.1.33.51623: 60862 16/0/0 A 80.149.20.98, A 80.149.20.84, A 80.149.20.89, A 80.149.20.118, A 80.149.20.109, A 80.149.20.114, A 80.149.20.103, A 80.149.20.113, A 80.149.20.93, A 80.149.20.119, A 80.149.20.104, A 80.149.20.108, A 80.149.20.123, A 80.149.20.88, A 80.149.20.99, A 80.149.20.94 (284)
11:25:34.147512 IP 10.11.1.33 > 80.149.20.98: ICMP echo request, id 2408, seq 1, length 64
11:25:34.165675 IP 80.149.20.98 > 10.11.1.33: ICMP echo reply, id 2408, seq 1, length 64

The interesting points here are:

  • ping is making a dns query (A record) to the configured dns server (as there is no entry for this host in /etc/hosts file) everytime the command is run.
  • the google dns server is returning multiple ips in different order.
  • the ping utility is using the first ip address returned from the dns server and sending an echo request to it.

So, there is no caching by the ping process itself as such and it all depends on how the dns server is replying. It can be that the queried dns server is returning cached values or same results then ping will also use the same ip.

Another important factor is (as mentioned above) the /etc/nsswitch.conf file, which tells the resolver what database to look for and in which order. Here is the relevant content from the test vm:

hosts:          files dns

The above tells the system to use the file /etc/hosts first and if not found there then the DNS server for host name resolution. In such a case an entry in the /etc/hosts file will have priority over dns record. More on this theme here: Name Service and Resolver Configuration

Another interesting read for Windows environment: Dilemma of Name Resolution Process with PING vs NSLOOKUP

7
  • ....but wrong. Linux (and most modern OS) use some sort of local caching for ns lookups. Fomerly (on Linux) this was handled by the resolver library with the cache memory allocated by the process - so there was a cache per process. For systems needing low latency lookups good admins would install a local DNS nameserver (usually bind) to cache requests. Nowadays you can use nscd (comes with most Linux distros) or dnsmasq.
    – symcbean
    Feb 18, 2016 at 12:31
  • @symcbean, I'm aware of dns caching, but in this case there is no dns caching involved. The OP is using google dns, and I have tested with same. The resolver library can use cache memory but how is that going to affect dns caching? Can you make it clear? And also, the answer is not about best admin practice. I could not find any information regarding moder linux os's using dns cache by default. So if you have some info regarding this, will be grateful if you could share.
    – Diamond
    Feb 18, 2016 at 12:42
  • ..@symcbean, and one more thing to make it clear, I have setup a test scenario similar to OP and explained the behaviour what I have found as far as I can. If you have another explanation for that behaviour, please post it as an answer. I might be wrong but I am open to learning.
    – Diamond
    Feb 18, 2016 at 12:45
5
  1. No, it does not, but overall it depends on the resolve. When you issue the command, the DNS entry is resolved into an IP address (yes, this is cache-dependent) and then the ping command protocol (ICMP) works with the IP address, not the name. That means if there is a DNS change while you continuously ping a destination, the result will not be influenced by that change. Cache is also not relevant here.

  2. Ubuntu does not cache DNS by default. NSCD daemon is the handler though.

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