Subject: Re: axfr-clarify on the move again

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Nov 2002 10:39:07 -0000

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

---

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Sat, 23 Nov 2002 11:43:54 +0000

DJB>   * Under RFC 1034, the Domain Name System has a single node
DJB>     named full.moon.heaven.af.mil. The records at that node 
DJB>     are copied to any place that they're needed. If a copy 
DJB>     isn't exact, the copying mechanism has failed and should be
DJB>     fixed.
 
AG> RFC1034 talks about copying "NS and glue RRs" to the parent, 
AG> not entire nodes.

The text that you quote doesn't talk about copying entire nodes, either.  The
point that you are attempting to make isn't clear.  What is it ?

--
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: [email-masked] (Andreas Gustafsson)
Date: Sat, 23 Nov 2002 17:45:30 -0800 (PST)

> point that you are attempting to make isn't clear.  What is it ?

It said "copy the records", which I would interpret as "copy all the
records" in the absence of further qualification.  I'm simply pointing
out that in fact only some of the records are copied, and therefore
there will be differences between the parent and child data for the
node even in a correctly configured DNS.  Please excuse me if I'm
stating the obvious.
-- 
Andreas Gustafsson, [email-masked]