Re: Bind 9 AXFR Modification vs AXFR Clarification

[Mark.Andrews@isc.org]

> Good. You found a bug in an implementation. I thought such things were
> off-topic for this list.  This bug doesn't mean that AXFR is broken.
> Bind 8 did not have this bug, yet it has the common understanding of AXFR.
> 
> Let me summarize the discussion:
> 
> Everyone agrees that AXFR specification in RFC 1034 is ambiguous.
> 
> Some people, many associated with Bind 9 development, assert that it is
> necessary to change AXFR to support IXFR.  This assertion has been refuted
> on the grounds that incremental database update does not depend on AXFR,
> since incremental database update does not depend on the underlying wire
> protocol used to create the remote database which is to be modified by
> IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could
> still use IXFR, so, AXFR is independent of IXFR.

	Nobody is saying that preserving zone content is a *wire*
	issue.  It is a server behaviour issue.

> Some people, many associated with Bind 9 development, assert that AXFR as
> commonly implemented by many implementors over many years, is broken, and
> can't transfer domains correctly.  This claim has been refuted by
> demonstration by interoperability between Bind 8 and other nameserver
> implementations over the years, and 77% of the internet that currently
> does not use Bind 9, yet still does AXFR.

	All this shows is that these nameservers are not used in
	situations where the breakage is demonstrated or the
	administators have learn to work around the breakage or
	choose to live with it or are unaware of it.

> There being no other arguments raised for the Bind 9 AXFR
> clarify/modification proposal, it seems that this proposal is gratuitous
> and unnecessary, and should be rejected.
>
> However, we still have the issue of AXFR ambiguity to deal with, and we
> still need to clarify those ambiguities.  I would therefore like to
> organize a small group of people using implementations other than Bind 9,
> which we declare to be broken, to document the common implementation
> assumptions made, and submit that as a clarification to RFC 1034
> 
> To prevent confusion between the two proposals, I would like to rename the
> first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR
> Clarification". The term "axfr-clarify" will not be used.
> 
> 		--Dean
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org