[geeks] DNS issue, localhost not resolving properly

[Ian Viemeister]

On Mon, 11 Dec 2006, Charles Shannon Hendrix wrote:

> I thought localhost was supposed to automatically resolve as long as
> it was in the local zone files

"localhost." will resolve properly if you have a localhost.zone or
equivalent file sey up (as in the example you posted).

"localhost" (as an unqualified name, no period) may be looked up as
"localhost.", or may be pulled from /etc/hosts, or may have the "search"
lines from /etc/resolv.conf appended to it and then looked up....

> and the local zone files listed the hostmasters FQDN in them.

I'm not quite sure what you mean there...

> When I ran Bind v8, a query on localhost returned the LAN IP address
> when run on the DNS server and MX lookup worked too.

As in "host localhost" returned "192.168.1.2"?  That's -- broken.
Did you have something odd in /etc/hosts?

> When I moved to Bind v9, localhost resolved to 127.0.0.1 and
> localhost.goid.lan didn't resolve at all.

Right.

> What I did today was add this:
>
> localhost IN CNAME escape.goid.lan.
>
> ...to my zone file for the LAN's domain.

That's probably *not* what you want to do.

> However, now my LAN thinks there is a host called localhost.goid.lan,
> which isn't really true, and I wonder what else this will trip up.

Well, any *other* machine that uses that DNS server for lookups, and
tries to lookup "localhost.goid.lan." (due to trying to qualify the name
prior to looking it up), will get that CNAME instead of "A 127.0.0.1".

If you have an entry for "localhost.goid.lan.", it should really have a
"A 127.0.0.1" record to avoid... odd problems with other machines on the
network thinking "localhost" is remote, etc.

> Or is it normal for the zone master of a domain to also be considered
> "localhost" for the domain?

No.

> > (A better question might be why sendmail is *looking* for localhost.goid.lan
> >  in the first place, but without knowing how the rest of the network is
> >  setup...)
>
> The short answer is that the RFC says so. That's also the long answer I
> got many years ago on the sendmail forums.

Um.  *Which* RFC says to configure sendmail to talk to
"localhost.your.domain.here"?  sendmail talking to itself on "localhost.",
that's fairly common, yes, but I don't recall any RFC specifying that,
either.

> My LAN has a machine called escape.goid.lan, which does email, DNS,
> news, and routing for the rest of the LAN. It has an ISP connection
> through a modem which is used for email and news.
>
> localhost is configured as the MTAHost in the submit.cf file, which is
> generated by my machine's m4 input files. The local domain's MX host is
> mail.goid.lan.

And *that* would be the actual problem.  Use "localhost." (with the dot),
or "[127.0.0.1]", or "escape.goid.lan.".  In your case, I'd recommend
using "[127.0.0.1]", as mentioned near the bottom of
<http://www.sendmail.org/m4/features.html>.

Put FEATURE(`msp', `[127.0.0.1]')dnl in whichever .mc file you are using
to generate submit.cf

> It's set up that way because the NetBSD documentation said to do it that
> way, and its been that way for about 12 years now.

Hopefully the NetBSD docs have gotten better since then ;-)

Seriously, email has changed just a *little* bit in 12 years, and
sendmail's behavior has changed along with it. Twelve years ago -- none of
us would have seen the point in a "spam filter".  Ten years ago, filtering
205.199.212.0/24 and a few others was enough.  Since then...

Er... sorry about the rant, I got off on a tangent there.  My point was
that you probably want to review sendmail configs more than once a decade ;-)

Right now, sendmail will try to fully-qualify a bare hostname in many/most
cases.  That's why you should be more explict when providing the MTAhost
option, instead of allowing sendmail to expand it on it's own.

> Doesn't mean it isn't wrong, just that I have no idea why.

Eh, just becase it's not a valid config *now*, doesn't mean it wasn't
previously.  sendmail's own sample configs previously used "localhost",
now they use "[127.0.0.1]".

--Ian