https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728
--- Comment #13 from Matthias Leisi <[email protected]> 2011-12-22 10:32:43 UTC --- I did some additional tests on how best to block abusive query sources. "Best" is defined as three goals: 1) Reduce the overall traffic on parent (dnswl.org) and data (list.dnswl.org) zone 2) Avoid or minimize collateral damage on root and gTLD servers 3) Make it easy for operators of abusive query sources to find out what is happening We have built the mechanism to redirect defined IPs to a special view of the dnswl.org zone as part of bug 6724 (using BIND views). I wanted to do actual tests to base at least the decision on the first goal on hard facts. We tested three combinations: A. Explicit nameserver in "nowhere land" | list.dnswl.org. 21600 IN NS blockedview.dnswl.org. | blockedview.dnswl.org. 21600 IN A 127.0.0.255 B. Explicit nameserver for data zone in .invalid | list.dnswl.org. 21600 IN NS _ | you.are.blocked.from.using.dnswl.org.thorugh.public.nameservers.invalid. C. No zone apex (no NS records for list.dnswl.org) In all cases, we returned 127.0.0.255 for *.list.dnswl.org in this view. Also in all cases, we return 127.0.0.255 for the nameservers of the original data zone (a through l.ns.dnswl.org), which affected clients should not actually ever have seen. Also, if an affected client would ask a through l.ns.dnswl.org they would always receive 127.0.0.255 as an answer. A. and B. showed no measurable difference in traffic levels on the parent and the data zone. With C., the traffic on the parent zone nameservers grew by about 30%; traffic on the data zone did only shrink by about half the amount that was added on the parent zone. This rules out C. as a viable option and makes the choice depend only on goals 2 and 3 above: minimize collateral damage (on root servers) and maximize identifiability for operators. It can be expected that some resolvers will ask the roots for invalid., and it can also be expected that not all resolvers will do proper negative caching for B. This leaves A. as the most efficient option with the least collateral damage (except for the timeouts on the affected DNS resolver / forwarder when trying to reach 127.0.0.255). It should be remembered that this only applies to query sources who generate excessive amounts of traffic over some period of time, and who do not react to reasonable attempts at communication. The first line of defense would be to return 127.0.0.255 (or other BLOCKED triggering value, to be defined) from the regular data zone nameservers, as discussed in this bug. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
