Re: in support of axfr-clarify

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

On Thu, 12 Dec 2002, Andreas Gustafsson wrote:

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

Thanks.

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

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

>
> In any case, I don't think making a specific exemption as part of the
> 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.


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