[ 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 18.70.0.1: icmp_seq=0 ttl=255 time=1.466 ms
> 
> (18.70.0.1 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.

Further:

	ttyp1:<woods@most> # host -d weird
	;; res_mkquery(0, weird.weird.com, 1, 1)
	;; res_send()
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16879
	;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0
	;; QUESTIONS:
	;;      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. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>