Subject: Re: name service (does anyone else see this?)
To: John Hawkinson <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 08/06/1995 23:53:22
[ On Sun, August 6, 1995 at 17:36:14 (-0400), John Hawkinson wrote: ]
> Subject: Re: name service (does anyone else see this?)
> 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).
Hmmm.... So it is on SunOS-4.1.1_U1 (sun3) and BSD/386 1.1
On NetBSD-current/sparc and SunOS-4.1.3 and SunOS-4.1.4 I get no
response from ping.
On Ultrix 4.3 I get a bizzare address (though I don't know the network
of that host very well).
BUT, is this because of ping, ICMP packets, IP, or what?
I note that BIND's gethostbyaddr() returns 'Unknown host' for 0.0.0.0.
ttyp1:<woods@most> # host -d weird
;; res_mkquery(0, weird.weird.com, 1, 1)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16879
;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0
;; weird.weird.com, type = A, class = IN
;; Querying server (# 1) address = 0.0.0.0
res_send: recvfrom: Connection refused
> > 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.
Well, I jumped ahead a bit there -- you advocated using 127.0.0.1,
seemingly in favour of the real IP number, but I've experienced problems
with 127.1, so thinking 0 worked in more places than it does, thought it
might have a couple of advantages over the real IP number.
Now that I've done some real experiments I wish to retract what I
suggested about 0.0.0.0 and revert to promoting the use of the IP number
of the host's "primary" (or most well known) interface.
> > 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?
I don't directly, but there was a lot of discussion on the bind mailing
list that I promoted to bind-workers, together with a patch to the BOG
that resulted in the paragraph I quoted.
I do know that on SunOS-4.1.x, with pre-BIND-4.9.9-BETA17 resolvers,
including the native SunOS ones, in the shared libraries, putting
127.0.0.1 as the first "nameserver" entry in /etc/resolv.conf can hose
you at times if named isn't running, and sometimes during boot,
depending on the sequence of things. I can't re-create it at the moment
with BETA17's resolver, nor BETA24's, though I only tried on type of query.
If you mean to say that multiple "nameserver" entries are generally
broken, I can assure you they aren't. In fact my experiments to try the
127.1 hang just now explicitly prove that.
I think one prime example was sendmail hanging during boot if named failed.
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <firstname.lastname@example.org>; Secrets Of The Weird <email@example.com>