[dns-operations] First experiments with DNS dampening to fight amplification attacks

Paul Vixie paul at redbarn.org
Mon Oct 1 07:33:15 UTC 2012

On 2012-09-29 2:28 AM, Mark Andrews wrote:
>>>> Are you referring to this?
>>>> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies
>>> Yes.  It's a reasonable way to identify non-spoofed traffic which
>>> means you can apply filtering techiques to the rest of the traffic
>>> which will be a mix of spoofed and non-spoofed.
>> i don't agree. there's no way to tell the difference between a client
>> who hasn't upgraded, vs. a client who has downgraded or is behind a NAT
>> box, vs. a spoofer. therefore we will not be able to drop non-cookied
>> queries even while under attacks which spoof the same netblock as we get
>> a non-cookied query from.
> It's about identifying non spoofed returning clients.  It does a good job of identifying that set of clients.  Those clients arn't using the server a reflector.  Those clients don't need to be penalised.

unless we can distinguish between packets from clients who don't
implement EDNS from packets which are spoofed this is a small comfort to
us or them. this is especially problematic for a large set of clients
behind a NAT.

> It also does a good job of protecting clients from off path spoofed replies.

i don't think i'd be willing to drop non-EDNS requests just on the basis
that some EDNS+cookies requests are coming from that address. so, no.

> For the server queries that present no cookie or a bad cookie go
> into the potentially rate limited pile.

i'm ready to accept that rate limiting (as specified by DNS RRL) hurts
non-spoofing clients who ask "similar enough" questions during the
attack. but so far this has not been demonstrated or even described. a
real recursive-service initiator may be forced to retry by UDP or even
by TCP. but a real recursive-service initiator will usually have a
cache. so the number of "similar enough" questions they'll ask will be
so small that the total pain of this delay is not worth the investment
of server-side state to solve for it.

> For clients the benefits come in less need to use multiple ports
> and knowing they are not going to be rate limited other than on
> initial queries when talking to servers that support cookies.
> This is about pulling out good traffic from the undifferentiated
> traffic we have today.

given that RFC 2671 was finalized more than a decade ago, we now know
the deployment curve of something like this. for that investment i want
more payback next time. thus, RFC 6013.

>> see RFC 6013, as earlier summarized in ;login:
>> (http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf),
>> for another approach to fixing not just DNS but HTTP state management.


"It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin." --rick jones

More information about the dns-operations mailing list