Re: in support of axfr-clarify

[Mark.Andrews@isc.org]

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or
>   fix subscription your subscription address! ]
> 
> Kevin Darcy writes:
> > incanting "but it won't interoperate with my implementation!" as if
> > it were some sort of religious mantra
> 
> Interoperability is incredibly important in the real world. You have no
> right to go creating interoperability problems where none exist today.
> 
> > No, the purpose of clarifying AXFR is not to spread a "big tent" that
> > accommodates the idiosyncratic behavior of every AXFR implementation
> > out there.  Such a specification, if it is possible at all, would be
> > so watered down it would be useless.
> 
> That's absurd. In fact, many future implementors would benefit from an
> accurate specification of the existing AXFR protocol. This does _not_
> mean screwing up interoperability. It does _not_ mean documenting
> irrelevant BIND 9 implementation details as if they were the protocol.
> 
> > (as DJB's server apparently does, because he considers AXFR
> > client/server transactions to be "local matter[s]" rather than
> > something to be governed by protocol, go figure).
> 
> When did I ever say that local protocols aren't protocols? What I'm
> saying is that unauthorized users like you have no right to demand a
> response---or even to try to participate in the protocol in the first
> place. The protocol is for authorized users.

	RFC 1034 says to send REFUSED not drop the connection.  Please
	fix your BROKEN implemetation as it is not RFC 1034 compliant.

When the poll shows that the zone has changed, then the secondary server
must request a zone transfer via an AXFR request for the zone.  The AXFR
may cause an error, such as refused, but normally is answered by a
sequence of response messages.  The first and last messages must contain
the data for the top authoritative node of the zone.  Intermediate
messages carry all of the other RRs from the zone, including both
authoritative and non-authoritative RRs.  The stream of messages allows
the secondary to construct a copy of the zone.  Because accuracy is
essential, TCP or some other reliable protocol must be used for AXFR
requests.

> 
> > The general rules also say that if a server declines to answer a query
> > for some administratively-defined reason, it sends back an approriate
> > RCODE
> 
> No, the specifications don't say that. Servers can say REFUSED if they
> want to, but there's no rule saying that they have to.
> 
> > the Authority and Additional sections are reserved for
> > specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.)
> 
> AXFR responses include glue, remember? A server implementor who doesn't
> investigate existing practice could reasonably interpret RFC 1034 as
> _requiring_ use of the additional section. That would, in turn, cause
> failures with careless clients that don't look at the additional section.
> 
> I support requiring the careful server behavior. I object to prohibiting
> the careful client behavior.
> 
> Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP
> clients from sending non-ASCII header bytes, but clearly allows SMTP
> servers to accept those bytes.
> 
> ---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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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