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

[Tim Gladding <tim () gladding com>]

On Tue, 2 Jul 2002, Jim Reid wrote:

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

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.

******************************************************************************