Subject: Re: install/21999: localhost.domain not correctly set in /etc/hosts file
To: William Allen Simpson <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 06/27/2003 15:08:30
[ On Friday, June 27, 2003 at 08:37:44 (-0400), William Allen Simpson wrote: ]
> Subject: Re: install/21999: localhost.domain not correctly set in /etc/hosts file
> Alan Barrett wrote:
> > There's no need for a localhost.domain entry in /etc/hosts, nor for a
> > localhost.domain entry in any DNS zone files. I haven't used anything
> > like that for years.
> > There is a need for a "localhost" entry in /etc/hosts, and NetBSD
> > installs a suitable entry by default.
> Yes. Mentioned in the PR. Although there is no trailing period on the
> two A records.
/etc/hosts entries should not ever have trailing periods. /etc/hosts
names do not have the full semantics of DNS host domain names.
> 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).
What, exactly, in NetBSD is trying to find "localhost.$your_domain"?
> As previously mentioned, the "something that breaks" happens to be the
> daily security update isn't delivered on a default install.
What, exactly, "breaks" in /etc/security?
> 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.
That doesn't make any sense.
> 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.
That doesn't make any sense either.
> Now, is it easier and better to change the library code, as you suggest,
> and regression test all applications?
You haven't identified exactly what broke yet.
> Or, to add a 3 line change to sysinst, fixing one (currently duplicated)
> line in the default /etc/hosts?
As Alan says, nothing should be trying to resolve a host "localhost" in
any sub-domain in the first place, and anything that does is broken
(though of course such behaviour is not entirely unexpected given the
penchant of *BSD software to try to be helpful and qualify hostnames for
> Remember, /etc/hosts is local only, and (supposedly) not cached for
> DNS response to other hosts.
A nameserver should never look at /etc/hosts for any reason whatsoever.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>