On Sat, 28 Jun 2003, Robert Elz wrote:
>   | Applications like ping, telnet and ssh do not exhibit the problem.
> 
> That's because they use getaddrinfo() (or gethostbyname()).   And they do
> exhibit the problem if your nsswitch.conf is sane (does DNS lookups only,
> or at least, DNS lookups before using /etc/hosts or other methods).

NetBSD's default nsswitch.conf has "hosts: file dns".  Yes, my
experiments would have produced different results with "hosts: dns files".

> Preferring /etc/hosts is just a recipe for disaster in general.

I think that depends on whether you administer many systems and are in a
position to keep the DNS sane, or whether you want to make a single
machine work despite broken DNS elsewhere.  For machines that live a
significant portion of their lives off net, I have also found
/etc/hosts a useful crutch.

>   | The default sendmail.cf tries to handle "localhost" as a special case.
> 
> I suspect you're misreading that.

I am looking at the top of ruleset "SCanonify2=96".  It's clearly
a special case for localhost, and it seems to be trying to rewrite
${user}@localhost to ${user}@${hostname}.

>   | We should also check whether postfix has a similar problem.
> 
> It should, as it should also be looking for MX records, and that means
> doing DNS queries, not hosts file lookups.   The normal recolver config
> on NetBSD appends the local domain to any name that has not dots (which
> is exactly what it should do, we don't want the root servers deluged with
> queries every time someone does "ping foo", we want it to assume that
> means foo.local.domain. first, and only fall back on "foo." if that fails,
> there are even good arguments for never falling back on "foo." if the
> name being queried has no dots in it at all - if you mean "foo." you
> can say "foo." - that's so rare as to be a very unusual case).

I agree that applications like ping, and even mail user agents, should
try appending the local domain name to things that look like unqualified
host names.  Most such applications have the option of allowing a trailing
dot to suppress the behaviour.

However, the SMTP and mail formats to not allow trailing dots in domain
names, and also do not allow unqualified host names to be used where
the protocol wants a domain name.  For thos reason, I believe that mail
transport agents should treat mail addressed to unqualified host names
as errors.

Sadly, sendmail is sometimes acting as an MUA and sometimes as an
MTA, and it's hard to know when it should or shouldn't try to qualify
unqualified host names.  I'd like to tell it "never try appending the
local domain to anything, unless you are sure that you are being used
as a user agent, not as a transport agent", but I don't know how to do
that.  So I am stuck with sendmail trying to append the local domain to
all sorts of things that were already fully qualified domain names; in a
way "localhost" is just one example of the larger problem.

> Of course, "foo" == "localhost" shouldn't be treated as any kind of
> special case.

Usually, I'd agree.  However, a system that is configured to treat
unqualified host names as errors should probably have an exception for
"localhost", which is actually a fully qualified domain name even though
it doesn't contain any dots.

> And this is also why sticking "localhost.domain. IN A 127.0.0.1" in
> all (relevant) forward zone files is still a *very* good idea (having
> "localhost." is useful as well, to save the root servers, though in
> practice it should rarely ever get used).

I have managed just fine for many years with "localhost. A 127.0.0.1",
"1.0.0.127.in-addr.arpa. PTR localhost.", and no mention of
localhost.${domain} anywhere.

--apb (Alan Barrett)