[dns-operations] question for DNS being attacked

Vernon Schryver vjs at rhyolite.com
Thu Jun 28 14:06:05 UTC 2012


> From: Michael Graff <mgraff at isc.org>

> It may also make Kaminsky style attacks easier if an attacker can
> blind an auth server from handing out responses.  If the counter values
> are real from the RFC style paper, every other response becomes a
> truncated reply in a flood situation.  This will extend the attack
> window by  the time it takes to establish a TCP connection and query,
> or to the time it takes to retransmit the query plus TCP handshake if
> the blinding is successful.  This assumes the second query works.  But
> in reality it has the same chance as the first.
>
> Assuming about 100ms for TCP handshake and two seconds for timeout
> and retry followed by the TCP handshake, This means the window for
> potential false responses moves to about 1100ms on average.
>
> If a UDP reply would normally make it to the server in 100 ms, this
> opens a window 11 times as wide.

That conclusion does not hold, because it does not define the narrow
window alternative.  11 times as wide as what?

Causing a DNS server to stop answering your target is a security issue,
but the alternative to rate limiting based on (IP,qname,type,class)
is not infinite bandwidth.  If DNS server software does not rate limit
its own answers, then its answers will be rate limited by bottlenecks
in the path between the server and the client.  This is true whether
the bottlenecks are in firewalls or routers.

To prevent an authoritative server from answering your requests, I
need only trigger the rate limiting between it and you.  If the rate
limits are based only on bandwidth, then I will cause it to try to
send more than that limit.  Before botnets and DNSSEC, that often would
have been difficult.  Today I can send as many requests/sec as I want
and I can use DNSSEC to make the responses at least 20 and often 50
times larger than the requests.

Consider choices for IP bandwidth limits.  Because of the 20X-50X
amplification of DNSSEC, aren't ipfw/iptables limits likely to be
correspond to about the values that you would choose for (IP,qname,type)
limits?  What is the difference in a security attack whether an auth
server is silenced by random DNSSEC requests that overrun its output
bandwidth limit or its (IP,qname,type) limit?  I see these differences:

  - Depending on the security attack, the attacker might not know
     the qname.  In that case, the attacker must fall back to
     exploiting bandwidth limits.
     
  - During the attack, the server might still answer other queries 
     if it uses (IP,qname,type) limits.  Another way of stating
     this difference is that relying on bandwidth limits to stop
     participation in DoS attacks makes it easier for an attacker
     to completely silence a DNS server in other kinds of attacks.

  - (IP,qname,type) rate limiting makes it less likely that your
      DNS server will be used as part of a DoS attack.

(IP,qname,type) rate limiting is not a silver bullet and IP bandwidth
rate limiting using fair or any other queue discipline is not magic
pixie dust.


Vernon Schryver    vjs at rhyolite.com



More information about the dns-operations mailing list