CNAME and other data , BUG #428

[Mark_Andrews at isc.org]

>  >  Yes.  Why should anyone expect a server to be coded to accept an
> > 	illegal configuration.
> 
> Yes I agree, BUT 
> look at my previous postings you will see that I showed a slave server
> loading illegal configuration.
> 65.96.180.71 ,a 8.3.4 server, loads a zone from a 8.1.2 master.

	So what if BIND 8.1.2 loads it.  BIND 8.1.2 was written
	assuming that the administator was competent enough to look
	for and correct errors like this when they were logged and
	BIND 8.1.2 does log a error message.

	We learnt through bitter experience that many are too
	incompetent to do this so we made it a HARD error.  Added
	to this was the support cost of explaining why their broken
	configuration was failing and why the zone wouldn't transfer
	to the slaves (cname at top of zone).

	So what if BIND 8.3.4 will loads the transfered zone.  It
	loads it on the principal of Garbage In Garbage Out.  We
	have learnt since that decision was made that it is better
	to just reject the zone.  BIND 8 is also at end-of-life.

	BIND 9 attempts to consistantly enforce zone contents
	regardless of the source of those contents.  We don't try
	to second guess zone administators, like BIND 4 and BIND
	8, did when we detect a error.  We just reject the zone.

	Mark

> have a look your self:
> dig @65.96.180.71 -t axfr example.com
> 
> 
> -----Original Message-----
> From: Mark.Andrews at isc.org
> To: Chimento, Douglas
> Cc: 'comp-protocols-dns-bind at isc.org'
> Sent: 12/5/02 8:04 PM
> Subject: Re: CNAME and other data , BUG #428 
> 
> 
> > 
> > Kevin,
> > 	These are good points, thank you for the info.
> > 	However my question really was , Should a slave server reject
> the
> > zone
> > 	with a CNAME error?
> 
> 	Yes.  Why should anyone expect a server to be coded to accept an
> 	illegal configuration.
> 
> 	BIND 4 and early BIND 8 issued warnings thinking that server
> 	administators were compentent and would correct the errors
> 	reported.  We know now that a vast number arn't compentent and
> 	that the only way to get incorrect configurations fixed is to
> 	make them fail.
> 
> 	Mark
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org