At 4:32 PM -0400 8/17/98, Skeelo wrote:
>How about having it answer 0.0.0.0 so you could use 'telnet 0.0.0.0' and
>other such commands. This is not strictly a DNS problem, many people
>expect a un*x system to answer a request to 0.0.0.0 and I know NetBSD did
>at one time. Why not just fix it so that it does answer (at least
>locally) requests to this address?

You would have to check the RFCs first.  0.0.0.0 is the old (Berkeley)
broadcast address, although its use as such has been depricated for a long
time.  DHCP, however uses 0.0.0.0 as the default client boot address (see
RFC 2131).  In routing, the zero net (as designated by 0.0.0.0) is the
default net such that it represents everything that is not on subnet.  In
the resolv.conf file, it can also mean "this host" but that is really the
only time that this is the case.  If you do telnet 0.0.0.0 and you have
assigned a default static route, you should get your router interface, NOT
your host.  (Solaris 2.5x handles this badly--it treats it as a link-level
broadcast.  If you did ping 0.0.0.0 on a such a host, you would get back
many responses on a populated subnet.)

Many OSs do not support the "this host" definition of 0.0.0.0, so the
official advice is to use 127.0.0.1.  (The forwarding bug dates back to
BIND 4.8.3, and has been fixed for many years.)  Because of the confusion
between default route, "this host," broadcast, and DHCP boot, I think we
should forget about 0.0.0.0 being equivalent to 127.0.0.1.


+++
Michael Sinatra			msinatra@uclin4.berkeley.edu
unix systems administrator	college of chemistry
university of california
berkeley, ca 94720-1460		(510) 643-1032