[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?

[Phil Pennock]

On 2012-09-27 at 22:05 +0000, Vernon Schryver wrote:
> } From: Phil Pennock <dnsop+phil at spodhuis.org>
> 
> }   It's possible that this could be used to defer DNSSEC responses to
> }   non-ANY queries too, during DoS; the RRSIG belongs in the ANSWER
> }   section, but a TC response which skips the RRSIG and causes a TCP
> }   retry would:
> }
> }   (1) return smaller results, turning off a large chunk of the
> }   amplification
> 
> How do you return smaller DNSSEC results but still verify?  If the
> recursive server thinks there are supposed to be crypto RRs thanks to
> DS RRs from the parent zone, won't the recursive server answer the
> local client with SERVFAIL if the authoritative answer doesn't verify?
> http://dns.comcast.net/ has real life examples.  SERFFAIL sounds less
> useful than an empty TC=1.

If the client is a legitimate resolver, it will retry with TCP and get
the DS RRs and be able to verify.  If the client is legitimate but
doesn't actually verify, it may have enough to go on with just the
regular results (although it shouldn't have been asking then).

It's a response which says "switch to a verifiable source, and here's a
small amount of data anyway".

> }   (2) with non-existent RR queries causing NSEC3 responses, defer the
> }   crypto work for NSEC3 until there's a TCP connection, which
> }   rate-limits the queries and reduces the CPU burden on the
> }   authoritative server
> 
> What authoritative server crypto work for NSEC3 is that?  Aren't NSEC3s
> pre-computed by dnssec-signzone or equivalent?  Check references to
> NSEC3 in your favorite hit in https://www.google.com/search?q=dnssec-signzone

Er, I confused minimal covering NSEC (RFC 4470) with NSEC3 (RFC 5155).

Sorry.

Does anyone have stats on RFC 4470 deployment?  Has it reached
"ignorable" status?

> }   All of this assumes that a modern server can be adequately tuned for
> }   TCP query volumes; for a dedicated DNS auth server, some very
> }   aggressive TCP state timeouts can be used (and can anyway, if the OS
> }   permits timeout tuning on a per-port/socket basis).
> 
> What does TCP tuning have to do with a DoS reflection attack?  Are you
> proposing that a server would punt all requests with TC=1 after seeing
> a flood of requests from one IP address block?  Without interesting

Almost.  Current mechanisms (DNS RRL) don't reply at all to many
requests during a DoS; the above replies with _some_ data, but punts to
TCP for the full response.

Note that for a reflection attack, the attacker will not set up TCP, so
the server does not have to scale up to TCP for every attack query,
"only" for the legitimate query volume.

The moment that you have TCP, with something like the
TCP-options-killing TCP cookie mechanism (to limit server state) you
have a valid source address and can rate limit on a per-IP basis more
aggressively.


> I trust you have looked at other imperfect solutions such as rate limiting
> by (qname,qtype,IP address).  In your estimation, how does that compare
> to trimming ANY and DNSSEC responses?

It works with limited server state and is a decent tool, but has the
side effect that service can be denied to, eg, a large ISP's resolvers,
so an attacker can knock a site intermittently off the net from the
perspective of a large percentage of the US population, by spoofing
traffic from those resolvers.

What legitimate source is there for ANY queries at high volume?  By
reducing the size, it works in combination with RRL to reduce outbound
traffic volume.

Trimming DNSSEC and requiring a retry over TCP vs/with RRL is where it
gets interesting; the question is if trimming DNSSEC reduces the volume
enough to reduce bandwidth to where RRL can be tuned to permit more
traffic and increase the odds of a legitimate query source get the
response which tells them to retry over TCP and get a response which can
be used to answer the user; the two together should reduce the false
impacts on legitimate traffic.

As I said, I was throwing out some ideas to see what sticks, to try to
increase the number of tools available.

-Phil