using 127.0.0.1 in resolv.conf
Kevin Darcy
kcd at chrysler.com
Mon Jul 23 21:38:59 UTC 2012
We've been running with 127.0.0.1 in /etc/resolv.conf for years, on a
wide variety of platforms (including Berkeley-derived ones), and never
run into this bug.
127.0.0.1 in /etc/resolv.conf is good from a configuration-consistency
standpoint: it helps prevent the fairly-common accident where
/etc/resolv.conf is copied verbatim from an old server to its
replacement, and then DNS resolution on the replacement stops working or
degrades performance, when the old server is shut down and the IP
address that's listed first in /etc/resolv.conf is no longer available
(or other permutations, such as highly-firewalled environments where the
server configured with the blindly-copied /etc/resolv.conf can't even
talk to the server from which that file was copied). In theory, using
127.0.0.1 in /etc/resolv.conf might also help to offload traffic from a
NIC, if the NIC driver is written so poorly that it fails to recognize
and "short circuit" traffic destined for one of the local addresses
configured on the NIC.
The only minor drawback is that one can experience unexpected results,
in sortlisting terms, when performing diagnostics from the box itself,
since the loopback address is normally not included in a sortlist
statement. This is only a minor drawback, however, since it only applies
to one use case for a feature (sortlisting) that most folks don't use
anyway...
- Kevin
On 7/23/2012 5:13 PM, John Miller wrote:
> Hey there folks,
>
> I was just going back through the good ol' cricket book, and ran into
> the following:
>
> "If you use multiple nameserver directives, don't use the loopback
> address! There's a bug in some Berkeley-derived TCP/IP
> implementations that can cause problems with BIND if the local
> nameserver is down. The resolver's connected datagram socket won't
> rebind to a new local address if the local nameserver isn't running,
> and consequently the resolver sends query packets to the fallback
> remote nameservers with a source address of 127.0.0.1. When the remote
> nameservers try to reply, they end up sending the reply packets to
> themselves."
>
> Given that this same text is in the fourth edition of Cricket & Paul's
> book as well, I'm assuming this was an old bug (pre-BIND 9) and has
> long since been fixed. Could someone point me to a bug report and/or
> changelog for this? A quick Google search for 'bind resolver source
> address bug' didn't yield much.
>
> John
More information about the bind-users
mailing list