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. 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. 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
