[ratelimits] CH/TXT/id.server queries rate-limited

[Jay Daley]

On 26/10/2012, at 3:35 PM, Vernon Schryver <vjs at rhyolite.com> wrote:

> One problem with that diagnosis is that it assumes many DNS client
> address blocks are running at 10 qps.  Why that particular rate?

I was illustrating a problem that may or may not be applicable in this case, there is insufficient data to tell for sure.  I was also quite specific that this is a problem that occurs only when the qps is near the limited rate.

> There's no cost to a bad guy in modestly overshooting the rate
> limit.  The best tactic is send to plenty of qps to be sure to fill
> the rate limit quota, but not so many that too many of your bots
> are found and cured.
> 
> 
> Instead I think two other things are going on.
> 
> The "stop limiting" messaages should only happen when either
>  - 60 seconds after rate limiting stops

Or are you just talking about the limiting behaviour and not the generation of log messages:

Either you are rate limiting at X qps in which case it should stop in the first second where the traffic is < X or you are actually describing the use of multiple buckets as I described previously.  To put it simply, if you stop limiting 60 seconds later then you are actually talking about X qpm not X qps.


>  - or there is a shortage of rate-limit database entries and fairly recent
>      entries must be recycled.
> Recycling prefers all entries older than 1 second that do not need
> need a "stop limiting" message when they are recycled.  So unless
> there's a bug, I think the DNS server is seeing significantly more
> distinct IP address blocks per second than the 40000 supported by the
> "max-table-size 40000;" clause.
> 
> In other words, even if fence-posting is happening, it should not
> be visible in the log messages.
> 
> Second, more or less legitimate DNS clients stutter naturally when
> rate limited.  When they are rate limited, they pause and generally
> try to slow down until they are not rate limited.  Then they speed
> up and hit the limit again.  You can see this in `repeat XXX dig ....`.
> 
> 
> 
> } From: Jay Daley <jay at nzrs.net.nz>
> 
> } When I've previously implemented rate limiting systems I've found
> } that miscreants get to learn the limits and adjust accordingly. 
> 
> Yes, that is a necessary basic assumption that is too often ignored
> in favor of neat ideas.
> 
> } For example, if I wished to launch a reflection attack then I would not
> } be bothered by a server running a rate limit of 10qps, I would just
> } find 1000 such servers and use all of them at once.  With the current
> } RRL implementation I could happily run this attack for hours or even
> } days.
> 
> On the contrary, whether you use 1 or 1,000,000 sources for your DNS
> amplified reflection DoS attack, all of your packets will have the
> same forged IP source addresses in the address block of your intended
> victim and so will use a single bucket in the BIND9 RRL patch.

I wasn't talking about sources, I was talking about servers - multiple servers from different operators being harnessed simultaneously.

Jay

> 
> Please remember that the BIND9 RRL patch is not intended to defend
> against a DoS attack on a DNS server, although it might in some cases.
> Instead, the BIND9 RRL patch is intended to keep a DNS server from
> being used to attack a third party in a DNS amplified reflection attack.
> 
> Both "amplified" and "reflection" are important aspects of the design
> goal.  Unless you set "slip 0;" the BIND9 RRL patch will reflect or
> send about 50% as many bits to the victim as the bad guy sends to the
> DNS server.  With the default "slip 2;", the patch reduces the "gain"
> of a DNS server in an amplified reflection attack to much less than
> 1.0 and so makes a DNS server uninteresting to bad guys.
> 
> It is easy to imagine scenarios in which a reflection attack with
> a gain of less than 1.0 might be useful, but there other protocols
> with higher gains DNS with the BIND9 RRL patch.  For example,
> consider TCP/IPv6 SYN to port 80.
> 
> 
> } Another benefit of a more general approach like this is that everybody
> } does it differently, which makes it far harder for miscreants to
> } predict cumulative behaviour and use cumulative behaviour to their
> } advantage.
> 
> It's vital to address the problem at hand, amplified reflection DoS,
> instead of other problems, such DoS against DNS servers.
> 
> Second, code diversity is good, but people running big (i.e. multi-box)
> DNS servers have made their strong preference clear.  There must be a
> useful intersection of the parameters and features of all amplified
> reflection DoS rate limiting implementations at a site.
> 
> 
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley