> From: =?ISO-8859-1?Q?Jaroslav_Benkovsk=FD?= <[email protected]>
> 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. How do you do that without too many false positives? How do you not drop responses when there is no attack because a lot of responses get the same bucket? And how do you not drop all of the legitimate responses to non-forged requests from a victim under attack? Notice that at the limit of that idea, you have one bucket per client IP address, and so have converted RRL to client IP rate limiting. You must assume that the bad guys will know how you group your buckets, and so can force you to use a single bucket per client IP address if they want. They can do that even if you use a secret or even varying grouping algorithm by randomingly varying qnames and qtypes while monitoring your reactions. The big advantage of RRL compared to rate limiting by client IP address is that DNS is not turned off for the victim. Between SLIP and rate limiting (qname,qtype,IP), the victim generally still gets name resolution. The purpose of a flood of forged DNS requests might not be to clog the victim's pipes, but to deny name resolution. Many attacks in past decades have had "Disable name resolution" as a first step, and with new uses of DNSSEC (e.g. DANE) that first step seems likely to be more common. On the other hand, if you prefer client IP address rate limiting, then the current BIND9 RRL patch includes an all-per-second parameter. You might set responses-per-second to 5 or 10 and all-per-second to 30 or 50. For more information, follow the link on http://www.redbarn.org/dns/ratelimits to the "Draft text for BIND9 Administrators Reference Manual (ARM)" 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
