Subject: Re: in support of axfr-clarify

From: [email-masked]
Date: Fri, 29 Nov 2002 08:28:03 +1100

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  your subscription address is
>   [email-masked], 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 [email-masked] 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: [email-masked]

--
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: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 22:25:38 -0000

[email-masked] writes:
  [ quoting RFC 1034 ]
> 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

See how this starts by saying that the SECONDARY SERVER does something?
You are not the secondary server. You have no authorization to even ask
for AXFR, let alone demand an answer.

Of course, there's also no support in RFC 1034 for your strange claim
that a closed connection is not ``an error.''

(As an engineering matter, every protocol has to allow connections to be
closed. Even when limiting unauthorized resource use isn't an issue,
hosts can and do crash. Forbidding this would be idiotic.)