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.