Linux – Bypass DNS Server lookup by using /etc/hosts when using a dynamic IP address

dns-lookupdomain-name-systemembedded-linuxhostslinux

It is my understanding that the need to query external DNS servers for commonly accessed names can be reduced if those commonly accessed names are present in /etc/hosts.

Now, I have a situation where in I have an Embedded Linux box with a dynamic IP address. Let's assume this dynamic IP address is currently 206.190.36.105.

Here are the contents of my /etc/hosts file:

[root@zop]# cat /etc/hosts
127.0.0.1       localhost
192.168.0.1     mydevice
173.194.33.18   somesite.com

However when I run tcpdump and ping somesite.com, I still see that somesite.com is being resolved via DNS lookup. 

17:28:48.330535 IP 206.190.36.105 > somesite.com: ICMP echo request, id 14880, seq 0, length 64
17:28:48.333465 IP 206.190.36.105.57201 > resolver1.opendns.com.domain: 2+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:49.312286 IP somesite.com > 206.190.36.105: ICMP echo reply, id 14880, seq 0, length 64
17:28:49.335601 IP 206.190.36.105 > somesite.com: ICMP echo request, id 14880, seq 1, length 64
17:28:49.366973 IP resolver1.opendns.com.domain > 206.190.36.105.57201: 2* 0/1/0 (104)
17:28:49.368286 IP 206.190.36.105.59381 > resolver1.opendns.com.domain: 3+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:49.664215 IP somesite.com > 206.190.36.105: ICMP echo reply, id 14880, seq 1, length 64
17:28:49.742004 IP resolver1.opendns.com.domain > 206.190.36.105.59381: 3* 0/1/0 (104)
17:28:49.743194 IP 206.190.36.105.57388 > resolver1.opendns.com.domain: 4+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:50.038848 IP resolver1.opendns.com.domain > 206.190.36.105.57388: 4* 0/1/0 (104)
17:28:50.040069 IP 206.190.36.105.53513 > resolver1.opendns.com.domain: 5+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:50.335815 IP resolver1.opendns.com.domain > 206.190.36.105.53513: 5* 0/1/0 (104)
17:28:50.337036 IP 206.190.36.105.54248 > resolver1.opendns.com.domain: 6+ PTR? 204.220.167.10.in-addr.arpa. (45)

If I create an entry for the current IP address of the Linux box in /etc/hosts as in:

[root@zop]# cat /etc/hosts
127.0.0.1       localhost
192.168.0.101   mydevice
173.194.33.18   somesite.com
206.190.36.105   whatismyip

then tcpdump in tandem with a ping to somesite.com shows that the DNS lookup is now bypassed

17:15:35.795013 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 0, length 64
17:15:36.648193 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 0, length 64
17:15:36.809234 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 1, length 64
17:15:37.164276 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 1, length 64
17:15:37.819915 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 2, length 64
17:15:38.148193 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 2, length 64
17:15:38.827728 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 3, length 64

I'm interested in understanding the rationale behind this observed behavior. The Embedded Linux vendor claims that this behavior is normal and expected behavior – but rationally, shouldn't the DNS lookup be bypassed if only the destination IP address is not in the /etc/hosts file?

Best Answer

I think you're confusing forward DNS lookups with reverse DNS lookups.

Forward DNS lookups are going from a name to an IP address. If you look at the DNS packets in your first tcpdump, you'll see PTR? (pointer request), which is a request to translate an IP to a name.

z.y.x.w.in-addr.arpa is the IP being requested in reverse lookup notation. If you reverse that order, you get w.x.y.z, the IP address it's attempting to look up.

I suspect tcpdump is the source of the reverse lookup requests, not ping, as it has no need to perform a reverse lookup on your IP. When you add your IP to /etc/hosts, tcpdump no longer has a need to perform a reverse lookup on your IP, as your resolver library can locate it without performing DNS queries.

It's usually a good idea to run tcpdump with the -n option in order to avoid these lookups. They're usually not necessary.

Related Topic