[ On Tuesday, January 6, 2004 at 16:29:40 (-0800), Fred Viles wrote: ]
> Subject: Re: [Exim] Problems caused by localhost entry in Received
>
> I didn't see anything below to support the idea that a CNAME record
> should be used instead of an A record here. RFC1912 certainly
> doesn't say so.
Well it does, by implication:
There has been some extensive discussion about whether or not to
append the local domain to it. The conclusion is that "localhost."
would be the best solution. The reasons given include:
"localhost" by itself is used and expected to work in some
systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some
software to connect back to the loopback interface when it didn't
want to because "localhost" is not equal to "localhost.dom.ain".
> What is your rationale for preferring CNAME? Just
> to have it aliased to the name on the PTR record?
I don't "prefer" a CNAME -- it's the only valid way to achieve a static,
correct, and canonical configuration of the 127.in-addr.arpa private zone.
But of course you don't need, and probably shouldn't want, any
"localhost.your.domain" record in the first place. Just use the one
true "localhost." It's all you need (though see below ;-)).
> These SOA and NS records are broken. The SOA MNAME and the NS RNAME
> should be the FQDN of the nameserver, not "localhost.".
No, they're most certainly _NOT_. "localhost." _IS_ a FQDN, and since
it's also a private TLD, "localhost." is the sole and only possible
nameserver for that zone.
> |...
> | Yes, BIND does allow data from different zones in the same file, that's
> | what the "$ORIGN" setting controls.
>
> No, BIND does *not* allow data from different *zones* in the same
> file. $ORIGIN is simply syntactic sugar, of use if you want to
> reference a bunch of names under a *subdomain* of the zone being
> defined.
Well, it does, but yes, it has to be a sub-domain, though of course if
one assumes the zone file is loaded as ``zone "."'' then anything goes.
In the mean time remember I was only giving an _example_. If you want a
canonical, correct, and complete, working config then download my files!
> | No, and it should not be. This is just "localhost" and nothing more.
>
> No. The SOA MNAME and NS RNAME values must name an authoritative
> nameserver for the zone. Putting "localhost." here breaks any
> resolver running on a machine that is not also running a DNS server
> authoritative for "localhost.".
No, it doesn't break anything. "localhost." is a FQDN and a proper (and
private) TLD.
If you're not running a nameserver then you're only using a stub
resolver then the stub resolver is not going to try to ask 127.0.0.1 for
anything since it's a stub resolver and it's been configured via
/etc/resolv.conf to query some other nameserver, no matter what any NS
record it retrieves says.
If you are running a nameserver then it is (supposed to also be) running
on the host identified by the hostname "localhost.". Obviously.
I've been doing this for a _lot_ of years (long before RFC 1912 was
published), and quite successfully I might add, and not just in trivial
little configurations, but for entire ISPs, corporate networks, and such.
(I do however still have "localhost.my.domain" CNAMEs in any zones which
also host real hosts, just to keep all the whining users happy. ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
