using 127.0.0.1 in resolv.conf
John Miller
johnmill at brandeis.edu
Tue Jul 24 13:50:13 UTC 2012
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
More information about the bind-users
mailing list