Redundant data in zone file.
Jonathan de Boyne Pollard
J.deBoynePollard at Tesco.NET
Thu Nov 18 04:44:13 UTC 2004
BL> Some DNS information, such as the target of an MX record, the SOA
BL> record, and the NS records may need (maybe "should") be fully
No. Only "may". Best practice for the intermediate domain names used
in delegations is that they be subdomains of the delegation point
itself. As such, if best practice is followed the domain names in the
data portions of "NS" resource records can be, and must be (in order to
implement that same best practice for all of the "zones" that share the
source file), unqualified:
@ IN NS a.ns
@ IN NS b.ns
a.ns IN AAAA 2001:0DB8::1
b.ns IN AAAA 2001:0DB8::2
Similar good practice applies in the cases of the intermediate domain
names in the SMTP Relay server information, albeit that the consequences
of gluelessness are less severe:
@ IN MX 1 a.mx
@ IN MX 1 b.mx
a.mx IN AAAA 2001:0DB8::3
b.mx IN AAAA 2001:0DB8::4
Similar good practice applies to the intermediate domain names in the
"MNAME" fields of "SOA" resource records. If one employs best practice
for the delegation information, one might as well re-use the
intermediate domain name for the content DNS server that one already has:
@ IN SOA a.ns hostmaster 1 28800 14400 3600000 86400
The use of fully-qualified domain names is *only* necessary if one is
following (in the case of delegation information) merely good practice
(i.e. intermediate domain names that are only subdomains of the
delegating superdomain), or downright bad practice (i.e. intermediate
domain names that are not within either bailiwick, superdomain or
subdomain, at all).
BL> the actual name servers for each of the zones would actually be
BL> "ns1.domain1.com" and "ns2.domain1.com" as defined by your "NS"
This, because "ns1.domain1.com." is a subdomain of "com." but not of
"domain2.com.", is merely good practice. It is not best practice.
BL> If you do NOT configure this virtual domain info for your web
BL> server, then everything would report back to the user as if it
BL> were for "domain1".
That's misleading. If virtual hosting is not configured, then the user
will still see the three distinct domain names. The three web sites,
that the user believes to exist, will be identical in content. But the
user will *not* see "domain1" if the URL is
<URL:http://www.domain3.com./>. With or without virtual hosting, the
user will see what appear to be three web sites. The difference is that
with virtual hosting, those three web sites may have differing contents.
BL> So, you can, and should, have a mixture of fully qualified domain
BL> information and partially qualified domain information in your zone
BL> file when you are creating a common zone file for multiple domains.
Actually, if best practice is followed, one should have unqualified
information throughout (with the exceptions of any client-side aliases
that point outside of the "zone" - but then those, too, should be a
rarity in themselves if best practice is followed).
More information about the bind-users