Colm MacCárthaigh wrote: > > On Fri, Feb 7, 2014 at 9:35 AM, Paul Vixie <[email protected] > <mailto:[email protected]>> wrote: > > Colm MacCárthaigh wrote: > > > > > Now if I have a botnet or client that can generate 1M PPS (this is > > > small, but adjust to any number), I can try to spoof 66,666 popular > > resolvers (this is a knowable set) at 5 QPS each to 3 auth > servers, I > > can use RRL to degrade service in a more widespread way. > > > > Now, let's say you have the capacity to answer these queries > (which is > > realistic for some) which behavior is better for your users? Just > > answering the responses? Or rate-limiting the responses? > > Rate limiting is always better, given that recursive servers will > retry, > will act on TC=1, and will stop asking once they cache the result. > > > Just to be clear; you're saying it's better, for your legitimate > users, only to answer their queries probabilistically? I agree that > they'll retry, and with 2 retries they'll even get a TC=1 87.5% of the > time. But I have to consider that some kind of degradation of service. > For the 12% who got no answer, do you consider that some kind of > degradation?
since you've asked for clarity, let me provide it as follows. for the case of an attack against the name server itself, not a reflection victim via ddos but a pool of response-starvation victims via a logic attack on RRL itself, it is theoretically worse for the response-starvation victims to have RRL deployed. i say "theoretically" because the impact would be (a) exceedingly brief, (b) exceedingly narrow, (c) not user-visible, and must be (d) exquisitely and expensively well targeted. in this one corner case, my statement "always better" is wrong. for the case of an attack against a reflection victim via name server reflected DDoS, the impact on response-starvation victims due to the RRL logic, will be no worse than the impact of not having RRL, and if the attack is large, it will be better with RRL than without. therefore my statement "always better" should have been written "never worse" and i apologize. > ... If I use RRL, my user queries can be degraded. And that is user > visible, including to stubs, even with caching. If you cause a caching > resolver to delay or timeout lookups that does hold up and impact stubs. i any delay at all is to you "user visible" even though once cached the same delay won't reoccur within a DNS TTL interval, then so be it. DNS RRL is a DNS-specific rate limiter which relies on retries, TC=1 behaviour, and caching -- by design, mind you -- for its success. i'm not merely splitting hairs here -- in my own testing, the only way i could cause a stub lookup failure, noting that a stub tries multiple recursive servers and will retry to each, was to send enough attack traffic toward all of that stub's recursives to also cause failures on unrelated names. in that latter case, it made no difference whether RRL was off or on, because the attack was on the recursive name server's resources, not the RRL logic. so, if you know a way to reliably cause targeted stub query failures using an attack that only works with RRL turned on, i'd like to see your demonstration. vixie
_______________________________________________ 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
