Re: axfr-clarify's fraudulent claims of consensus

[Mark.Andrews@isc.org]

> bert hubert writes:
> > Much of your criticism boils down to the fact that you do not have a
> > zone concept and do not want to have one, where 1034 and 1035 simply
> > ooze with zone definitions and they are clearly part of the DNS philosophy.
> 
> It's amazing how many errors you can pack into one paragraph. Facts:
> 
>    * My software has zones. It simplifies them for the user, by taking
>      advantage of the RFC 1034 database-consistency requirements.

	Your software (and BIND 8) causes operational problems by not
	preserving zone contents.

	By incorrectly merging data from child zones you can prevent
	a master from sending correct data.  You can also prevent slaves
	from sending the correct information.  You require administators
	to worry about silly timing issues.  You require administators to
	detect when the timing was wrong and update the serial numbers
	on zones just to get it retransfered with the original information
	because the server couldn't keep the zone contents seperate.

	Senario 1.

	Server 1 master for example.com and slave for division.example.com.
	division.example.com has been updated on it master to have
	new delegation information, the zone has not yet refreshed
	on server 1 for some reason.  You receive email with the
	new delegation information.  You update example.com adjusting
	its serial.  You reload example.com.  You expect the new
	delegation to be advertised in the outgoing zone transfer.
	This doesn't happen because the server messed with the zone
	contents.

	Senario 2.

	Server 1 master example.com
	Server 2 master division.example.com
	Server 3 slave example.com and division.example.com
	Server 4 slave example.com using server 3 as a master.

	Server 2 the delgation infomation for division.example.com is
	update and the parent zone is informed.   Server 1 is updated
	to contain the new delegation information.  Server 3 receives
	the updated parent zone before the updated child zone and
	notifies Server 4 which transfers example.com WITH THE OLD
	DELEGATION INFORMATION.  Both masters were updated to have
	the new delegation information but it doesn't get distributed
	to all the servers.

	You want the IETF to believe that this is *correct* AXFR
	behaviour.  This doesn't pass the giggle test.
	
	This is a common implemention error caused by trying to
	stuff all zones into a common database.  BIND 4 got it
	wrong.  BIND 8 got it wrong.

	You want us all to keep repeating this mistake.

	All that is being asked is that the data in AXFR is preserved
	so that it can be used as the data source of another AXFR and
	as a dataset to which IXFR deltas can be applied.  If you want
	to merge the zones for non AXFR requests go ahead.

	In otherwords what is entered as the zone data is what is
	transmitted as the zone data.

	I was very much aware of this issue when I was working as
	a systems administrator for CSIRO years before I started
	working for ISC.  We had to make regular sweeps of the the
	CSIRO.AU heirarchy to detect and clean up the errors caused
	by nameservers incorrectly merging zone contents.  I got
	very tired of having to explain to all of the different
	system admins what the problem was and how to "fix it" by
	incrementing the serial number and getting the zone
	re-transfered.

	Mark

>    * The relevant difference between my software and BIND 9 is that,
>      when my software sees some of the RFC-1034-violating zones allowed
>      by BIND 9, it boils them down to the RFC-1034-compliant parts.
> 
>    * BIND 8 does this to some extent too. It would sound pretty stupid
>      of you to claim that BIND 8 doesn't ``have a zone concept,'' don't
>      you think?
> 
>    * The BIND company's ``AXFR clarifications'' try to eliminate the
>      RFC 1034 database-consistency requirements, allowing data for the
>      same class+name+type to vary across zones, contrary to RFC 1034,
>      sections 4.2.1 and 4.2.2.
> 
> Furthermore, this zone mismanagement is only one of many problems with
> axfr-clarify.
> 
> If you decided to imitate BIND 9's database format in your software,
> feel free---but stop trying to force me to do the same thing. It isn't
> what my users want, and it's not necessary for interoperability.
> 
>   [ removing duplicates ]
> > Yes, you could build sophisticated hashes & stuff
> 
> Learn to program: ``sort -u''.
> 
> As for your suggestion to shift this programming burden to the server:
> You aren't thinking straight. There will be BIND 8 servers for the
> foreseeable future, so you'll have to continue removing duplicates for
> the foreseeable future. You'll be imposing a burden on servers without
> removing it from clients. Silly.
> 
> > I do like to have the ability to add TSIGs to an AXFR in the additional
> > section, even if that potentially breaks older remotes.
> 
> Again, you aren't thinking straight. Servers don't randomly use TSIG;
> they use it _upon request_. Random use of TSIG has no benefits; it's a
> pointless incompatibility, and there's no reason to allow it. (Besides,
> IPSEC does a better job than TSIG.)
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org