PSA - Using Spamhaus Blocklists with Cloudflare Public Resolver May Cause Issues

Posting this here to hopefully save someone else a bunch of troubleshooting and headache.
TLDR; if you are using Spamhaus DNS blocklists (DNSBL) and use Cloudflare’s public resolver, you are more than likely either not getting the protection you need or are seeing a bunch of bouncbacks from outside orgs trying to send you email.

I recently inherited administration of our email servers and we started seeing a bunch of tickets come in for our users not receiving email from outside orgs. Turns out our servers were using a couple of Spamhaus DNSBL’s (specifically cbl.abuseat[.]org & zen.spamhaus[.]org) for spam protection. Starting on February 25th, instead of getting the typical “NXDOMAIN” DNS response you would expect to see for most legit queries to a dnsbl, we started getting a ton of “NO ERROR” responses with a return code of redacted. Spamhaus had in their docs that this return code meant we were using their service through a public resolver (which was true). I found it odd that this just started since we never had this problem before while using the Cloudflare public resolver for DNS. At the end of the day we figured out and corrected the issue, but didn’t know the reason for why it started. I eventually stumbled on the blog post linked below that would have made my life so much easier had I seen it early on in the troubleshooting process. Hopefully posting this here will help someone else avoid the same problem or find the issue much quicker.

I am not aware, but may I ask if this is related to a Cloudflare customers which have got misconfigured e-mail related DNS records or something else?

Meaning they have got an e-mail hostname like A mail for their domain somehow misconfigured and proxied :orange:, despite the known articles how e-mail related DNS records should be configured (unproxied :grey:)? :thinking:

If so, then I am afraid that’s the customers/users issue if their domain somehow got on the “blacklist” due to it as far as e-mail related hostname was proxied :orange: that way didn’t returned a FcrDNS / PTR, as far as Cloudflare “by default” doesn’t proxy the e-mail traffic (proxy :orange: works for HTTP/HTTPS web traffic).

Nevertheless, I am using Postfix with Amavis + SpamAssassin and have multiple of RBLs added, even the mentioned one zen.spamhaus.org / dbl.spamhaus.org on smtpd_recipient_restrictions.

I haven’t experienced any issues so far for now while using 1.1.1.1/1.0.0.1 added to my “resolv.conf” on the Linux OS servers.

Isn’t the origin host/server IP (with configured PTR) in the request while querying? :thinking:

May I ask in which logs did you get them?
I cannot grep any of the stated error so far in my logs - might be I am looking into wrong ones? :thinking:

Could be I wrongly misunderstood the referenced article in your post.

This is not related to an IP actually being on a Spamhaus blacklist. This related to anyone using the Spamhaus blocklist public mirrors to check IP reputation (i.e. checking incoming connections to your email server to see if they are on the Spamhaus blocklist). I believe the Spamhaus blocklists were free at one point but are now a paid service for commercial use. This change appears to be an effort for Spamhaus to stop non-paying companies from using their blocklist service…which is understandable. Their reasoning is that when a lookup to the Spamhaus block list is performed and queried by a public DNS resolver (such as Cloudflare), they cannot attribute the number of queries a specific IP is making to enforce their free tier limit. Per the linked blog post from Spamhaus, in mid February they started rolling out this change.

Typically when you check a clean IP against the Spamhaus DNSBL, you should expect to get an “NXDOMAIN” response. However, with this change, anyone using Cloudflare for a public DNS resolver who tries to check an IP against any Spamhaus blocklist public mirrors (i.e. zen.spamhaus[.]org) will now get a DNS query answer of 127.255.255.254 instead of NXDOMAIN. According to the Spamhaus docs, this is due to the query coming from an open/public DNS resolver. See this FAQ from Spamhaus.

The way to correct this is to sign up for the Spamhaus Data Query Service (DQS). It’s spelled out in the blog post, but Spamhaus does still have a free tier for certain use cases. At any rate, you have to sign up for an account. When you do, they will provide you with a unique key that you append to your blocklist query. This will allow you to continue to use the public Cloudflare DNS resolver, while still allowing Spamhaus to attribute the DNS lookups to your specific account.

1 Like

Aha, that so.

I will note that this seems to be intermittent right now. We were seeing a mix of nxdomain and the answer of 127.255.255.254. Email delivery for us was very hit or miss and it took a bit to track down the actual cause. That said, according to the blog post from Spamhaus, they began “slowly” rolling this out on February 15, 2022 with no definitive end date. Given what we saw, I would suspect it is not fully rolled out yet so it may not impact you at all or intermittently at this point.

Screenshot from the blog post…

This is also pretty easy to test with dig or nslookup. The Spamhaus FAQ tells you how to test here - The Spamhaus Project - Frequently Asked Questions (FAQ)

1 Like

Thanks! :+1:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.