spamhaus DNS query blocked from inside containers

lozik

Hi there,

For a long time now, I have in my postfix logs the following messages:

warning: dnsblog_query: lookup error for DNS query 1.2.3.4.zen.spamhaus.org: Host or domain name not found. Name service error for name=1.2.3.4.zen.spamhaus.org type=A: Host not found, try again
warning: dnsblog reply timeout 10s for zen.spamhaus.org

These messages exists for both IPv4 addresses, as well as for IPv6 ones. I always thought it was normal and ignored the message but then I saw in the github repo that this is not supposed to be as it is. In fact, I cannot remember if it has ever worked.

The issue is strange. These are the tests I’ve run on the same machine:

dig 1.2.3.4.zen.spamhaus.org gives me a response, while
docker-compose exec acme-mailcow dig 1.2.3.4.zen.spamhaus.org @unbound times out.
However, docker-compose exec acme-mailcow dig google.com @unbound gives a response.

The server is based on debian (latest stable) and is running only mailcow (currently on 79f8a3c) as well as fail2ban (for the ssh access). Iptables has not been manually adapted.
git diff origin/master only yields one change in /data/conf/postfix/main.cf (myhostname) (I don’t remember why I changed that but this should not be the issue).

Is anyone having similar issues or knows what that could be?

Thanks 😀

lozik

Am I really the only one facing this issue? 🤨

Some further details about my server: the server had been freshly installed before installing mailcow. So no settings changes except maybe some ssh tweaking. It was originally installed with that major version of debian (i.e. nothing that could have gone wrong during an upgrade). And finally, every apt package is up to date (including docker and docker-compose).

I have browsed through this forum and also the gitlab issues and nobody mentioned such an issue. There were some similar issues with dns but those were general failures of dns (e.g. https://community.mailcow.email/d/511-dns-stopped-resolving-after-recent-update). I would love to check what it could be but I cannot imagine in any way how I could investigate the issue 🤔

diekuh

Using dig inside the container uses the unbound recursor shipped with mailcow and therefore the actual VPS IP to be seen by Spamhaus. When you use dig on your host you most likely use a public recursor with a local forwarder. These public recursors are either heavily rate limited or blocked by most lists.

Iirc Spamhaus blocks most if not all Hetzner IPs.

lozik

Thanks a lot for your help, André! I completely misunderstood your other statements that you gave in some of the github issues. And I didn’t think far enough…

To summarise the issue (and with that maybe help others that run into similar problems; and please, if someone reads this that knows more, feel free to correct me!):

Mailcow uses a own unbound installation that does the DNS lookup itself (by querying the root servers if it musts) dig in Mailcow will thus use that Unbound resolver which obviously has the server IP visible to the root servers and all to other queried name servers
If using dig outside the mailcow containers, the system’s DNS resolvers are used for the lookup
In standard installs, the system doesn’t have an own resolver (on localhost) but uses a resolver preset by the hosting provider, manual config or via DHCP
If a third party resolver is used, the outgoing IP address is not the one of the server, but the IP of the resolver.
Spamhaus blocks Server-IPs from hosting provider’s VPS/cloud server range, as it does for Hetzner. Seemingly, an exception are the Hetzner recursive name servers
For black-lists/spam requests, external resolvers should never be used (except if they don’t cache their requests, which is never the case). Thats why Mailcow uses an own unbound resolver: to avoid cached results that are not valid anymore. If needed, it will internally cache the results to be more efficient and not to DoS the root servers.

However, the good news is that Spamhaus provides it services free-of-charge for non-commercial use. To that end, one can request a free account and get personalised DNSBL server endpoints.

The bad news is that one cannot simply register for it to work without changing the mailcow installation. As noted in Spamhaus’ documentation:

To query the datafeed query service, your key is added to the DNSBL zone names that you will use in the same way as you would use any normal DNSBLs in your mail server. If, for example, you have been using zen.spamhaus.org, you simply delete zen.spamhaus.org and replace it with abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net.

This needs to be done once for postfix (to block messages before even being accepted) and once for rspamd (to block contents or block messages according to the contents’ domain reputation). For postfix, the change is quite easy but I nevertheless don’t like it. It is dirty and will perhaps one day trigger merge conflicts but it will not be problematic if new DNSBLs are added.

In /data/conf/postfix/main.cf, item postscreen_dnsbl_sites
Comment:

  zen.spamhaus.org=127.0.0.[10;11]*8
  zen.spamhaus.org=127.0.0.[4..7]*6
  zen.spamhaus.org=127.0.0.3*4
  zen.spamhaus.org=127.0.0.2*3

and add:

  abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.[10;11]*8
  abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.[4..7]*6
  abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.3*4
  abcdefghijklmnopqrstuvwxyz0123456789.zen.dq.spamhaus.net=127.0.0.2*3

(don’t forget to restart the unbound container)

That’s where I am right now. I have not yet tried how to include the spamhaus check into rspamd but I think it’s harder because there is no mailcow-specific config of rspamd mentioning spamhaus.
If someone fiends a cleaner way to make this happen, feel free to comment.

I will further explain my findings if I find some time to tackle the rspamd issue.