On 2021-04-12 03:11 AM, Matthias Leisi wrote:
> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> https://www.dnswl.org/,
> high trust
> [203.160.71.180 listed in list.dnswl.org [1]] I looked up this, and the other
> one, and didn't find them in dnswl. As
> others said, if you are using public DNS, stop doing that immediately.
> And, run the dnswl queries with dig or host yourself on your own machine.
Answering to this mail, I could have used any of the others.
At dnswl.org [2], we have the fair use policy of 100'000 queries per 24
hours. Those that are consistently way above this threshold (either on
an individual IP, within a block of IPs or spread over multiple blocks)
may get blocked.
„Blocked" is not straightforward in DNS - if you simply return REFUSE
status code, resolvers may retry on other nameservers, thus effectively
multiplying the (useless) traffic. To avoid this, we have a number of
strategies:
* „pass" - for those we don't want to block
* „parentblock" - we do not return the actual NS records for the
list.dnswl.org [1] zone from the parent zone; all A records in
*.list.dnswl.org [1] return 127.0.0.255 and a corresponding TXT record -
that's the default strategy for most part of those that query above the
fair use threshold.
* „refuse" - see above, rarely used
* „empty" - we return NXDOMAIN. Not currently used.
* „ignore" - we don't return anything. Not currently used.
* „returnhi" - for those that try to evade „parentblock" (eg by
directly querying list.dnswl.org [1] nameservers), or who do not take
action after long times of „parentblock" (and which also did not change
behaviour on „refuse"), we return „hi" in order to make them go away
eventually.
* We may chose to escalate from single IPs to eg v4-/24 or
v6-/48-or-larger for active evaders (eg frequently changing nameserver
IPs), and we may also use „returnhi". Interstingly, we have a surprising
high number of „returnhi" cases which have been querying us for _years_
without a change in behaviour. From time to time we change them to one
of the other strategies. It would be interesting to dig in what they are
actually thinking...
It's likely that the OP is using a nameserver where we have „returnhi".
Obviously the advice given in this threat (use a local caching resolver
who does not forward queries) is correct and will that problem magically
go away :)
-- Matthias
Ah, thank you for the explanation.
Following the advice on this list, I set up a locally running running
DNS server. Since that time, I have not seen the problem of _HI scores
in my spam emails.
Links:
------
[1] http://list.dnswl.org
[2] http://dnswl.org
