Subject: in support of axfr-clarify

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 05 Dec 2002 11:59:24 -0500

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

---

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

---

From: Bill Manning <[email-masked]>
Date: Thu, 5 Dec 2002 10:40:29 -0800 (PST)

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

Perhaps you missed this announcement to namedroppers:

To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-05.txt
Date: Tue, 03 Dec 2002 07:58:28 -0500
Sender: [email-masked]

[Part #1: Type: text/plain, Encoding: 7bit, Size: 2079]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

        Title           : DNS Zone Transfer Protocol Clarifications
        Author(s)       : A. Gustafsson
        Filename        : draft-ietf-dnsext-axfr-clarify-05.txt
        Pages           : 7
        Date            : 2002-12-2

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

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]

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 11 Dec 2002 20:23:41 +0100 (CET)

On Wed, 11 Dec 2002, Andreas Gustafsson wrote:

[ ah, a sensible mail ;) ]

> it is easily found through <http://www.iana.org/assignments/dns-parameters>.

Actually, both 2845 and 2930 refer to (in their References) 2136, where
NotAuth is defined (for reasons other than an RCODE listing).  Could 2136
be added to the References section for completeness?

> RCODE indicating an error?

Not acknowledging the request at all, terminating the connection
immediately.

> slave" case that was recently extensively discussed (to put it mildly)

The (corner) case that I'm thinking of is a large DNS server (for
instance, a root server) under a DDoS where Bad People(tm) are getting
said large DNS server to swamp its outbound link in replying to (lots of)
bogus AXFR queries.  Even if they're just short replies, its still
avoidable traffic.

( I'm trying to avoid possibilities where some dweeb claims that we must
  do this behaviour because 'It Is Written', I'm also trying to avoid
  possibilities where more creative DNS-based attacks are used. )

On 'unauthorised clients', I'm quite happy for said large DNS server to
reply 'Refused' up to a point.  Beyond that point, we should be able to
ignore irritating clients on that particular type of request.

> was previously allowed.

Hrm, that sounds like you're pointing the finger at implementors for
corruption caused through misinterpretation of existing standards (which
is ok).

Ok, skip this point.

> I'd rather err on the side of caution than

Heh.

--==--
Bruce.

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 12 Dec 2002 11:12:25 -0800 (PST)

> be added to the References section for completeness?

I suppose it could; that's just an editorial change.  Added.

> Not acknowledging the request at all, terminating the connection
[...]
> bogus AXFR queries.  Even if they're just short replies, its still

It's quite a small amount of traffic compared to the TCP connection
setup and teardown overhead - 14 bytes, to be precise.

In any case, I don't think making a specific exemption as part of the
AXFR protocol itself makes sense.  A DDoSer could cause just as much
harm by sending (e.g.) type A queries over TCP, and almost as much
harm just by opening lots of TCP connections without actually sending
queries.  A defense against this type of attack would have to work at
a lower level in the AXFR/DNS/TCP/IP protocol stack, by dropping
excessive requests regardless of type or even by dropping excessive
TCP connections without trying to receive a request at all.  If you do
that, you are simply refusing to speak the AXFR (or even DNS)
protocol, not closing the connection as part of the AXFR protocol.
--
Andreas Gustafsson, [email-masked]

---

From: Bruce Campbell <[email-masked]>
Date: Fri, 13 Dec 2002 18:28:58 +0100 (CET)

> I suppose it could; that's just an editorial change.  Added.

Thanks.

> setup and teardown overhead - 14 bytes, to be precise.

( Well, I wasn't going to be worried about TCP teardown persay )

> AXFR protocol itself makes sense.

Ok.

> A DDoSer could cause just as much
> harm by sending (e.g.) type A queries over TCP,

[snippery]

I've also reached the same conclusions, and think that I can find a more
general exception (ie, not specific to axfr).

This particular point can be dropped.

--==--
Bruce.