[ratelimits] rate limiting recursive server

[Paul Vixie]

Jay Daley wrote:
> On 18/04/2013, at 2:13 PM, Vernon Schryver <vjs at rhyolite.com> wrote:
>
>> ...
>> That implies that the server isn't used by SMTP servers, HTTP clients,
>> or other applications that send bursts of identical DNS requests.
>> ...
>
> Does anyone know of any studies done or other evidence that would help understand exactly what would break (or slow down) if RRL were used on a recursive resolver?

it's a known theoretical bad thing, doesn't require study though simple
testing will show you that "slip 1" is nec'y but that the resulting
tcp/53 sessions will slow down your apps.

what's needed for rd=1 is request rate limiting like you'd do in your
firewall or IPS. i use freebsd "ipfw dummynet". an attacker can still
cause you to churn your state holdings, but even that won't make an
input-restricted rdns server useful as a reflecting amplifying ddos tool.

request rate limiting could be built into the name server, but
engineering economics suggests that this is the wrong approach. response
rate limiting MUST be in the name server or otherwise dns protocol-aware
mechanism. (cloudshield told me they could do it in their line rate
front end IPS box, but that box is dns-aware, so it matches my
assertion.) whereas request rate limiting CAN be done by most upstream
firewalls. engineering economics tells us that it's cheaper upstream,
since you won't be paying for the context switches on your name service
host.

if you want to, you just gotta, use RRL on an rdns, you'll need a max
request rate of 100 or so, which means you're still quite useful as an
amplifier, or you'll need "slip 1", which means you're slowing down
every dns-requiring application within your sphere of influence, and
also opening yourself to a resource exhaustion attack.

paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130509/b5a44972/attachment.htm>