Date: 20 Nov 2002 10:39:07 -0000
Message-ID: <20021120103907.63440.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: axfr-clarify on the move again
References: <200211200534.gAK5YOV17060@guava.araneus.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Andreas Gustafsson writes:
> the incremental zone transfer (RFC1995) protocol makes the implicit
> assumption that

As stated in http://cr.yp.to/djbdns/axfr-clarify.html:

   Gustafsson says that the IXFR protocol breaks if AXFR clients
   discard bad records. Well, that's too bad for the IXFR protocol.
   IXFR has an official status of Elective, and my users have a better
   protocol (rsync), so I am not going to support IXFR, and I object to
   the notion of IXFR-induced complications in the AXFR protocol.

The notion that _I_ should work to support _your_ stupid IXFR extension
is utterly absurd. Every optional protocol extension is responsible for
maintaining perfect compatibility with the unextended protocol. If IXFR
fails to meet this responsibility, IXFR has to be fixed.

I keep pointing out this basic flaw in your argument. You keep repeating
the argument, ignoring the flaw. I put all the arguments on my web page
so that the discussion could move forward; you ignore my web page, and
you secretly lobby the DNSEXT chairs to act without WG approval.

Of course, there's also the problem that you're fraudulently labelling
this protocol change as a ``clarification'' of the ``existing protocol''
in ``accordance'' with the ``fielded DNS server software.'' This isn't
even compatible with BIND 8!

  [ ``non-glue record below bottom of zone'' ]
> That's completely false.  BIND 9 does not reject such records, and
> never has.

I've investigated further. It was actually BIND 8.2.3, not BIND 9, that
introduced this interoperability problem last year. My apologies for the
error. Please substitute BIND 8.2.3 for BIND 9 at the relevant spots in
my message. (Do subsequent BIND 8 versions behave the same way?)

> RFC1035 goes as far as saying that the "suggested data structure" for
> a name server has "Separate data structures for each of the zones held
> by the name server".

RFC 1035 goes on to explain that this allows atomic updates of a zone
with a ``simple pointer replacement.'' It turns out that users are
generally happier with atomic updates of the entire database.

> Since the nodes are separate when the zones are on separate servers,
> it makes sense for them to also be separate when they zones happen to
> be on the same server.

Please stop trying to force everybody else to imitate BIND 9's
implementation decisions.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago