Re: axfr-clarify breaking RFC 1034

[Mark.Andrews@isc.org]

> 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.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
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.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.Andrews@isc.org