On Tue, 2 Jul 2002, Jim Reid wrote: > >>>>> "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. You're missing the point! > 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. Yeah, all very real and valid points, however, my patch is a quick, dirty, messy, throw it up now and fix 'em all later solution to the underlying problem that is multiple vulnerable resolvers living on your network of which not all will be patched in time for the holiday weekend because vendors just aren't coming out with the patches fast enough. Let's say you have 1,000 hosts of which only about half can be patched at the moment (remember, you can't just drop BIND 8.3.3's libbind on every piece of network equipment that does dns resolution), and 20 name servers currently running BIND 8. You want to protect those remaining 500 hosts by putting BIND 9 between them and the world but you can't simply run BIND 9 because you have possibly hundreds of zone files created by a huge number of people dating back several years, a number of which break RFC1034, to load. Sure, you can and SHOULD fix the errors in your zone files but are you going to be able to complete this task between now and the holiday weekend.. or are you planning to stay in the office through Monday? or perhaps you'd rather just leave those 500 hosts exposed to the world and pray that no-one figures out where you are and that you are still using a vulnerable resolver? In short.. yeah I know it breaks RFC1034, yeah I know you should fix your zone files instead, however, given the choice I'd rather have a holiday weekend with secure hosts sitting behind my patched BIND 9 servers! It's up to you, and judging by the number of mails I've received saying 'thanks!' or 'that's great but my mail server blocked your attachment, please please please send it to me!', the people agree :) Which reminds me, because lots of people were not able to receive the attachment, here is the patch again included.. enjoy! Tim Gladding ****************************************************************************** --- bind-9.2.1/lib/dns/rdataslab.c.orig Tue Jan 9 16:51:25 2001 +++ bind-9.2.1/lib/dns/rdataslab.c Mon Jul 1 22:49:19 2002 @@ -111,14 +111,14 @@ /* * Ensure that singleton types are actually singletons. */ - if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) { + /* if (nitems > 1 && dns_rdatatype_issingleton(rdataset->type)) { */ /* * We have a singleton type, but there's more than one * RR in the rdataset. */ - result = DNS_R_SINGLETON; + /* result = DNS_R_SINGLETON; goto free_rdatas; - } + } */ /* * Allocate the memory, set up a buffer, start copying in @@ -310,13 +310,13 @@ /* * Ensure that singleton types are actually singletons. */ - if (tcount > 1 && dns_rdatatype_issingleton(type)) { + /* if (tcount > 1 && dns_rdatatype_issingleton(type)) { */ /* * We have a singleton type, but there's more than one * RR in the rdataset. */ - return (DNS_R_SINGLETON); - } + /* return (DNS_R_SINGLETON); + } */ /* * Copy the reserved area from the new slab. ******************************************************************************
This archive was generated by hypermail 2b30 : Thu Jul 04 2002 - 23:51:40 PDT