<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF">...<br>
<br>
Jaroslav Benkovský wrote:
<blockquote cite="mid:51274684.6080005@nic.cz" type="cite">
  <pre wrap="">On 02/20/2013 08:48 AM, Jan-Piet Mens wrote:
</pre>
  <blockquote type="cite"><pre wrap="">FYI, a paper (Feb 2013) titled "Defending against DNS reflection
amplification attacks" at [1].
</pre></blockquote>
  <pre wrap=""><!---->
Interesting. Since the problem with RRL at low NXDomain ratio is the
number of buckets, i.e. names queried, perhaps it would be possible to
limit the number of buckets by grouping names together for the purpose
of assigning the bucket?

E.g. a name server could adaptively assign names to a limited number of
groups so that each group gets roughly the same amount of qps (or total
sum of RRL score of the constituent domains) and then use the group id
instead of a name as a bucket key.

Or if this added complexity is too high, perhaps just (semi) random
assignment of group id to a name on zone reload would be sufficient.</pre>
</blockquote>
<pre wrap="">
</pre>
since this whole line of reasoning (which belongs on the ratelimits@ 
mailing list, not this one, by the way) is based on the idea that RRL 
can be gamed, and since the above proposal and all variants of it can 
also be gamed, i think we're in the weeds.<br>
<br>
the perfect unstoppable reflecting amplifying ddos would first enumerate
 all authority servers on the internet, and reflect 3 QPS off of each, 
using a single fixed qname per server. nothing we do inside a server nor
 in its data path to the internet core (as in, using front end load 
limiters) will fix that.<br>
<br>
we could develop a clearinghouse and maintain state centrally, at the 
peril of "end to end system design", but this would not be fruitful 
unless almost all authority servers (then and in the future) subscribed 
to it.<br>
<br>
at which point it's easier to fix source address validation and make 
THAT universal. which we already know can't be done.<br>
<br>
let's remain realistic.<br>
<br>
paul<br>
</body></html>