Redundant data in zone file.

[Kevin Darcy]

Looks we have a collision of so-called "Best Practice"s here. "Best 
Practice" #1 is (supposedly) for the NS'es of a zone, and the A (let's 
just stick with IPv4 for the moment to keep things simple) records 
referred to by those NS'es, to always be in the zone itself. "Best 
Practice" #2 is for each A RR to have a corresponding PTR RR."Best 
Practice" #3 forbids unnecessarily-large RRsets. But what if the same 
nameserver serves hundreds or thousands of zones? Then by Best Practice 
#1 we have hundreds or thousands of different A records referring to the 
same IP address, by Best Practice #2 each one of those A RRs must have a 
PTR RR owned by the corresponding in-addr.arpa name. But that violates 
Best Practice #3, because now our PTR RRset is unnecessarily large. It's 
not logistically/economically feasible to require a unique set of IP 
addresses for every zone for its nameservers (and that would break the 
"share the same source file among different zones" model anyway). And of 
course CNAMEs don't help here, since NS'es can't legally be pointed at 
CNAMEs. So something's gotta give.

                                                                         
                                                   - Kevin

Jonathan de Boyne Pollard wrote:

>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
>
>  
>