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
BL> qualified.

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
    @       IN MX       1    IN AAAA 2001:0DB8::3    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> "" and "" as defined by your "NS"
BL> records.

This, because "" is a subdomain of "com." but not of 
"", 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:>.  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 mailing list