On 6 Jan 2004 at 15:24, Greg A. Woods wrote about
"Re: [Exim] Problems caused by local":
| [ On Tuesday, January 6, 2004 at 20:13:02 (+0100), Giuliano Gavazzi wrote: ]
| > Subject: Re: [Exim] Problems caused by localhost entry in Received
|...
| > > If, and only if, you really want a "localhost.your.domain" name as well
| > > then you really should make that a CNAME in your local zone.
| >
| > not really (see below).
|
| Yes, _REALLY_. :-) (see below :-)
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. What is your rationale for preferring CNAME? Just
to have it aliased to the name on the PTR record?
| > > I.e. at minimum the following:
| > >
| > > $ORIGIN localhost.
| > > $TTL 24w
| > > . IN SOA localhost. hostmaster.localhost. (
| > > 1 8h 2h 24w 16h )
| > > . IN NS localhost.
| > > . IN A 127.0.0.1
These SOA and NS records are broken. The SOA MNAME and the NS RNAME
should be the FQDN of the nameserver, not "localhost.".
| > > $ORIGIN 127.in-addr.arpa.
| > > $TTL 24w
| > > 1.0.0.127.in-addr.arpa. IN PTR localhost.
And of course there should be SOA and NS records in this zone also.
|...
| 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.
|...
| > Or should localhost.
| > in the SOA and NS records substituted with the nameserver's FQDN? (I
| > do this way).
|
| 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.".
|...
- Fred
