Re: axfr-clarify's fraudulent claims of consensus

[Mark.Andrews@isc.org]

> Mark.Andrews@isc.org writes:
> > Server 1 master for example.com and slave for division.example.com.
>   [ and division.example.com decides to change its NS records: ]
> > You receive email with the new delegation information. You update
> > example.com
> 
> Your hypothetical scenario breaks down here, for two reasons:
> 
>    (1) That configuration violates RFC 1034.

	It does not.

>    (2) My software doesn't allow that configuration.

	Well as we keep pointing out your software is BROKEN.
 
> Consequently, your claims of failure have no connection to reality. The
> situation simply doesn't occur. (What actually happens is that the NS
> record is updated when the child zone is transferred, as it should be.)
> 
> In more detail:
> 
>    (1) RFC 1034, sections 4.2.1 and 4.2.2, make crystal clear that the
>        NS record for division.example.com is supposed to be exactly the
>        same in the example.com zone and the division.example.com zone.

	But the parent version *IS* a exact copy in both of the
	senarios given.  Just because it is not what is in the *old*
	copy of the child zone doesn't make it not a exact copy.

>    (2) When my software is handling both zones, it enforces the RFC 1034
>        requirement, by unifying the data for the two zones. There isn't
>        a division.example.com NS record in the example.com zone separate
>        from the same NS record in the division.example.com zone.

	Which is a problem in your software as it is a problem in BIND4
	and BIND 8.

> I realize that, in BIND, there are two independent disk files with the
> two zones, so it's possible to separately change the NS record in the
> division.com zone. But that violates RFC 1034, and my software simply
> doesn't allow it.
>
> implementation decisions. If you persist in viewing everything through
> the language of BIND's configuration files, you're going to keep making
> false claims about the behavior of other DNS software. I strongly
> recommend that you read the specifications of the standard DNS protocol,
> specifically RFC 1034 and RFC 1035, before you comment further.
>
> ---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