>>>>> "Tim" == Tim Gladding <tim@gladding.com> writes:
Tim> However, your situation may preclude you from running BIND 9
Tim> either locally or at the site level. One such situation
Tim> would be that you are already running BIND 8 and you have
Tim> zones loaded that will not load in to BIND 9 because they
Tim> have multiple resource records assigned to one singleton data
Tim> type. For example, an A record pointing to a list of CNAMES:
Tim> fuzzy IN CNAME www.snuggie.com.
Tim> IN CNAME www.r-9.net.
Tim> Normally BIND 9 would reject this as part of a zone.
Correct. And that's the way it should be. RFC1034 is very clear that
multiple CNAMEs are illegal. I quote:
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and
its aliases cannot be different. This rule also insures that
a cached CNAME can be used without checking with an
authoritative server for other RR types.
And before any DNS pedants chime in, this rule has been relaxed in
RFC2181 so that when DNSSEC is in use, a CNAME may have KEY, SIG or
NXT records.
Tim> To overcome this particular problem I have produced the
Tim> attached patch(1) to BIND 9.2.1 which, when applied, will
Tim> again allow you to use multiple CNAMEs etc. on one RR. This
Tim> patch is the equivalent of the 'multiple-cnames yes;' option
Tim> in bind 8.x.
This is a very unwise thing to do and I strongly recommend against
applying this patch. It will cause more problems than it apparently
"solves". Aside from creating a name server that violates RFC1034, the
patch needlessly creates an interoperability and software maintenance
nightmare. What if your slave (secondary) servers reject these illegal
multiple CNAMEs? What happens when the next BIND9 release comes along?
What if somebody else in your organisation installs it and they're
unaware of this special patch? Your patches miss a few things too:
like the code that parses named.conf or the documentation. For BIND9
the documentation does an accurate job of describing the code and it's
not nice to introduce gratuitous discrepancies.
The real solution to the question you pose is to fix the underlying
problem at source (forgive the pun). Get rid of the illegal multiple
CNAMEs. For the example above, just provide two A records for fuzzie
that have the IP addresses of www.snuggie.com and ww.r-9.net. And put
some comments in the zone file and version control logs explaining
what these RRs are for and why they are there. This will save another
maintenance headache for your eventual successor.
