On 07/24/2012 05:10 PM, Mark Andrews wrote:
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 r
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 c
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.
Th
I also use loopback regularly if running a localhost resolver; in fact I
use a script that goes as far as changing resolv.conf if it detects an
interface address instead of loopback. [Our rules require listening on
loopback minimally here]
If you do use it, I recommend you make sure you don't hav
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
5 matches
Mail list logo
