Re: axfr-clarify supporting unauthorized users

[Kevin Darcy <kcd@daimlerchrysler.com>]

"D. J. Bernstein" wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  your subscription address is
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you
>   wish to regularly post from an address that is not subscribed to this
>   mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to
>   have the alternate address added to the list of addresses from which
>   submissions are automatically accepted. ]
>
> Mark.Andrews@isc.org writes:
> > Dan I asked you a reasonable question with reasonable pre-conditions.
>
> No, you didn't. Your preconditions contradict themselves. You start from
> the silly assumption that an unauthorized user, a user to whom the
> primary refuses to give the zone, can nevertheless be a secondary, and
> then you complain that the primary isn't doing what you think it's
> supposed to be doing for a secondary.
>
> Maybe your implementation has some sort of ``unauthorized users who we
> call secondaries even though they're not'' list, but there's nothing in
> the protocol requiring this.

Dan,
        RFC 1034 only mentions two possible outcomes of an AXFR request: "an
error, such as refused" or an answer consisting of "a sequence of response
messages", i.e. a zone transfer. Now, we all realize that circumstances beyond
the control of the DNS implementation may cause the connection attempt to fail
(network congestion, hardware errors, OS crash, whatever), or to be prematurely
broken, but RFC 1034, as a *DNS* spec, describes what a DNS implementation should
do (or attempt to do), and TCP FIN is not among the options here. Surely you can
see this, can't you?

Now, you can perform as much semantic acrobatics as you wish over whether that
paragraph only applies to "secondary servers" or not, but the fact that
"refused" is mentioned as a legitimate response to an AXFR request from "a
secondary server", combined with the fact that the companion RFC describes the
"refused" RCODE as "the name server refuses to perform the specified operation
for policy reasons" means that it is illogical to limit the definition of
"secondary server" to "only those entities which, by policy, are allowed to
request and/or receive zone transfers from me". To put it another way, the
definition of "secondary server" which you are proposing ineluctably leads to the
conclusion that "refused" could *never* be a valid, standards-conforming response
to an AXFR request. Yet clearly this line of thought is at odds with the RFC 1034
verbiage to which Mark refers.


- Kevin


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