> From: Eric Osterweil <[email protected]> > > That computation might be correct if DNS clients did not retransmit, > > if the BIND RRL idea involved only discarding responses, > > and if Paul and I proposed dropping 99% of all traffic for a CIDR block. > > We advocate none of that. > > Hmm.. I may still be missing some nuances, what are the specifics?
Instead of my writing a new complete description or even worse for other readers, copying-and-pasting the existing documentation, please see the recently mentioned http://www.redbarn.org/dns/ratelimits That page has a link to a technical note talking about the problem, a link to code for serious specifics, and even a link to draft changes to the BIND9 ARM. > So, I don't understand something... If you see a lot of identical > responses from an authority, could that not be because it is an authority > for those responses? How do you distinguish a netblock with multiple > resolvers, or anycast resolvers? The BIND RRL code is part of the resolver. It does not "see a lot of identical responses from an authority" except when it is the authority. > Perhaps more directly, are you > dropping responses from legitimate clients and how do you feel about > them being collateral damage? Paul Vixie and I are not advocating DNS rate limiting in firewalls. We're talking about rate limiting in the hosts at the ends of the intertubes. > So, every identical response either gets dropped or gets its TC bit set? No, every *excessive* identical response is either not sent (dropped) or a tiny TC=1 response is sent instead. > > A DNS client that retransmits N times to a DNS server that answers > > 50% with TC=1 of the time will get an answer to 1-(0.5)^N of its > > queries. For N=4, it will get a TC=1 answer 94% of the time. > > Wait, I'm very confused... The above sounds like you respond to > 94% of the reflector attack queries (which furthers the attack). No, I was pointing out that P(R1&R2&R3&R4)=P(R1)*P(R2)*P(R3)*P(R4) Given a uniform drop probability of 50%, the probability that all 4 responses to an initial request and its 3 retransmissions will dropped is 6%. (Or should that be N=5?--I always seem to be off by 1. In which case 97% of requests would be answered.) > Well, if doing something hurts the legitimate clients more than doing > nothing, I think you need to be upfront about that. I think that's > worse than doing nothing. That's like opposing mechanical spam filtering by pointing to mechanical false positives while ignoring the higher false positive rate of the otherwise inevitable purely manual filtering on subjects and senders. If you do nothing, then legitimate clients will be denied all service by the firewall rules advocated here or by IP bandwidth rate limits at the source (DNS servers) and the DoS targets. Remember why it's called a DoS. You are saying that you would rather try to receive 1000 1500 Byte bogus DNS responses per second along with all your legitimate DNS responses that don't get dropped from router queues by that flood instead of 10 bogus responses and useful responses to 94% of your requests. > OK, but you've also almost certainly eliminated the legitimate > client's ability to query you for responses. That is simply false. When Paul Vixie wrote that the BIND RRL code is effective, he wasn't talking about theory or small scale tests. It has been in use on some major DNS servers for months. If there were enough collateral damage to talk about, someone would have complained. Vernon Schryver [email protected] _______________________________________________ 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
