Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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

[root@zop]# cat /etc/hosts       localhost     mydevice

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

17:28:48.330535 IP > ICMP echo request, id 14880, seq 0, length 64
17:28:48.333465 IP > 2+ PTR? (45)
17:28:49.312286 IP > ICMP echo reply, id 14880, seq 0, length 64
17:28:49.335601 IP > ICMP echo request, id 14880, seq 1, length 64
17:28:49.366973 IP > 2* 0/1/0 (104)
17:28:49.368286 IP > 3+ PTR? (45)
17:28:49.664215 IP > ICMP echo reply, id 14880, seq 1, length 64
17:28:49.742004 IP > 3* 0/1/0 (104)
17:28:49.743194 IP > 4+ PTR? (45)
17:28:50.038848 IP > 4* 0/1/0 (104)
17:28:50.040069 IP > 5+ PTR? (45)
17:28:50.335815 IP > 5* 0/1/0 (104)
17:28:50.337036 IP > 6+ PTR? (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       localhost   mydevice   whatismyip

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

17:15:35.795013 IP whatismyip > ICMP echo request, id 61212, seq 0, length 64
17:15:36.648193 IP > whatismyip: ICMP echo reply, id 61212, seq 0, length 64
17:15:36.809234 IP whatismyip > ICMP echo request, id 61212, seq 1, length 64
17:15:37.164276 IP > whatismyip: ICMP echo reply, id 61212, seq 1, length 64
17:15:37.819915 IP whatismyip > ICMP echo request, id 61212, seq 2, length 64
17:15:38.148193 IP > whatismyip: ICMP echo reply, id 61212, seq 2, length 64
17:15:38.827728 IP whatismyip > 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?

share|improve this question
What does /etc/resolv.conf look like? Does it contain If there are multiple IPs, are their gateways on separate interfaces? – Andrew B Jul 4 '13 at 1:03
/etc/resolv.conf does not contain - could that be the reason that DNS lookups are bypassed? /etc/resolv.conf contains openDNS server IP addresses as in "nameserver". I'm not sure I understand your question on multiple IPs and gateways on separate interfaces. Could you elaborate please? @AndrewB – xorsi Jul 4 '13 at 1:10
You shouldn't have in that file unless the machine is running a DNS server, so it's good that you don't have it. My other question was whether or not you had multiple nameserver lines, with each taking routes on different interfaces. If you're using OpenDNS that won't be the case. – Andrew B Jul 4 '13 at 1:22
@AndrewB There are currently three nameserver entries, all point to – xorsi Jul 4 '13 at 1:28
up vote 2 down vote accepted

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

share|improve this answer
Thanks for elucidating re: reverse/forward lookups. Page 395 of Practical UNIX and Internet Security by Simson Garfinkel, Gene Spafford, Alan Schwartz, 3rd Ed confirms your suspicion about tcpdump being the source of the reverse lookups. – xorsi Jul 5 '13 at 21:53

The order of lookups is usually controlled by /etc/nsswitch. Beware that if you have entries in /etc/hosts and that is the first lookup, DNS lookups won't occur. Make sure the entries are both static and correct.

If dns is first, /etc/hosts will only be used if dns lookups fail. If files is first, dns is only used if /etc/hosts fails.

The search and domain lines in /etc/resolv.conf may cause additional lookups to be tried if the name is not found. The ndots option can be used to indicate who many dots are required to disable use of the search and domain in searching.

You can use aliases in /etc/hosts tied to the first entry in search to prevent lookups with additional search domains.

share|improve this answer
There is no /etc/nsswitch on this embedded linux system. – xorsi Jul 5 '13 at 17:51
On an embedded system it may be coded into the resolver library. Knowing the resolver order is important to your desired behavior. – BillThor Jul 5 '13 at 23:29
Thanks, this was /etc/nsswitch.conf in Ubuntu – Chris Gunawardena Apr 5 '15 at 23:07

The DNS requests you see are Reverse requests mapping IP to a domain name:


Ping asks for the name of (presumably the IP of your client?). I didn't see any forward requests (resolving to an IP address) in your tcpdump output.

Now back to your original intent - which I assume is to reduce the network traffic. If you run nscd (Name Services Caching Daemon) you will generally see only one DNS request for each hostname and the nscd daemon will than cache it for you. That's a lot better option than keeping /etc/hosts up to date with network changes and renumberings.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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