Subject: Re: name service (does anyone else see this?)
To: None <firstname.lastname@example.org>
From: John Hawkinson <email@example.com>
Date: 08/06/1995 17:36:14
> From: firstname.lastname@example.org (Greg A. Woods)
> To: John Hawkinson <email@example.com>
> Cc: firstname.lastname@example.org (Michael K. Sanders),
> mouse@Collatz.McRCIM.McGill.EDU, current-users@NetBSD.ORG
> > You should certainly use the loopback address in preference to
> > 0.0.0.0, which is entirely bogus. If any implementation accepts it,
> > it's confused itself.
> Since most TCP/IP implementations do accept 0.0.0.0 as the local host,
> and this is a very well known feature, there's no problem with using it
> where it works.
This is misleading.
> It certainly works on NetBSD-current:
> ttyp1:<woods@tar> $ telnet 0
> Trying 0.0.0.0...
Yup, and on my NetBSD/i386 boxes, and even on my SunOS boxes. But that's
telnet. Other programs:
[lola-granola!jhawk] ~> ping 0
PING 0 (0.0.0.0): 56 data bytes
64 bytes from 188.8.131.52: icmp_seq=0 ttl=255 time=1.466 ms
(184.108.40.206 is the default router).
> >From the BIND-4.9.3-BETA24 "Name Server Operations Guide":
> Note that if multiple \fInameserver\fP entries are desired in
> \fB/etc/resolv.conf\fP (assuming the first entry is intended for the
> local host's instance of \fBnamed\fP), the first entry should specify
> the IP number of the local host, and not 127.0.0.1. If your host's IP
> implementation does not create a short-circuit route between the default
> interface and the loopback interface, then you might also want to add a
> static route (eg. in \fB/etc/rc.local\fP) to do so:
> .(b l
> \fIroute add myhost.domain.name localhost 1\fP
> I.e. you should use 0.0.0.0 if your host(s) supports it,
I fail to see how you get that. I would read it as you should use the
IP address associated with the primary interface of your host.
> Many TCP/IP implementations will cause even the most modern DNS resolver
> implementations to hang in a query to 127.0.0.1 if the local named isn't
> running for some reason, regardless of the presence of additional
> "nameserver" entries in the /etc/resolv.conf file.
I don't think this brokenness is unique to 127.1, and probably happens
with just about anything you put there. Do you have any evidence to that?