[ratelimits] No response repeated queries

[Vernon Schryver]

> From: Pete Ashdown <pashdown at xmission.com>

> First thanks for this patch.  I'm running it on our public recursors and it is
> working much better than the bailing-wire/sticky-tape/fail2ban I had before.

I hope those public recursors use firewalls, views, ACLs, etc. to only
answer requests from your customers.  DNS amplified reflection DoS
attacks are a major problem in large part because people are running
open resolvers without no rate limiting.  (Yes, authoritative servers
would still have problems, but few of them answer forged requests for
those party favorites.)

> Although I understand the usefulness of slip for targets that are pulling DNS
> from a server, it would be nice if there was an option to not let the repeated
> query slip at all.  I have slip at 10, responses-per-second at 20 and
> qps-scale at 250, and I'm still letting out 50-80 slip requests a second for
> party favorites like isc.org and ripe.net to targets under attack.  I'd rather
> they were just silent on repeated queries for the duration of window.

"slip 0;" turns off substituting truncated responses instead of
dropping responses.

Do you mean "letting out 50-80 slip responses" instead of "requests"?
Unless there is something odd about caching, a recursive server should
not be sending 50-80 requests/second for any (qname,qtype).

With slip at 10, then 50-80 truncated responses/second are inconsequential.
They are less than 8 KByte/sec or about an old fashioned voice channel.
Meanwhile the bad guys are sending you 499-799 requests/second or about
80KByte/sec.  One can hope that they'll eventually understand that
they're spinning their wheels and try some other open resolver.

With slip at the default of 2, the bad guys would be spending 2 bytes
of their bandwidth to reflect 1 byte to the victim.
But with the default of 2, if the victim really needs one of those
party favorites, at least 1 of the victim's 4 or 5 tries is likely to
be answered with a slipped or truncated response and so the victim will
retry with TCP and so get the data.

This is related to a major difference between the RRL patch and the
commonly advocated firewall rules.  With those firewall rules,
a victim gets no responses for any requests for many minutes.  With
the RRL patch, the victim gets full responses for requests that differ
from the forged stream and lossy or truncated responses that are the
same (modulo NXDOMAIN, apex for referrals, etc.) as for the forged
stream.  You can see this with something like
    repeat 100 dig Host @Server
With the default RRL parameters at Server, you'll get all 100 responses
with some hiccups.  With a firewall scheme, you'll get one burst of
responses and then no joy at all for minutes, not even for unrelated
requests.


> Also, do I have my qps-scale set right?  The documentation doesn't make it
> clear to me if queries exceed 250, how does slip and the other counters get
> reduced/increased?

I hope the current version of the documentation is less unclear.  The
previous version was missing the phrase "ratio of the".

With "qps-scale 250; responses-per-second 20;" and a total query rate of
1000 qps for all queries from all DNS clients including via TCP,
then the effective responses-per-second rate changes to (250/1000)*20 or 5.


Vernon Schryver    vjs at rhyolite.com