Andrews admits that his configuration violates RFC 1034 section 4.2.2.
It's a necessary and unavoidable reality to temporarily
violate it.
The only way to meet this all the times and at all levels
of the DNS is to have the all the zones administered on a
single machine *and* to have a multizone transfer protocol.
Lets go back to HOSTS.TXT, that meets this criteria.
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.)
No. I agree that server can be configured to correct PRIMARY
zones if they detect a inconsistancy and if they do so they
have to update the serial number.
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 is not the servers job to correct inconsistancies in SECONDARY
zones.
RFC 1034 states that a ACURATE copy of the zone is ESSENTIAL.
"The stream of messages allows
the secondary to construct a copy of the zone. Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests."
A modified zone is NOT a ACURATE copy. It's not even
a copy. It is a derived work.
BIND 4 and BIND 8 violate this section of RFC 1034.
BIND 9 does not.
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!
The installed base is broken. It doesn't matter if it is 1%,
77% or 100%.
Anyone who cares about interoperability will draw a very different
conclusion:
(3) Sane conclusion: The configuration is broken. Stop using it.
No. The sane conclusion is to deal with physical and
administative realities. To stop fighting the speed of
light and correct the implementations.
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.
It is good to see that you agree that Section 4.2.2 cannot
be met all the time. It is good to see that you agree that
enforcing agreement between zones causes problem. The
logical conclusion is to stop enforcing agreement between
zones where it causes problems.
Mark(_dot_)Andrews(_at_)isc(_dot_)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
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:
Mark(_dot_)Andrews(_at_)isc(_dot_)org