ietf
[Top] [All Lists]

Re: axfr-clarify on the move again

2002-11-20 04:38:51
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



<Prev in Thread] Current Thread [Next in Thread>