I try to deploy mailcow on my home server and I have some error with the UNBOUND container. I previosly bypassed it to correct others problème, using SWAG reverse proxy and setting SMTP2GO. But now I need to correct it. When it start, the container stuck with this loop of message in logs: 2026-01-07 09:00:08: Healthcheck: DNS Resolution Failed on attempt 1 for fuzzy.mailcow.email! Trying again... 2026-01-07 09:00:08: Healthcheck: DNS Resolution Failed on attempt 2 for fuzzy.mailcow.email! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 3 for fuzzy.mailcow.email! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution not possible after 3 attempts for fuzzy.mailcow.email... Gave up! 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 1 for github.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 2 for github.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 3 for github.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution not possible after 3 attempts for github.com... Gave up! 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 1 for hub.docker.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 2 for hub.docker.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution Failed on attempt 3 for hub.docker.com! Trying again... 2026-01-07 09:00:09: Healthcheck: DNS Resolution not possible after 3 attempts for hub.docker.com... Gave up! 2026-01-07 09:00:09: Healthcheck: Too many DNS failures (1 failures allowed, you got 3 failures), marking Healthcheck as unhealthy... I tried to define a foward-zone like mentioned in documentation but this don't resolve the problème. I suspect SWAG create another problème but I don't know why. I also disabled IPv6. I also added UNBOUND_DNS=1.1.1.1,8.8.8.8 Because UNBOUND cannot resolve DNS, others container, like nginx cannot start.

So I decided to use a VPN. I used Gluetun container because it is maintained and supports a lot of VPN providers. I also decided to use ProtonVPN because it is possible to have a free account, perfect for my test. I created a new service named gluten on docker-compose.override.yml like that: ``` services: gluetun: image: qmcgaw/gluetun #networks: # - mailcow-network network_mode: "service:unbound-mailcow" cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun volumes: - ./gluetun:/gluetun environment: - VPN_SERVICE_PROVIDER=protonvpn - VPN_TYPE=openvpn - OPENVPN_MSSFIX=1360 - OPENVPN_FRAGMENT=1360 - OPENVPN_USER= - OPENVPN_PASSWORD= - SERVER_COUNTRIES=canada - DNS_SERVER=off - FREE_ONLY=on ``` I was planning to use network_mode in the unbound-mailcow service to map on the Gluten container but it's not possible to redefine network mode in the override file. So it's Gluetun who uses the unbound mailbox net stack. On startup, Unbound will have some health check failures until Gluetun sets the VPN. Now all DNS requests work fine, not unbound reboot because the watchdog sees too many failures. And now all mail services work fine. Thanks for support.

Currently I bypass Healthcheck because I have another problem to set smtp relay.

Now I can send email but not recevie them. I saw they were rejected because postfix cannot resolve DNS. But it use Unbound and unbound are not able to résolve DNS. Someone can help me? Thanks NOQUEUE: reject: RCPT from unknown[52.103.20.95]: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo=

Sorry with that little information about your setup we cannot help (which hoster, which firewall, which OS, IPv4 or also IPv6 etc). Check the logs of the unbound container. Check if you meet all prerequisites (DNS port 53 outgoing open for TCP **and** UDP, check with your hosting provider). Check if you can `dig` from within your unbound container. Use forum search to find other threads that explain things to try and narrow down the error.

I validate fierwall also I disabled IPv6 but I see somthing strange in logs. After disabled Healthcheck I see in logs the container or the application seems reboot with this logs: Setting console permissions... Receiving anchor key... Receiving root hints... ######################################################################## 100.0% setup in directory /etc/unbound removing artifacts Setup success. Certificates created. Enable in unbound.conf file to use 2026-01-14 14:47:05,892 INFO Set uid to user 0 succeeded 2026-01-14 14:47:05,895 INFO supervisord started with pid 1 2026-01-14 14:47:06,898 INFO spawned: 'processes' with pid 17 2026-01-14 14:47:06,901 INFO spawned: 'syslog-ng' with pid 18 2026-01-14 14:47:06,903 INFO spawned: 'unbound' with pid 19 2026-01-14 14:47:06,905 INFO spawned: 'unbound-healthcheck' with pid 20 2026-01-14 14:47:06: Healthcheck: ALL CHECKS WERE SKIPPED! Unbound is healthy! [1768420026] unbound[19:0] notice: init module 0: subnetcache [1768420026] unbound[19:0] notice: init module 1: validator [1768420026] unbound[19:0] notice: init module 2: iterator Jan 14 14:47:06 7f49191ceb3b syslog-ng[18]: syslog-ng starting up; version='4.8.1' [1768420026] unbound[19:0] info: start of service (unbound 1.22.0). 2026-01-14 14:47:07,928 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-01-14 14:47:07,928 INFO success: syslog-ng entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-01-14 14:47:07,928 INFO success: unbound entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-01-14 14:47:07,928 INFO success: unbound-healthcheck entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-01-14 14:53:33,402 WARN received SIGTERM indicating exit request 2026-01-14 14:53:33,402 INFO waiting for processes, syslog-ng, unbound, unbound-healthcheck to die 2026-01-14 14:53:34,404 WARN stopped: unbound-healthcheck (terminated by SIGTERM) [1768420414] unbound[19:0] info: service stopped (unbound 1.22.0). [1768420414] unbound[19:0] info: server stats for thread 0: 132 queries, 32 answers from cache, 100 recursions, 0 prefetch, 0 rejected by ip ratelimiting [1768420414] unbound[19:0] info: server stats for thread 0: requestlist max 20 avg 8.79 exceeded 24 jostled 0 [1768420414] unbound[19:0] info: average recursion processing time 0.000000 sec [1768420414] unbound[19:0] info: histogram of recursion processing times [1768420414] unbound[19:0] info: [25%]=2.5e-07 median[50%]=5e-07 [75%]=7.5e-07 [1768420414] unbound[19:0] info: lower(secs) upper(secs) recursions [1768420414] unbound[19:0] info: 0.000000 0.000001 76 2026-01-14 14:53:34,417 INFO stopped: unbound (exit status 0) 2026-01-14 14:53:34,417 WARN received SIGQUIT indicating exit request Jan 14 14:53:34 7f49191ceb3b syslog-ng[18]: syslog-ng shutting down; version='4.8.1' 2026-01-14 14:53:34,528 INFO stopped: syslog-ng (exit status 0) 2026-01-14 14:53:34,529 WARN stopped: processes (terminated by SIGTERM)

> @"BisonOpiniatre"#p30003 2026-01-14 14:53:33,402 WARN received SIGTERM indicating exit request You need to find out why the unbound container gets the SIGTERM signal (request to shutdown). Look at other logs, e.g. form healthcheck container and correlate what happens at that time.

@"esackbauer"#p30016 I will investigate, I will come back with what I will find. Thanks

Sorry I didn't have a lot of time this week but easily I found who reboot my container, it's the watchdog and is because Unbound cannot resolve any DNS. So All comeback to this problem. I suspect it's a problem with IPV6. Maybe the domains who try to reach dont have IPv6 address or, it's more probable, a routing problem between my host and the container network. When I will have time I will continue to investigate.

Ok I disabled IPv6 on mailcow.conf and unbound.conf. Also I removed all DBNS definition on docker-compose.override.yml and others confs (sugested by AI). I juste define default dns in daemon.json of docker config. In watchdog console I saw DNSSEC Failed log and a message about Unbound container who reach error limit. So I decided to reactivate Healthcheck on startup because is clear I have a problèm of DNS résolution. So on startup I see these errors: 2026-01-21 08:10:06: Healthcheck: DNS Resolution Failed on attempt 1 for fuzzy.mailcow.email! Trying again... 2026-01-21 08:10:08: Healthcheck: DNS Resolution Failed on attempt 2 for fuzzy.mailcow.email! Trying again... 2026-01-21 08:10:10: Healthcheck: DNS Resolution Failed on attempt 3 for fuzzy.mailcow.email! Trying again... 2026-01-21 08:10:10: Healthcheck: DNS Resolution not possible after 3 attempts for fuzzy.mailcow.email... Gave up! 2026-01-21 08:10:12: Healthcheck: DNS Resolution Failed on attempt 1 for github.com! Trying again... 2026-01-21 08:10:14: Healthcheck: DNS Resolution Failed on attempt 2 for github.com! Trying again... 2026-01-21 08:10:16: Healthcheck: DNS Resolution Failed on attempt 3 for github.com! Trying again... 2026-01-21 08:10:16: Healthcheck: DNS Resolution not possible after 3 attempts for github.com... Gave up! 2026-01-21 08:10:18: Healthcheck: DNS Resolution Failed on attempt 1 for hub.docker.com! Trying again... 2026-01-21 08:10:20: Healthcheck: DNS Resolution Failed on attempt 2 for hub.docker.com! Trying again... 2026-01-21 08:10:22: Healthcheck: DNS Resolution Failed on attempt 3 for hub.docker.com! Trying again... 2026-01-21 08:10:22: Healthcheck: DNS Resolution not possible after 3 attempts for hub.docker.com... Gave up! 2026-01-21 08:10:22: Healthcheck: Too many DNS failures (1 failures allowed, you got 3 failures), marking Healthcheck as unhealthy... So like sugested by esackbauer, I use dig to resolve DNS for these three domains. dig fuzzy.mailcow.email ; DiG 9.18.34 fuzzy.mailcow.email ;; global options: +cmd ;; Got answer: ;; ->>HEADERHEADERHEADER

Unbound resolves DNS recursively beginning with the root hints. If you just use dig it will query a DNS server directly, you have to use dig +trace to simulate this behavior. So try `dig +trace fuzzy.mailcow.email` from inside the container and have a look

UNBOUND_MAILCOW Healthcheck problème

BisonOpiniatre

DocFraggle
dig +trace fuzzy.mailcow.email

; <<>> DiG 9.18.34 <<>> +trace fuzzy.mailcow.email
;; global options: +cmd
;; Received 17 bytes from 127.0.0.11#53(127.0.0.11) in 4000 ms

I dont know if is good.

DocFraggle

BisonOpiniatre That’s all? No, that’s not good, it should look like this:

ca73da79caec:/# dig +trace fuzzymail.mailcow.com

; <<>> DiG 9.18.34 <<>> +trace fuzzymail.mailcow.com
;; global options: +cmd
.                       86076   IN      NS      e.root-servers.net.
.                       86076   IN      NS      g.root-servers.net.
.                       86076   IN      NS      h.root-servers.net.
.                       86076   IN      NS      b.root-servers.net.
.                       86076   IN      NS      i.root-servers.net.
.                       86076   IN      NS      k.root-servers.net.
.                       86076   IN      NS      c.root-servers.net.
.                       86076   IN      NS      j.root-servers.net.
.                       86076   IN      NS      f.root-servers.net.
.                       86076   IN      NS      m.root-servers.net.
.                       86076   IN      NS      l.root-servers.net.
.                       86076   IN      NS      d.root-servers.net.
.                       86076   IN      NS      a.root-servers.net.
.                       86076   IN      RRSIG   NS 8 0 518400 20260203050000 20260121040000 21831 . B+Xifq7eK97OOCJVACVgSUk5UFVttgM3INFEp4pUtyY2kxU8FfVOIGk/ ajhPKUd1QkhQRdmsZmEONXEdX5cv4fQQ/x5pJawJObouKiRK3HAZgxvx zQReAd664mLCVovk3Byz9ho84c3LOmWDJBNA1QG8UhnOgcsQmjjtOWKK aAW49Jm3wkAQU3kBNWfPLhcTCBCop+dcXks7kgpeSXSmorJRkyNZEw6t 6AmRWFLTFIE7O7f1i+zMD/1xKNWFfCa5/tCj61YUBiTvsOwzasWWFBHa HFgdmrJtvoSg8EfV4gDSraYnKPv8S+KHXaSlIJu8moYEfZyUJ21Uw16o 0kw7JA==
;; Received 525 bytes from 127.0.0.11#53(127.0.0.11) in 4 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.                    86400   IN      RRSIG   DS 8 1 86400 20260203050000 20260121040000 21831 . US1upvPOikxbv4uS5UFM7U4GBEdFXfYkStxTb5VfnY1KYy/9IdmzW3Bz 9o8AX7R/Uigd7ZE/OemLLt2c6lcY5py0W3xMH4j3Z2wHYq7EyTNgNFJH PrFYqeZf1BXZguWU4PESS/Nc2mH1/sIt/g/s+Pbj5ZVm/5jV+MZW4TvO 6ZzZlnfgXEtJDofMjiHNdXD6ppfcmPiQZMAcEVrZ7zAK6rCZiLxgZmUW 89d745s5OBcox7sgFe+4hPnCH/EGLOvmBmH2bco58SMY6U54HGe+wUWv 3QUDdGa0kOMzFUNeRht6syoHVyFZwmQCF9Lho523ZTu/XjEl7wiV4VUQ 7lwUzg==
;; Received 1181 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 28 ms

mailcow.com.            172800  IN      NS      olivia.ns.cloudflare.com.
mailcow.com.            172800  IN      NS      memphis.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20260126002710 20260118231710 35511 com. 0bNytozFV1z10ZDaGdUh2zPszt/f7UxjqIddWwwh4sshp0Cd0hizxKrl +LU0xu3xVugr78hdtQdRRiuxb/3GAw==
OTRHC127D8TS94N1TRH2PEQQADAC7UV4.com. 900 IN NSEC3 1 1 0 - OTRHDB4NLI2FAGH74FCL1NQGU990E81N NS DS RRSIG
OTRHC127D8TS94N1TRH2PEQQADAC7UV4.com. 900 IN RRSIG NSEC3 13 2 900 20260127012118 20260120001118 35511 com. 7Ie+Rj11/S5tg45YXSbk8s9ZlWhpUvu366XH34b8MzOvHdIaW1tE2tnh OS6B+OuvXY8Rg3FteThp9p1bwP1PRA==
;; Received 728 bytes from 2001:503:eea3::30#53(g.gtld-servers.net) in 8 ms

mailcow.com.            1800    IN      SOA     memphis.ns.cloudflare.com. dns.cloudflare.com. 2394092424 10000 2400 604800 1800
;; Received 112 bytes from 2606:4700:50::a29f:26dd#53(olivia.ns.cloudflare.com) in 8 ms

Use -4 to use IPv4 only for dig:

ca73da79caec:/# dig -4 +trace fuzzy.mailcow.email

; <<>> DiG 9.18.34 <<>> -4 +trace fuzzy.mailcow.email
;; global options: +cmd
.                       86245   IN      NS      j.root-servers.net.
.                       86245   IN      NS      b.root-servers.net.
.                       86245   IN      NS      c.root-servers.net.
.                       86245   IN      NS      e.root-servers.net.
.                       86245   IN      NS      f.root-servers.net.
.                       86245   IN      NS      i.root-servers.net.
.                       86245   IN      NS      g.root-servers.net.
.                       86245   IN      NS      h.root-servers.net.
.                       86245   IN      NS      k.root-servers.net.
.                       86245   IN      NS      l.root-servers.net.
.                       86245   IN      NS      d.root-servers.net.
.                       86245   IN      NS      m.root-servers.net.
.                       86245   IN      NS      a.root-servers.net.
.                       86245   IN      RRSIG   NS 8 0 518400 20260203050000 20260121040000 21831 . B+Xifq7eK97OOCJVACVgSUk5UFVttgM3INFEp4pUtyY2kxU8FfVOIGk/ ajhPKUd1QkhQRdmsZmEONXEdX5cv4fQQ/x5pJawJObouKiRK3HAZgxvx zQReAd664mLCVovk3Byz9ho84c3LOmWDJBNA1QG8UhnOgcsQmjjtOWKK aAW49Jm3wkAQU3kBNWfPLhcTCBCop+dcXks7kgpeSXSmorJRkyNZEw6t 6AmRWFLTFIE7O7f1i+zMD/1xKNWFfCa5/tCj61YUBiTvsOwzasWWFBHa HFgdmrJtvoSg8EfV4gDSraYnKPv8S+KHXaSlIJu8moYEfZyUJ21Uw16o 0kw7JA==
;; Received 525 bytes from 127.0.0.11#53(127.0.0.11) in 0 ms

email.                  172800  IN      NS      v0n0.nic.email.
email.                  172800  IN      NS      v2n0.nic.email.
email.                  172800  IN      NS      v0n2.nic.email.
email.                  172800  IN      NS      v0n3.nic.email.
email.                  172800  IN      NS      v0n1.nic.email.
email.                  172800  IN      NS      v2n1.nic.email.
email.                  86400   IN      DS      62422 8 2 92A9DA686674B9BC30EE72224130A7C761D5B01902DA9A5A62038C79 6A16BD33
email.                  86400   IN      RRSIG   DS 8 1 86400 20260203050000 20260121040000 21831 . rPXbDAXf5UOiGxakbbYWywuQl2Y2BPUVW3CVTe88+7c9Ttn5NrXlabVR /hqhbxXUgBV8k19WUjGazUwaNVbTjpRJVP5y8glpghfYkOf2wP4cXX3v oFbSP35lKHUrZnSrF2ytq6oJSVh9hxu+R8BvA/ZzBBoqba8OpNMYLGA+ +niS02wU3H/rk7F133IdDrCTrePQnP3aq1GE4fwq3QcDKd5KLP1M62r4 KKB19ZHJXzB0k1/EjW16pc/lkneYehEDeM8eTFTnMD/6WY+kDOjqV0nh fOEL3fms4xXmcZstRn1MiEi7MYsORIaiP/poMY7IWbm/rSut//RtNi9o oba9Ng==
;; Received 765 bytes from 198.41.0.4#53(a.root-servers.net) in 4 ms

mailcow.email.          3600    IN      NS      angus.ns.servercow.de.
mailcow.email.          3600    IN      NS      dexter.ns.servercow.net.
mailcow.email.          3600    IN      NS      galloway.ns.servercow.com.
mailcow.email.          3600    IN      DS      41879 13 2 7427B02EF2AB136E84740A14D3D2F7CC84AB821D55AB0EFEFCF4B950 4DC55FC6
mailcow.email.          3600    IN      RRSIG   DS 8 2 3600 20260207154202 20260117144202 59535 email. HxeR+uWUvEcP4TYOXgNaZrPiv9glL/ApZVXoWi4TKG6wv/sv8k3JsvLX TecejxXnHPZPxrhalgg7GptkCCxrvRJLeWy6Ad9ZvEceyMuMkDjbSNUH L6t8VtqOaLBE+eAp0+hwYlmQlyq53wwztbTqby1tlx2d5+GF7KsC3WdR +Mc=
;; Received 372 bytes from 161.232.12.35#53(v0n3.nic.email) in 32 ms

fuzzy.mailcow.email.    64800   IN      RRSIG   A 13 3 64800 20260129000000 20260108000000 41879 mailcow.email. rWMEmqz8qYxc3bdk0IWyOWdZJf4kZ6JtGa3viKd6u5JyG9A21znWFrx/ atAyU48VRDHyStBvwPmvf5aS/75rUg==
fuzzy.mailcow.email.    64800   IN      A       95.217.129.125
;; Received 173 bytes from 94.130.42.192#53(galloway.ns.servercow.com) in 8 ms

BisonOpiniatre

Which config can bloc that? My host run under Ubuntu 24.04.3 LTS and I dont use snap version of docker, I installed it from docker PPA repo.
Maybe a problem with routing table on my host?

DocFraggle

Does the above command work from the host system? Did you maybe not disable ufw on your host as recommended by the mailcow docs? Any other firewall you’re using at home?

renedubs

Hi All

same here, fresh ubuntu 24.04 LTS minimal install, first ipv6 was going to be disabled automatically. Then i checked everything, the host is able to complete all checks in ipv4/ipv6. I tried ./update.sh, the I got the same result:

Checking IPv6 settings…
Starting mailcow…
[+] up 1/1
[+] up 3/7 mailcowdockerized_mailcow-network Created [+] up 7/11mailcowdockerized_mailcow-network ✔ Network mailcowdockerized_mailcow-network ✔ Container mailcowdockerized-unbound-mailcow-1 [+] up 16/17 mailcowdockerized-netfilter-mailcow-1 [+] up 17/18ailcowdockerized_mailcow-network [+] up 19/19ailcowdockerized_mailcow-network ✔ Network mailcowdockerized_mailcow-network ✘ Container mailcowdockerized-unbound-mailcow-1 ✔ Container mailcowdockerized-netfilter-mailcow-1 ✔ Container mailcowdockerized-sogo-mailcow-1 ✔ Container mailcowdockerized-dockerapi-mailcow-1 ✔ Container mailcowdockerized-olefy-mailcow-1 ✔ Container mailcowdockerized-memcached-mailcow-1 ✔ Container mailcowdockerized-redis-mailcow-1 ✔ Container mailcowdockerized-clamd-mailcow-1 ✔ Container mailcowdockerized-postfix-tlspol-mailcow-1 ✔ Container mailcowdockerized-mysql-mailcow-1 ✔ Container mailcowdockerized-postfix-mailcow-1 ✔ Container mailcowdockerized-dovecot-mailcow-1 ✔ Container mailcowdockerized-php-fpm-mailcow-1 ✔ Container mailcowdockerized-ofelia-mailcow-1 ✔ Container mailcowdockerized-rspamd-mailcow-1 ✔ Container mailcowdockerized-nginx-mailcow-1 ✔ Container mailcowdockerized-acme-mailcow-1 ✔ Container mailcowdockerized-watchdog-mailcow-1 dependency failed to start: container mailcowdock 0.1s
Created 0.1s
Created 0.1s
Created 0.2s
Created 0.2s
Created 0.1s
Created 0.1s
Created 0.1ss
Error dependency unbound-mailcow failed to start 92.0s
Created 0.2ss
Created 0.2ss
Created 0.2ss
Created 0.2ss
Created 0.2ss
Created 0.2ss
Created 0.2ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
Created 0.1ss
erized-unbound-mailcow-1 is unhealthy

Collecting garbage…

there is allways entering a block rule at the end of iptables:

iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination
MAILCOW 0 – 0.0.0.0/0 0.0.0.0/0 /* mailcow */
DOCKER-USER 0 – 0.0.0.0/0 0.0.0.0/0
DOCKER-FORWARD 0 – 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain DOCKER (2 references)
target prot opt source destination
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:12345
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:4190
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:995
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:993
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:143
ACCEPT 6 – 0.0.0.0/0 10.141.97.250 tcp dpt:110
ACCEPT 6 – 0.0.0.0/0 10.141.97.5 tcp dpt:3306
ACCEPT 6 – 0.0.0.0/0 10.141.97.249 tcp dpt:6379
DROP 0 – 0.0.0.0/0 0.0.0.0/0
DROP 0 – 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
target prot opt source destination
DOCKER 0 – 0.0.0.0/0 0.0.0.0/0
DOCKER 0 – 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-CT (1 references)
target prot opt source destination
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target prot opt source destination
DOCKER-CT 0 – 0.0.0.0/0 0.0.0.0/0
DOCKER-INTERNAL 0 – 0.0.0.0/0 0.0.0.0/0
DOCKER-BRIDGE 0 – 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0
ACCEPT 0 – 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-INTERNAL (1 references)
target prot opt source destination

Chain DOCKER-USER (1 references)
target prot opt source destination

Chain MAILCOW (1 references)
target prot opt source destination

DROP 6 – 0.0.0.0/0 0.0.0.0/0 /* mailcow isolation */

how can i properly disable this block rule?

Thanks & Best Regards
René

DocFraggle

That has nothing to do with it. It’s a catch-all rule to keep Mailcow’s containers isolated from the rest of the Docker host/network, except for traffic that Mailcow explicitly allows earlier.

renedubs

In my case the error was, because I replaced the defait IPv4/IPv6 entry’s in the mailcow.conf.

BisonOpiniatre

Interesting, on my host, I have this error.
dig +trace fuzzy.mailcow.email
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> +trace fuzzy.mailcow.email
;; global options: +cmd
;; no servers could be reached
I disable ufw but I have the same résult.
I dont have other firewall on my host but I am behind a router, It’s a home server.
So my router have rules to forward port, (53 is define to reach my server) but I dont see any rules for outbound trafic.

esackbauer

BisonOpiniatre I disable ufw but I have the same résult.

I don’t get it why people are using ufw if the installation guide says it should not be used and why:
https://docs.mailcow.email/getstarted/prerequisite-system/#firewall-ports

I guess just disabling it does not clear the firewall/iptable rules properly

DocFraggle

BisonOpiniatre So my router have rules to forward port, (53 is define to reach my server)

Why? Do you have a DNS server running on your host?

BisonOpiniatre

Sorry I don’t see it. So now I disable it but not work better. I printed iptables rules for MAILCOW on host but I just had a drop rule:
sudo iptables -L MAILCOW -v -n
Chain MAILCOW (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP 6 – !br-mailcow br-mailcow 0.0.0.0/0 0.0.0.0/0 /* mailcow isolation */

I added these rules:

UDP 53

sudo iptables -I MAILCOW 1 -s 172.22.1.0/24 -p udp –dport 53 -j ACCEPT

TCP 53

sudo iptables -I MAILCOW 2 -s 172.22.1.0/24 -p tcp –dport 53 -j ACCEPT

But it’s not enough.
Worst, now dig google.com in Unbound don’t work anymore. 😭

BisonOpiniatre

DocFraggle
Removed now.

BisonOpiniatre

I’m not quite sure how work iptables but I see the drop rules for MAILCOW. I supposed that I needed to add rules to permit 53 trafic.

BisonOpiniatre

I don’t understand why I can ping google.com from Unbound container but dig return timeout.
Also I dont understand why dig try to connect to 127.0.0.11 when it have only 2 interface, 127.0.0.1 and 172.22.1.254.
Also I can try dig @127.0.0.1 of dig @172.22.1.254 but timeout occured everytime.

Also, I can dig google.com from my host but dig +trace don’t work.

BisonOpiniatre

BisonOpiniatre
I think is a problem in my unbound.conf

server:
  verbosity: 1
  #interface: 0.0.0.0
  interface: 127.0.0.11
  #interface: ::0
  logfile: /dev/console
  do-ip4: yes
  do-ip6: no
  do-udp: yes
  do-tcp: yes
  do-daemonize: no
  do-not-query-localhost: no
  val-permissive-mode: yes
  #auto-trust-anchor-file: "/etc/unbound/root.key"
  access-control: 0.0.0.0/0 allow
  access-control: 127.0.0.0/8 allow
  access-control: 172.22.1.0/24 allow
  access-control: 10.0.0.0/8 allow
  access-control: 172.16.0.0/12 allow
  access-control: 192.168.0.0/16 allow
  #access-control: fc00::/7 allow
  #access-control: fe80::/10 allow
  #access-control: ::0/0 allow
  directory: "/etc/unbound"
  username: unbound
  auto-trust-anchor-file: trusted-key.key
  #private-address: 10.0.0.0/8
  #private-address: 172.16.0.0/12
  #private-address: 192.168.0.0/16
  #private-address: 169.254.0.0/16
  #private-address: fc00::/7
  #private-address: fe80::/10
  # cache-min-ttl needs to be less or equal to cache-max-negative-ttl
  cache-min-ttl: 5
  cache-max-negative-ttl: 60
  root-hints: "/etc/unbound/root.hints"
  hide-identity: yes
  hide-version: yes
  max-udp-size: 4096
  msg-buffer-size: 65552
  unwanted-reply-threshold: 10000
  ipsecmod-enabled: no

remote-control:
  control-enable: yes
  control-interface: 127.0.0.1
  control-port: 8953
  server-key-file: "/etc/unbound/unbound_server.key"
  server-cert-file: "/etc/unbound/unbound_server.pem"
  control-key-file: "/etc/unbound/unbound_control.key"
  control-cert-file: "/etc/unbound/unbound_control.pem"

BisonOpiniatre

I just see now that my host il listening on port 53 with syatemd-resolved and avahi-daemon. I don’t know why I dont see it before with the tlpn CMD. So It’s posible that bloc the trafic from Unbound container?
I supposed that Docker flag an error when a port isn’t available.

BisonOpiniatre

It’s clear I have some conflict between my host and the Docker image. So I decided to make a fresh install of MailCow and retry to run Unbound, but it seems to have conflict again.
I decided to change of linux OS. It was planned for later but I think I will do it now.
But I planned to use Fedora uCore OS (immutable OS), but it comes with a preloaded Docker engine, the Moby Engine. I know Mailcow cannot run over any kind of Docker installation, but can I install it on Moby Engine?

esackbauer

I would strongly suggest you try it on a Debian install, without ufw.

BisonOpiniatre

esackbauer
Minimal Install?

DocFraggle

BisonOpiniatre I’m running the normal Debian 13 version, I guess you can use the minimal installation as well

« Previous Page