CNAME and other data , BUG #428
Douglas.Chimento at FMR.COM
Fri Dec 6 00:01:17 UTC 2002
These are good points, thank you for the info.
However my question really was , Should a slave server reject the
with a CNAME error?
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Thursday, December 05, 2002 6:54 PM
To: 'comp-protocols-dns-bind at isc.org'
Subject: Re: CNAME and other data , BUG #428
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.
"Chimento, Douglas" wrote:
> Take a look at this set up:
> 220.127.116.11 is master for example.com , bind version 8.1.2 ( dig -t
> txt -c CHAOS @18.104.22.168 version.bind )
> 22.214.171.124 is slave , version 8.3.4
> ( dig -t txt -c CHAOS @126.96.36.199 version.bind )
> Now do a query for www.example.com ( do this like 4 or 5 times )
> dig @188.8.131.52 www.example.com
> dig @184.108.40.206 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 (
> 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
More information about the bind-users