In message <500ea815.6050...@brandeis.edu>, John Miller writes: > 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.
No. It was a kernel bug. The kernel wouldn't let you un-bind the socket. When you sent to 127.0.0.1 the local address was set to 127.0.0.1 then when you sent to some other address 127.0.0.1 was used as the source address which doesn't work. Modern resolvers check for this and open a new socket. > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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
