Mark.Andrews@isc.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