[ratelimits] rate limiting recursive server

Patrick W. Gilmore patrick at ianai.net
Thu Apr 18 01:16:14 UTC 2013

On Apr 17, 2013, at 08:34 , Vernon Schryver <vjs at rhyolite.com> wrote:

>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>>> Or even use network infrastructure QoS to rate-limit traffic to it, =
>> since it isn't a production device and therefore there're no worries =
>> about programmatically-generated attack traffic 'squeezing out' =
>> legitimate traffic.
>> Ooh, I think we have a winner!
> How does that work, when the traffic squeezing intended by the bad
> guys is not in your network infrastructure?  How does using QoS to
> ensure that none of the legitimate traffic in your networks are squeezed
> by requests to or responses from a test open recursive server mitigate
> a DNS reflection attack in the intended victim's network?
> Is the idea to impose a tiny packet or bit/sec limit on all requests
> and/or responses for the test DNS?  If so, why doesn't that have
> the same problems but more so as the numerically same RRL limit?

I think there is a bit of confusion here.

Akamai has an open resolver - as in anyone on the internet can query it with recursion set and it will answer. This is the intended and, unfortunately, required functionality.

The total legitimate query load on this server is << 1 qps. To keep us from being an amplifier, I was thinking about rate limiting it to the massively "over-provisioned" rate or 3 or maybe 5 qps. (I realize that still makes us an amplifier, but I'm willing to be no one cares about a few hundred Kbps.)

The question was whether BIND had a switch or patch to do that. Apparently there is not one other than RRL, which may work. But Roland's idea was to simply rate limit at the FW in front of the NS. Easier to implement, and has the exact same effect of what I originally wanted.

RRL may be more nuanced in its limiting. But for this particular application, it doesn't matter. If an attack happens, we would rather deal with a down server than being the source of amplification.


More information about the ratelimits mailing list