On Thu, Jan 10, 2013 at 12:07 PM, Jim Reid <span dir="ltr"><<a href="mailto:jim@rfc1035.com" target="_blank">jim@rfc1035.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On 10 Jan 2013, at 17:39, Matthew Ghali <<a href="mailto:mghali@snark.net" target="_blank">mghali@snark.net</a>> wrote:<br>
<br>
> So if I understand correctly, the solution you are advocating is to only answer non-spoofed queries?<br>
<br>
</div>It's one of them, yes. Though since it's hard for a DNS server to distinguish between spoofed and genuine source IP addresses, the RRL patch is the easiest way to get the same effect. Your server would then respond to a teeny fraction of the thousands of queries per second from the same (forged) IP address(es).</blockquote>

<div><br>I'm not familiar with other RRL behavior, but to provide some numbers for BIND's patch:  All responses to rate-limited queries are truncated, but default behavior is to withhold response altogether for only 1 out of 2 such queries (50%).  The maximum configurable behavior is to withhold 90% of such responses [1].<br>
<br>With a low response rate for rate-limited queries and a high query rate for a rate-limited query from the same "client", responses to legitimate clients with the same IP (or range) would effectively be shut out by the statistical (im)probability of being "selected".  I understand that "teeny fraction" is a relative term, but in order to effectively meet the objectives of 1) amplification mitigation and 2) not denying legitimate clients service, the response rate must be reasonable.  A reasonable value depends on the query rate.  The statisticians might provide a good rule of thumb for reasonable response rate given query rates, but it seems like 50% is in fact a good starting place.<br>
<br>The BIND RRL patch also has an option for scaling down the "slip" value (which dictates response rate) in the presence of increased query rates.  I haven't had time to play with it, but the idea is smart.<br>
<br>kudos to Paul and Vernon on the BIND RRL patch (and others working on similar functionality). It's been a useful tool for mitigating some of the behaviors that have been observed in recent months.<br>
<br>Casey<br><br>[1] documentation from the patch itself:<br><br>Rate limiting prevents the use of BIND 9 to flood a network<br>with responses to requests with forged source addresses,<br>but could let a third party block responses to legitimate requests.<br>

There is a mechanism that can answer some legitimate<br>requests from a client whose address is being forged in a flood.<br>Setting slip to 2 (its default) causes every<br>other UDP request to be answered with a small response<br>

claiming that the response would have been truncated.<br>The small size and relative infrequency of the response make<br>it unattractive for abuse.<br>Slip must be between 0 and 10.<br>A value of 0 does not "slip"<br>

or sends no rate limiting truncated responses.<br>Some error responses includinge REFUSED and SERVFAIL<br>cannot be replaced with truncated responses and are instead<br>leaked at the slip rate.<br></div></div>