On Thu, Jan 10, 2013 at 12:07 PM, Jim Reid <[email protected]> wrote: > On 10 Jan 2013, at 17:39, Matthew Ghali <[email protected]> wrote: > > > So if I understand correctly, the solution you are advocating is to only > answer non-spoofed queries? > > 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).
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]. 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. 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. 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. Casey [1] documentation from the patch itself: Rate limiting prevents the use of BIND 9 to flood a network with responses to requests with forged source addresses, but could let a third party block responses to legitimate requests. There is a mechanism that can answer some legitimate requests from a client whose address is being forged in a flood. Setting slip to 2 (its default) causes every other UDP request to be answered with a small response claiming that the response would have been truncated. The small size and relative infrequency of the response make it unattractive for abuse. Slip must be between 0 and 10. A value of 0 does not "slip" or sends no rate limiting truncated responses. Some error responses includinge REFUSED and SERVFAIL cannot be replaced with truncated responses and are instead leaked at the slip rate.
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
