Mark(_dot_)Andrews(_at_)isc(_dot_)org writes:
Changing the content of SECONDARY zones is outside of the
actions specified by RFC 1034.
Fact: Slaves _must_ discard records in some situations. A detailed
example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.
(There are many other counterexamples to your ``no reason'' claim.)
Fact: Slaves _do_ discard records in many situations. You claim that
this is ``wrong'' solely because it can break certain configurations.
You have admitted that RFC 1034 clearly prohibits those configurations.
It is the errors in BIND 4, BIND 8 and tinydns that introduce
timing constraints that are not part of RFC 1034
Fact: As you have already admitted, RFC 1034 _does_ impose these timing
constraints. As you have already admitted, RFC 1034 prohibits even the
slightest configuration inconsistency. In previous messages, you were
complaining about how severe the RFC 1034 consistency requirement is!
Fact: As above, your sole basis for calling the widespread BIND-8-etc.
behavior an ``error'' is that it doesn't work with your broken
configurations. Your sole basis for claiming that the configurations
aren't broken is _some_ DNS servers support them.
Fact: These broken configurations are going to continue to fail for the
foreseeable future. (As http://cr.yp.to/surveys/dns1.html shows, BIND 8
is more widely used than BIND 9.) It is essential for interoperability
that these broken configurations continue to be prohibited. Demanding
support for them would impose costs on at least two independent
implementations, without providing any benefits for the users.
Fact: Making the configurations work is a simple matter of updating the
parent---most importantly, the parent serial number---after (or at the
same time as) all the child servers are updated. This rule is easy for
administrators to follow.
All your complaints are based on your interpretation of RFC 1034.
Fact: There are no relevant disputes about the interpretation of RFC
1034. When I pointed to the sections of RFC 1034 that you are violating,
you admitted your violations.
change the serial number when you change the zone contents
Fact: That's part of what RFC 1034 requires. However, that's not even
close to a complete description of an RFC-1034-compliant glue-update
procedure. More importantly, it's not a complete description of a
glue-update procedure that works in practice.
IXFR depends upon
Fact: IXFR is an optional protocol extension. It is entirely IXFR's
responsibility to maintain compatibility with the preexisting,
unextended, protocol. It is not the responsibility of the installed base
to change for the sake of new protocol options.
Fact: When a protocol extension causes failures with most of the
software deployed on the Internet, you can't safely use the extension
without waiting for a massive upgrade. Users are much happier with an
extension that, at comparable cost, avoids the failures and provides
the same benefits immediately. I have explained to you how to do this
in the case of IXFR.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago