[ratelimits] rate limiting recursive server
Patrick W. Gilmore
patrick at ianai.net
Thu Apr 18 10:34:22 UTC 2013
On Apr 17, 2013, at 22:13 , Vernon Schryver <vjs at rhyolite.com> wrote:
>> From: "Patrick W. Gilmore" <patrick at ianai.net>
>> 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.
> That's a common situation, and perhaps even more commonly claimed.
>> The total legitimate query load on this server is << 1 qps.
> That implies that the server isn't used by SMTP servers, HTTP clients,
> or other applications that send bursts of identical DNS requests.
It is only (supposed to be) used by users during diagnostics. I.e. "I can't get to $AKAMAIZED_SITE", "Please click on $URL <that does a lookup against NS among other things>".
As a result, load is low by most standards, but has to be wide open since users anywhere can have issues.
> It might be nice if the Open DNS Resolver Project could distinguish
> open resolvers that are useful for current reflection attacks
> from those that are rate limited. On the other hand, that might
> be too useful to the bad guys.
Is Jared on this list?
>> 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 recommend RRL limits of 5 or 10 for all except exceptionally big
> and busy authoritative DNS servers.
>> (I realize that still makes us an amplifier, but I'm willing
>> to be no one cares about a few hundred Kbps.)
> As implied by RRL limits of 5 or 10, I agree,
> with a caveat regardless of the rate limiting flavor.
>> 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.
> The BIND RRL code includes an "all-per-second" parameter for simplistic
> rate limiting per CIDR block. I added it to answer popular demand,
> but I do not recommend it when there is an alternative. Simple rate
> limiting is best done outside the DNS server and so without wasting
> its CPU cycles, bandwidth, disk space (logs), etc.
Yeah, this one has lots of all the above. But it is probably easier for me to do it in the FW as opposed to have the NS guys add a patch to BIND.
Thanx for the help.
More information about the ratelimits