[ratelimits] rate limiting recursive server

[Vernon Schryver]

> 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 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.


> 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.


Vernon Schryver    vjs at rhyolite.com