Subject: Re: in support of axfr-clarify

From: Dean Anderson <[email-masked]>
Date: Thu, 5 Dec 2002 12:51:08 -0500 (EST)

Where is the axfr-clarify draft? What is it that you support?

		--Dean

On Thu, 5 Dec 2002, Bill Sommerfeld wrote:

> I support the current axfr-clarify draft as-is.
>
> --
> 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/>
>

--
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: Bruce Campbell <[email-masked]>
Date: Mon, 9 Dec 2002 11:52:53 +0100 (CET)

[ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt ]

> I support the current axfr-clarify draft as-is.

Section 3. could do with a reference to an updated RCODE listing (ie,
which RFC was NOTAUTH defined in?)

I would also like to see a clear exemption for responding to a zone
transfer request if the master server feels that the slave has made too
many queries in a short space of time (phrased in such a manner that the
slave will get at least one response in a given time period).

Section 6 is partially incorrect in stating that it does not solve any
existing security-related problems, in that by removing ambiguity of which
records to transfer, you are removing the possibility of errors in a given
zone corrupting information in other zones (on the same server), and
preventing the replication of such corruption further.

Is good otherwise.

--==--
Bruce.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 11 Dec 2002 10:58:57 -0800 (PST)

> which RFC was NOTAUTH defined in?)

I don't see such references in other pending drafts or recent RFCs.
For example, RFC2845 and RFC2930 mention NOTAUTH but neither
references an RCODE listing.  The draft already contains sufficient
information for implementation since it explicitly states the numeric
value of the NOTAUTH RCODE, and if you need to know the defining RFC
it is easily found through <http://www.iana.org/assignments/dns-parameters>.

> slave will get at least one response in a given time period).

What exactly do you mean by "not responding" in this case?  Not
sending the zone data, or not even sending a single message with an
RCODE indicating an error?

The former is already allowed; it would be a case of the server being
"unable or unwilling" to provide a transfer.  The latter would be a
bad idea for the same reasons it is a bad idea in the "unauthorized
slave" case that was recently extensively discussed (to put it mildly)
on namedroppers.

> preventing the replication of such corruption further.

I think saying that the draft "solves" this problem would be too
strong; for one thing, I don't want to imply that corrupting zone data
was previously allowed.  I'd rather err on the side of caution than
make a potentially controversial claim of improved security; this
draft has seen more than its share of controversy already.

-- 
Andreas Gustafsson, [email-masked]