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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users