Re: Poison in a zone

[Dean Anderson <dean@av8.com>]

On 26 Feb 2003, D. J. Bernstein wrote:

> Dean Anderson writes:
> > I'll write up the draft with these changes, if you agree.
>
> The existing draft was shoved into Last Call with huge problems. I'm
> still waiting for it to be withdrawn (or rejected).

I agree that the curent version is unacceptable, though, we also (I think)
agree that AXFR does need to be clarified.  We could reject the current
document and resubmit a new one, or we could extensively modify the
current one.  Is there any benefit to doing this one way over the other
way?

> There are obviously bigger problems here than clarification of the AXFR
> protocol. The discussion has revealed a huge gap between

We should add:

====
It is the responsibility of extended AXFR clients to preserve
compatibility with un-extended AXFR servers.
====

I think the issue with AXFR responses was addressed consistently with the
comments on your page.

Your comment about atomic retrieval of Zone Contents is supported by RFC
1035 Section 6.3 Second Paragraph.  This doesn't seem ambiguous to me.

I had proposed deleting section 3.4 of the clarify draft.  However, it
seems that to support concurrent UDP zone tranfers, either the question
section must be used, or the ID must be supplied by the AXFR server.

I also just noticed that I don't see anywhere that TCP is required for
AXFR. If UDP is to be used (why?), then one needs the ID in all UDP
packets.  Over TCP, unless non-AXFR data is to be intermixed in the TCP
connection, neither the ID nore the question matters. Including the ID in
all packets would permit multiplexing over TCP.  I'm for this, in general,
but it wasn't done previously. It could be the topic of a modified AXFR
proposal.  So, the clarification should also say that TCP is required for
AXFR. The question and ID sections are not required. Presence of the ID
and question sections in the responses should be accepted and ignored by
all AXFR clients. Neither client nor server is not allowed to interleave
questions or responses over the same TCP connection during an AXFR.

Regarding Poison, I think that such records could be discarded, but I
wonder whether it is necessary to require such records be removed.  It
seems to me to be enough to allow administrators and implementations to
remove such records, by removing the proposed requirement that no data
ever be deleted.  So I think that no further clarification is required.
This also addresses the database indexing issue.

Regarding the parent/child descrepancies, I think we have now demonstrated
that IXFR has no bearing on AXFR, and similar to the previous paragraph,
the implementation is free to discard such records.


However, I would like to move on the clarification, to clarify what the
existing AXFR definitely is and definitely is not, the way it was pre-bind
9.

> The real world is somewhere between these extremes. Perhaps we can have
> a rational cost-benefit discussion, now that BIND 9's disobedience of
> the cult has been exposed.
>
> Meanwhile, http://cr.yp.to/djbdns/axfr-notes.html covers several issues
> that aren't covered in axfr-clarify.
>
> ---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/>
>


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