On Fri, 27 Jun 2003, William Allen Simpson wrote:
> > "localhost."  DNS zone (as a master zone in all caching nameservers),
> > and NetBSD's default named.conf does so.
> Yes (RFC-1912).
> But that's not enabled by default, and not relevant.

Well, named is not enabled by default, but if you do enable named then
its default configuration *does* include a "localhost." zone.

> As the original PR clearly states (as a first sentence): 
> 
>  ! In a default install, the search order for root@localhost looks for 
>  ! localhost.domain before localhost.
> 
> Maybe the fact that it came at the end of a sentence made the 
> description unclear?  NetBSD isn't trying to find "localhost.", it's 
> trying localhost.domain (such as, localhost.example.net).

Your description was clear enough, and I did not misunderstand you; I
simply disagree with you.  In a working system, even if an initial
search for localhost.domain fails, that should not matter, because it
should immediately move on to searching for "localhost.", and that
should succeed, so there's no need for a localhost.domain entry.

> > If there's something that breaks due to lack of a localhost.domain entry
> > in /etc/hosts or in the DNS, then that problem should be fixed in some
> > other way, without adding a localhost.domain entry.
> > 
> As previously mentioned, the "something that breaks" happens to be the 
> daily security update isn't delivered on a default install.

Oh, I thought that that error was attributable to sendmail being
disabled by default.  The proper fix is to fix the mail system, not to
add unnecessary stuff to /etc/hosts.

> Certainly, based on RFC-1912, an argument could be made that some 
> domains would want to name a host "localhost.dom.ain", and the daily 
> security update will start being delivered to their root, instead of 
> its own.
> 
> Somehow, it gives me a more warm fuzzy feeling to know that some user 
> that really needs to talk to "localhost.dom.ain" on some other system 
> will have to remove a line from /etc/hosts.

I am not worried about somebody deliberately set up a host named
localhost.dom.ain with an address other than 127.0.0.1.

> Now, is it easier and better to change the library code, as you suggest, 
> and regression test all applications?  
> 
> Or, to add a 3 line change to sysinst, fixing one (currently duplicated) 
> line in the default /etc/hosts? 

I didn't suggest changing any libraries.  I claim that there's no need
to change any resolver or DNS related libraries.  There might be some
broken applications, or some applications that are improperly configured
by default, and they should be fixed.

I claim that adding a localhost.domain entry to /etc/host is at best
unnecessary, and at worst wrong; it's not fixing anything, and it might
be masking bugs elsewhere.  I can't remember when last I deliberately
used a localhost.domain entry in /etc/hosts or in the DNS.

> Remember, /etc/hosts is local only, and (supposedly) not cached for 
> DNS response to other hosts. 

Yes.  So, even if the nameservers mentioned in /etc/resolv.conf do not
provide a "localhost. A 127.0.0.1" record, having a "127.0.0.1 localhost"
line in /etc/hosts should be enough.

By the way, if you do have any applications that break when there's
no localhost.domain entry in /etc/hosts, and if you can't fix the
applications, and if you use DHCP, then you will also have to teach
dhclient-script to edit /etc/hosts whenever it edits /etc/resolv.conf.

--apb (Alan Barrett)