Thanks, Kevin. It sounds like if there was a bug in the resolver when
using 127.0.0.1, it's long since been resolved. For the reason of
portability alone, 127.0.0.1's a good choice, and what we've been doing.
I hadn't considered the NIC offloading issue, but I suppose it _could_
happen.
Thanks for your help!
John
On 07/23/2012 05:38 PM, Kevin Darcy wrote:
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
_______________________________________________
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
