Re: in support of axfr-clarify

[Bruce Campbell <bc-namedroppers@vicious.dropbear.id.au>]

On Wed, 11 Dec 2002, Andreas Gustafsson wrote:

[ ah, a sensible mail ;) ]

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

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?

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

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

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

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.

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

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
> make a potentially controversial claim of improved security; this
> draft has seen more than its share of controversy already.

Heh.

--==--
Bruce.


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