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

Reply via email to