Re: in support of axfr-clarify

[gson@nominum.com (Andreas Gustafsson)]

Bruce Campbell writes:
> 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 suppose it could; that's just an editorial change.  Added.

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

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