>>>>> "Tim" == Tim Gladding <timat_private> 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.
This archive was generated by hypermail 2b30 : Tue Jul 02 2002 - 14:59:38 PDT