[ratelimits] adding "all-responses-per-second X"

Paul Vixie paul at redbarn.org
Sun Sep 16 22:53:59 UTC 2012

On 2012-09-16 9:11 PM, sthaug at nethelp.no wrote:
>>> Tony Finch recently mentioned DNS reflection amplification attacks
>>> spread among many valid domains at an authority server to evade rate
>>> limits on individual domains.
>> It was Klaus Darilion who said he had observed this kind of attack on his
>> servers. I was just speculating about how this kind of attack could be
>> mounted. Note that the attack can use many names within a zone as well as
>> many zones.
> I can confirm this observation. Example from one of our authoritative
> servers running 9.8.3-P2 and the ratelimit patch:
> 16-Sep-2012 16:00:10.825 rate-limit: info: limiting responses to for IN ANY adressa.no
> 16-Sep-2012 16:00:10.862 rate-limit: info: limiting responses to for IN ANY brreg.no
> 16-Sep-2012 16:00:11.282 rate-limit: info: limiting responses to for IN ANY ventelo.no

noting the following text from
http://ss.vix.com/~vixie/isc-tn-2012-1.txt (which can be found from

5 - Attacker Behaviour

   5.1. A forged-source reflective amplifying attacker who wants to be
   successful will either have to select authority servers who do not
   practice rate limiting yet, or will have to select a large number of
   authority servers and use round robin to distribute the attack flows.
   Each authority server will have to be asked a question within one of
   that server's zones chosen at random in order to get an amplification
   effect. An attacker would do well to select DNSSEC-signed zones and to
   use DNSSEC signalling in their forged queries to maximize response size.
   This will be more effective than QTYPE ANY queries which are often
   blocked altogether due to their diagnostic rather than operational

...i now wonder if this section should be expanded to talk about
dictionary attack against diverse existing names within a single zone.
an NSEC walk would be a perfect example of this. i want to make sure
we've documented everything we think attackers could do to get around
rate limiting, to avoid any false feeling of safety.

comments on this approach would be welcome.


More information about the ratelimits mailing list