Re: BIND 9.2.1 patch, multiple RR's for singleton types.

[Jim Reid <jim () rfc1035 com>]

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