how to deploy new zone-transfer protocols

["D. J. Bernstein" <djb@cr.yp.to>]

[ 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
  54830374684695-namedroppers@sublist.cr.yp.to, 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 namedroppers-owner@ops.ietf.org and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

Mark.Andrews@isc.org 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.

> Can't you see that any implementation that CHANGES the
> 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.

---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/>