> From: Jared Mauch <ja...@puck.nether.net> > Because of the FP ratio presented at the DNS-OARC meeting this > past week. It's suitable on a recursive resolver, where RRL is most effective > on an authority. > > See > > https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0 > > Page #12
I wonder to which RRL implemetation those numbers apply? Please recall that those slides appeaer to be from NLnet Labs and that one of my concerns with the NLnet Labs RRL implementation is the possibility of significantly more false positives than what I hope are the practically none from the BIND9 RRL code. I also wonder about the definition of "false positive." There are many plausible candidates. > This effectively does slip=1 and does away with any amplification and just > makes it > a pure reflection attack. Still not ideal, but doesn't amplify. On the contrary, as I just now wrote in the ratelimits mailing list http://lists.redbarn.org/mailman/listinfo/ratelimits your patch does not affect amplification by authorities. For example, if applied to an authority for isc.org, `dig +dnssec isc.org any @ams.sns-pb.isc.org' would still reflect almost 4 KBytes for each 60 byte ANY request. Vernon Schryver v...@rhyolite.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
