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