CNAME and other data , BUG #428

Kevin Darcy kcd at
Thu Dec 5 23:54:06 UTC 2002

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

With the CNAME and the A record (i.e. ignoring the
A record)?

With only the 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:
> is master for , bind version 8.1.2
> ( dig -t txt -c CHAOS @ version.bind )
>   is slave  , version 8.3.4
> ( dig -t txt -c CHAOS @ version.bind )
> Now do a query for ( do this like 4 or 5 times )
>   dig @
>   dig @
> 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 ---- ZONE
> @       IN      SOA root.localhost (
>                         3
>                         28800
>                         7200
>                         604800
>                         86400 )
>         IN      NS      bubba
> bubba   IN      A
> joe     IN      A
> www     IN      A
> www     IN      CNAME   bubba
> -----Original Message-----
> From: Nate Campi [mailto:nate at]
> Sent: Thursday, December 05, 2002 3:08 PM
> To: Chimento, Douglas
> Cc: 'comp-protocols-dns-bind at'
> 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
> "Those who don't read have no advantage over those who can't." - Samuel
> Clemens

More information about the bind-users mailing list