Subject: Re: in support of axfr-clarify

From: [email-masked]
Date: Fri, 29 Nov 2002 08:22:10 +1100

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   [email-masked], please post from it or
>   fix subscription your subscription address! ]
> 
> [email-masked] writes:
> > This is why you MUST preserve zone contents with AXFR.
> 
> No. If a screwy configuration causes problems with the deployed AXFR
> protocol, the solution is to outlaw the configuration, not to demand
> that the entire universe deploy new software.

	There is nothing "screwy" about that configuration.  It and
	others like it happen all the time in large organisations.
	Can't you see that any implementation that CHANGES the
	contents of a zone and then transfers it is BROKEN.  The
	purpose of AXFR it to transfer the zone unaltered between
	server.  If the server doesn't maintain the zone it is no
	longer transfering the zone.

	BIND 4 and BIND 8 AXFR implementations have ALWAYS been
	broken as they change the replace parts of the zones contents
	silently.

> Is interoperability such a difficult concept to grasp? If you want a new
> protocol, use a new query type. Using the existing AXFR type is clearly
> malicious: you're trying to hurt other implementors and users.

	The server behaviour was under specified.  Common sense
	says that you have to maintain the zone contents if you are
	going to be part of a zone transfer graph.  Clarifications
	are EXPECTED to correct mis-implementations.  We mis-implemented
	AXFR for years (and still do in BIND 4 and BIND 8).

	Mark

> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] 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: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Nov 2002 20:28:18 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  your subscription address is
  [email-masked], please post from it or, if you
  wish to regularly post from an address that is not subscribed to this
  mailing list, send a message to [email-masked] and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

[email-masked] writes:
> There is nothing "screwy" about that configuration.

You admit that this configuration doesn't work correctly with the
zone-transfer protocol as deployed in most servers. (My current survey
shows far more servers running BIND 8 than running BIND 9.)

You claim without evidence that this configuration is used ``all the
time.'' I'm perfectly willing to accept that some administrators have
tried it, but the suggestion that it's popular is simply wrong---even if
we ignore the fact that it doesn't work correctly with most servers.

Demanding that most DNS server administrators deploy new software, for
the sake of a few people who want to try this configuration, is, from an
economic perspective, downright stupid. (Of course, from the perspective
of a software company trying to squelch competition, it's a good idea.)

I'm not trying to say that you have to ignore those people. On the
contrary. You can define a new protocol that makes their configuration
work. For example:

   * Allocate a new MMAXFR query type.

   * Define an MMAXFR response format with all the constraints you want.
     Note that the response may be from an unextended server that treats
     MMAXFR as a normal type; remember that you created interoperability
     problems for IXFR when you screwed this up in BIND 9.

   * Require master+slave servers that received a zone in MMAXFR format
     to provide exactly the same bytes in response to an MMAXFR request,
     and to reject MMAXFR requests if they received the zone in anything
     other than MMAXFR format. One of the mistakes you made in IXFR was
     allowing an AXFR-then-IXFR chain.

   * To prevent zones from being horribly mangled by transfer bugs (such
     as many of the IXFR implementation bugs), use cryptographic hashes
     to supplement serial numbers. (For example, the SOA MNAME can start
     with an MD5 hash of everything else in the MMAXFR response.)

You can write software supporting this new protocol, and give that
software to the people who care. BUT YOU CANNOT IMPOSE THESE COSTS ON
EVERYBODY ELSE.

> contents of a zone and then transfers it is BROKEN.

``Can't you see that software that doesn't reliably report replication
errors to the zone creator is BROKEN? Can't you see that software that
doesn't transmit client-differentiation information (`views') is BROKEN?
Can't you see that software that doesn't transmit timestamps (records
being created or disappearing at a certain moment) is BROKEN?''

Everybody agrees that the zone-transfer protocol has limitations. That
doesn't give you the right to break compatibility.

In the words of Kernighan and Pike: ``Change the name if you change the
specification.'' You're violating this rule. You're trying to deploy a
new AXFR protocol with the same query type as the existing protocol.
You're threatening completely unnecessary interoperability problems---
telling people that they can use features of your new protocol as AXFR
features, when the existing AXFR protocol says nothing of the sort.