|Main Archive Page > Month Archives > spamassassin-dev archives|
--- Comment #13 from Matthias Leisi <firstname.lastname@example.org> 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)
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
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
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 _
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
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
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.