SpamHaus "blocked" answers

[lapo-luchini]

SpamHaus recently started responding in the 127.255.255.0/24 net for blocked queries (also, it's saying my DNS is a public one and I'm using a local resolver, so I guess their checks are flaky) so it would be better to ignore that kind of values as "no answer" instead of "it is spam" to avoid false positives.

I have a lot fo false positives from abuseat/spamhaus domains since 2025-05-13 17:51:00.

[till]

Can you comment how you setup your local resolver? The helm chart contains an unbound sidecar as an example which seems to work. How's your setup different?

[lapo-luchini]

I use a local unbound (without forward: configured) and it does work (I checked using dnsleaktest and requests are solved by my local DNS) but for some reason SpamHaus still has decided that I'm using an open DNS.

Oh, I notice that after 6 days they are now responding correctly to my queries again. Still, I think the exporter should "filter out" those kind of responses which are documented as being refusal for answers (and not negative answers) to avoid having false positive alerts.

e.g. I'm using the following alerting rule:

  - alert: MX in RBL
    expr: sum(luzilla_rbls_ips_blacklisted) by (hostname) > 0
    annotations:
      title: 'MX flagged in RBL: {{ $labels.hostname }}'
      description: 'Il server di posta "{{ $labels.hostname }}" è stato segnalato in liste anti-spam.'
    labels:
      severity: warning

[till]

Do you happen to have examples for the responses so we can write a test later. I am a bit stretched on time, so I appreciate your input.

[lapo-luchini]

Unfortunately it's not happening anymore.
As soon as it happens again I will take care of saving some response and/or try a PR myself, thanks!

[lapo-luchini]

I managed to reproduce the problem using an "actual" DNS problem (the DNS of my provider):

% drill a 99.2.9.176.sbl.spamhaus.org @185.12.64.1
;; ANSWER SECTION:
99.2.9.176.sbl.spamhaus.org.    2100    IN      A       127.255.255.254
% drill txt 99.2.9.176.sbl.spamhaus.org @185.12.64.1
;; ANSWER SECTION:
99.2.9.176.sbl.spamhaus.org.    2100    IN      TXT     "Error: open resolver; https://check.spamhaus.org/returnc/pub/2a01:4f8:0:a231::add:2d/"

I also saved a tcpdump of the packets, if it could be useful, I'm willing to send it my email (I'm not sure I want to attach the file here publicly).

[till]

@lapo-luchini I am torn on this.

So to summarize: you expect the exporter to yield a different response when people use an open resolver? Or do you want to ignore it completely?

I think, I am a firm 👎🏼 on ignoring it, as it masks a mis-configuration.

Potentially, we could respond with 2 instead of 1?

• 0: unlisted
• 1: listed
• 2: this error

But now we need to start parsing responses for different RBLs?

[dragoangel]

This what I was speaking about different responses for different rbls handling in #225 (comment) - maybe we better rename this FR and think not about spamhaus but about general cases when users want to have special handling for different answers?

Another thing that could be cool in dnsbl_exporter.conf:

rbl_configuration:
<rbl_domain_name>:
ignored:
- response: 127.0.0.7
description: "whitelisted"
- response_range: 127.0.0.100-127.0.0.115
blocked:
- response: 127.0.0.1
- response_range: 127.0.0.120-127.0.0.135
rate_limited:
- response: 127.0.0.8
- response_range: 127.0.0.200-127.0.0.215
This would allow to exclude false positive of luzilla_rbls_ips_blacklisted and will allow really rely on this metric for alerting globally, as now I can't say it's possible due to some rbls could reply 127.0.0.1 for rate_limited, f.e.: multi.uribl.com, and some rbls - for example score.senderscore.com provides "dynamic score from 0 to 100, have ability to set ranges would allow people to set threshold for what expect to be bad or not. Now to achieve same approach need to write own alerts per rbl with promql, not bad thing to do as well, but less user friendly, as such rbl_responses configuration could be contributed to the default yaml conf and work for everyone out of the box.

rate_limited stuff also would allow take some actions to administrators 😊, like reduce interval of probes or use another resolver...

if rbl is configured with at least one known response, and response returned that is not in ignored, blocked or rate_limited it treated as unknown and have dedicated metric which can be alerted with severity=info to notify adminstrator that they missed to configure something or their rbl added new response code which they not aware about.

optionally we can have description for any of status that would be added as a label to rbl with such response.

[dragoangel]

we can hardcode that blacklisted is used for firing luzilla_rbls_ips_blacklisted but every other reply from range just exported as extra label. One thing to check on startup - that for 1 <rbl_domain_name> we do not have overlapping responses\ranges between different responses and fail if this happen due to misconfiguration. Example of missconfiguration:

rbl_configuration:
  <rbl_domain_name>:
    blacklisted:
      - response: 127.0.0.2
    ignored:
      - response: 127.0.0.7
        description: "whitelisted"
      - response_range: 127.0.0.100-127.0.0.115
        description: "unexpected"
    blocked:
      - response: 127.255.255.254
        description: "blocked due to open resolver"
      - response_range: 127.0.0.120-127.0.0.135
    rate_limited:
      - response: 127.0.0.8
      - response_range: 127.255.255.0-127.255.255.254 # << collision with blocked open resolver

[till]

It sounds super complicated to maintain all these specifics?

[dragoangel]

From my view I can say this is the only way to get rid off from FP and have detailed view, f.e. if you would query domain from uribl they can reply with "grey", "red", "black" or "white" or "ratelimited" and in current scheme it would be unclear what is what.

I would like to hear other options, because when I see way I can skip (in thoughts) other ways around 😅.

Grey, red & black can be put under blacklisted with each - own description which will land under rbl_description label (or anyhow you want to name it), while white & rate limited to dedicated sections and as result will not get into luzilla_rbls_ips_blacklisted but be added to dedicated luzilla_rbls_ips_listed metric with appropriate label. By default when rbl not provided with own conf - default (current) behavior will be applied. Also this not something personalized, this is general rules for everyone who would query rbl which has extended configuration - but again if somebody will have some "closed|not public" rbls they can tune them via conf as much as they want.

P.s. by hardcode - I mean in conf file - which shipped in default setup and can be modified (adjusted/extended)**

[lapo-luchini]

I think, I am a firm 👎🏼 on ignoring it, as it masks a mis-configuration.

You're right, returning a different value is probably best.
Maybe -1 instead of 2?
But I have not much preference there, as long as I can create a alerting rule on it.

Also, I'm not sure to to configure correctly, as I'm actually already am using local resolver instead of a common resolver, and I still get that value… but that's on SpamHaus and not on your nice exporter, of course.

[till]

@lapo-luchini could you use my ubound or share the unbound config you are using? I would still like to reproduce it. Not ruling out that I am missing something or haven't provided enough docs.