Re: in support of axfr-clarify

[gson@nominum.com (Andreas Gustafsson)]

Bruce Campbell writes:
> [ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt ]
> 
> Section 3. could do with a reference to an updated RCODE listing (ie,
> 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>.

> 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).

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.

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

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.

> Is good otherwise.
-- 
Andreas Gustafsson, gson@nominum.com

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