CNAME and other data , BUG #428

[Kevin Darcy]

Doug,
          Please consider the following scenario: a caching server has a
CNAME record aliasing a.example.com to b.example.com. It also has A records for
both a.example.com and b.example.com. A query comes in for a.example.com/A. How
does it answer?

With the CNAME and the b.example.com A record (i.e. ignoring the a.example.com
A record)?

With only the a.example.com A record (i.e. ignoring the CNAME and the canonical
name to which it points)?

With a mish-mash of all 3 records?

There is a horrible ambiguity here, and even if one devises some "rule of
thumb" for how to handle such a situation, it all falls apart when you consider
that any combination of those 3 records could be expired from a given cache at
any given time. So answers for the same question will be inconsistent from
different caching servers, even with recursion in effect and even in the
absence of any master/slave replication delays or issues. This violates a
fundamental design goal of DNS.

Things get even uglier when negative caching is thrown into the mix.

In summary, there are *very* good reasons behind the "CNAME and other" rule.
The fact that old crusty versions of BIND kindasorta can deal with "CNAME and
other" doesn't mean you or anyone else should be perpetuating the travesty.
Modern versions of BIND are *right* to reject zones with "CNAME and other".
It's just *wrong*, and needs to be eradicated.


- Kevin

"Chimento, Douglas" wrote:

> Dude,
> Take a look at this set up:
>
> 192.223.154.69 is master for example.com , bind version 8.1.2
> ( dig -t txt -c CHAOS @192.223.154.69 version.bind )
> 65.96.180.71   is slave  , version 8.3.4
> ( dig -t txt -c CHAOS @65.96.180.71 version.bind )
> Now do a query for www.example.com ( do this like 4 or 5 times )
>   dig @192.223.154.69 www.example.com
>   dig @65.96.180.71   www.example.com
>
> Hmm....it seems to respond with answers, albeit they are "illegal" I have
> seen both windows and unix/linux dns clients accept these dns answers.
> (Although linux will syslog a warning)
>
> Currently our infrastructure consists of bind version 8.1.2 and we load 20 -
> 30 cname errors. Thus far , everything is running ok.
>
> Here is the point I am trying to make:
> The slave servers don't reject the zone when "Cname and other error" occurs.
> Which , I think is wrong, the slave should reject the zone.
>
> I have a patch for 8.3.4 to NOT make CNAMEANDOTHER a hard error Instead BIND
> will load the 1st entry and discard the 2nd and load the rest of the zone.
> However, if someone puts only
> "@ IN CNAME somethingelse", bind will load. Which is bad...I guess.
>
> FYI ---- example.com ZONE
>
> @       IN      SOA     bubba.example.com. root.localhost (
>                         3
>                         28800
>                         7200
>                         604800
>                         86400 )
>
>         IN      NS      bubba
> bubba   IN      A       192.168.0.254
> joe     IN      A       192.168.0.10
> www     IN      A       192.168.0.1
> www     IN      CNAME   bubba
>
> -----Original Message-----
> From: Nate Campi [mailto:nate at campin.net]
> Sent: Thursday, December 05, 2002 3:08 PM
> To: Chimento, Douglas
> Cc: 'comp-protocols-dns-bind at isc.org'
> Subject: Re: CNAME and other data , BUG #428
>
> On Thu, Dec 05, 2002 at 02:26:23PM -0500, Chimento, Douglas wrote:
> >
> > > If you actually serve such errors to the internet,
> > > your DNS won't work  anyways - so there's no point in disabling it.
> >
> > Huh?
> > Yes it will.
> > Are you saying that people running version 8.1.2 and lower with this
> > error won't work at all?
>
> Yes. I went to the trouble of explaining why. If you want to ignore it,
> that's up to you.
> --
> Nate Campi   http://www.campin.net
>
> "Those who don't read have no advantage over those who can't." - Samuel
> Clemens