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