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