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

I have an issue where hostnames are being looked up from DNS even though they are present in /etc/hosts.

I have the following configured:


order hosts,bind


hosts:      files dns


nameserver <nameserver one>
nameserver <nameserver two>

The application running on the host makes some internal and external API requests.

From tcpdump, I'm seeing DNS queries to some of the internal service hostnames that are listed in /etc/hosts. The tcpdump command I'm using is:

tcpdump -tqAlU -s0 port 53 and host <nameserver one>

In the dump I'm seeing requests like the following:

IP > app004-private.51308: UDP, length 102
.........I.1E...:...Q.. localhost............
IP app004-private.33828 > UDP, length 39
IP > app004-private.33828: UDP, length 96

Notice that localhost is being sent to DNS as well as The /etc/hosts entry for localhost is: localhost.localdomain localhost


IP > app004-private.51664: UDP, length 93
IP app004-private.51664 > UDP, length 48
IP > app004-private.48878: UDP, length 76
.P. .        :...Q.
IP > app004-private.51664: UDP, length 105

Where is in /etc/hosts. Running getent to query returns:

$ getent hosts   api001-private api001 api

I'm stumped. Everything appears to be configured correctly (as far as I'm aware) to use /etc/hosts first then DNS. Any insight as to why /etc/nsswitch.conf and /etc/host.conf are not being respected?

The main application running on the system is http (apache 2.2.15 and PHP 5.3.8 with curl 7.30.0). The OS is Centos 5.6 running with kernel 2.6.18-238.9.1.el5 and glibc 2.5-58.el5_6.3.

Thanks in advance!

share|improve this question
drsnyder's coworker here: we stumbled on a weird workaround: setting CURLOPT_IPRESOLVE to CURL_IPRESOLVE_V4 avoids the DNS lookup, as demonstrated here: – Frank Farmer Jun 20 '13 at 0:43
up vote 3 down vote accepted

We were able to resolve this by disabling ipv6. We disabled ipv6 by adding the following to /etc/modprobe.conf and rebooting.

alias net-pf-10 off
alias ipv6 off
options ipv6 disable=1

After reboot, we no longer see DNS lookups for hosts listed in /etc/hosts.

It's not clear to me exactly why this resolves the issue.

share|improve this answer
That's interesting.. I'd consider filing that as a bug upstream. – yoonix Jun 20 '13 at 22:11
And that one system that behaved correctly already had IPv6 disabled? – Nils Jun 21 '13 at 11:55
Yes, the one system that behaved correctly had IPv6 disabled. – drsnyder Jun 21 '13 at 15:52
One more reason to disable IPv6 - which I do on every installation. – Nils Jun 21 '13 at 21:06
Interesting. Is an IPV6 record defined for the hosts that were going to DNS instead of the hosts file? Just trying to narrow down how this quirk behaves. – Andrew B Jun 22 '13 at 15:46

There are many applications out there that do not use the OS-api to query names. Instead they do an explicit DNS-query.

If that happens - they will not go via the resolver library.

On Linux you can do the same on the command line:

  • host YOURHOST will try to resolve DNS - no matter what.
  • gethostip YOURHOST will use the defined resolver settings in the configured order.
share|improve this answer
One wrinkle that we have observed is that we have one system (out of about 10) that is behaving as expected with our application. This suggests that it's not the application, but something about the OS. As best we can tell, the two systems are configured exactly the same and have the same apache, php, curl, kernel, libc, and centos version. – drsnyder Jun 20 '13 at 16:17
@drsnyder there are config-items in apache/httpd and propably also in php for name-resolving. Did you compare all direct and included configurations? – Nils Jun 20 '13 at 20:15
all of the php and apache configs are uniform across all of the servers. They are distributed via puppet. – drsnyder Jun 21 '13 at 5:14

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.