> > The situation is that dnswl has four possible responses when it acts on a > query that it has flagged as exceeding the limits of unpaid use: 1) reject > with SERVFAIL, 2) reject with BLOCKED, 3) return 127.0.0.255 which is code > for blocked, 4) return 127.0.10.3 which is code for "other service" HI > non-spam
127.0.0.255 is what is used in most cases (and was the only response we initially implemented). We had the following cases where this did not result in the number of queries being reduced (and please note that the source is not only SA): * Large scale open resolvers. Additionally they keep adding/changing the IPs which they use to talk to auth NS, and on top they often lack rDNS, making it difficult to identify. Some of the clueless admins fall into this category. * Large hoster resolvers (namely AWS, OVH, Hetzner, …): Sometimes we observe massive amounts of „enumerating queries“, clearly some outfit scanning large IP ranges over DNS. Likely not SA doing this, but some standard SA installations are likely „mixed in“. * A number of security companies (likely) where the pattern indicates that they are „freeriding“ as part of the service to their customers (some well known names…). Some have changed and are hiding behind AWS nowadays (see first bullet point). Now if one gets blocked results (.255) from a blocklist, the effect is usually visible right away. With a welcomelist, the effect may be more subtle (more false positives, but you may not immediately know why). Getting persistent overusers to act thus needs a different response: * Do not give them NS response for the list.dnswl.org response. * Return a SERVFAIL on the list.dnswl.org zone. * Return a _HI response. Neither of those is ideal, neither of them works in all situations, but doing nothing is also not an option in terms of resource usage. > That policy clashes with the SpamAssassin PMC's explicit policy of not > supporting in our default configuration any dnsbl that responds to violation > of a "free for some" model by returning wrong information instead of a > specified BLOCKED code. If we allow that, it The implemented actions are intended to keep up a „free for most“ model. > Under some of those circumstances, the complaints go to SpamAssassin and the > pressure is put on us. I‘m aware of it and have responded a number of times on the SA users list („use a local resolver which you should anyway and you‘re find unless you really go way above 100k queries per day“). > process after the first 127.0.0.255 is received you would feel better about > relying on that. Or maybe you can think of another compromise suggestion. I‘m very open to suggestions for a better process / better actions with fewer collateral damage. I can suggest that we run a statistical experiment by turning all non-.255 responses into .255 responses and then compare the rate of queries. I‘m currently on business travel (and typing this mail on my phone 😅) so I could implement that on the weekend, and then give it a week or two to compare query loads (and identify some of the more obnoxious commercial abusers mentioned above). — Matthias
