Andrews admits that his configuration violates RFC 1034 section 4.2.2.
He also agrees that DNS servers are allowed to discard the inconsistent
parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to
some extent.)
However, because the _title_ of section 4.2.2 is ``Administrative
considerations,'' Andrews concludes that DNS servers aren't allowed to
discard the inconsistent parts of his configuration _if_ they obtained
data for the parent zone through AXFR rather than directly from an
``administrator.''
It would be easy to shred the details of that argument. I could point
out again that the configuration also violates section 4.2.1; the title
of section 4.2.1 is ``Technical considerations''; no ``administrators''
here. There are many other obvious mistakes in what Andrews says.
But there's a much larger problem here. Look at the overall structure of
Andrews's argument:
(1) Observation: This configuration, which is prohibited by RFC 1034,
doesn't work correctly with 77% of the installed base.
(2) Insane conclusion: 77% of the installed base is broken! We have
to change all of it to make this configuration work correctly!
Let's ignore all the objections, and declare the software used
for most of the Internet's DNS servers to be non-compliant!
Anyone who cares about interoperability will draw a very different
conclusion:
(3) Sane conclusion: The configuration is broken. Stop using it.
Andrews is trying to shift blame from the broken configuration to the
installed base. He's fighting against both RFC 1034 and the real world;
that's why he's resorted almost entirely to religious arguments about
proper implementation techniques for servers.
There is one spot where Andrews returns to reality. He points out that
his software (unlike mine) has never supported the synchronization
required by RFC 1034. Obeying RFC 1034 would mean, among other things,
changing all the BIND installations, which would be very difficult.
Does this mean that we need the broken configurations? No! There's a
middle ground between the synchronized configurations required by RFC
1034 and the broken configurations: namely, semi-synchronized
configurations (parent serial changing after all the child servers have
changed), which work with the entire installed base. RFC 1034 can be
modified to allow semi-synchronized configurations.
Mark.Andrews@isc.org writes:
> Even if we were to go down that path (which I don't believe we should)
Let me get this straight, Mark. You're screaming that the RFC 1034
requirement is too restrictive---because it requires synchronization
that your software can't handle---but you don't believe that it should
be changed to allow configurations that work with all existing software?
You know, Mark, this discussion would have been a lot easier if your
company had started by making an honest proposal to change the protocol,
instead of trying to sneak changes past us as ``clarifications.''
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago