• Community Support
  • USEnglish

  • Be careful with update from 2024-07 to 2024-08 leads to dns error in unbound

Must be the script.

Disabled the forward-zone. Did a docker compose down followed by a docker compose up -d. Entered the unbound container and altered the healthcheck.sh to 127.0.0.11. Did a docker compose restart unbound-mailcow.
[+] Restarting 1/1
✔ Container mailcowdockerized-unbound-mailcow-1 Started

docker compose ps
mailcowdockerized-unbound-mailcow-1 mailcow/unbound:1.23 “/docker-entrypoint.…” unbound-mailcow 24 minutes ago Up 11 minutes (healthy) 53/tcp, 53/udp

I’ll define a forward-zone as workaround until this is fixed.


    stefan21 altered the healthcheck.sh to 127.0.0.11

    127.0.0.11 is Docker’s own internal DNS service. All containers use 127.0.0.11 to include internal names of Docker containers. Your change simply asks another DNS server instead of Unbound, which effectively makes the health check useless.

    stefan21 1.) dig +short +timeout=2 +tries=1 fuzzy.mailcow.email @127.0.0.1 is giving nothing back

    That’s why the health check fails, so it’s working correctly. In your tests above, I missed that you skipped the @127.0.0.1 part, i.e. you were not asking Unbound directly.

    So the question now is why your Unbound is not resolving DNS requests.

        DocFraggle I suggest you edit your data/Dockerfiles/unbound/healthcheck.sh script and add some debug log output starting at line 53

        GitHub Icon mailcow/mailcow-dockerizedblob/master/data/Dockerfiles/unbound/healthcheck.sh#L53

        GitHub Icon GitHub
        mailcow-dockerized/data/Dockerfiles/unbound/healthcheck.sh at master · mailcow/mailcow-dockerized
        mailcow: dockerized - 🐮 + 🐋 = 💕. Contribute to mailcow/mailcow-dockerized development by creating an account on GitHub.
        mailcow: dockerized - 🐮 + 🐋 = 💕. Contribute to mailcow/mailcow-dockerized development by creating an account on GitHub.

        For example, output the details of the dig command in $dig_output and maybe even the return code. The script just checks if rc=0, but maybe it’s not 0, dig can return multiple return codes apart from 1

        The script may still run things differently from you running commands inside the container

        Which brings me back to my suggestion from above… why don’t you have a deeper look and log the details from the healthcheck script?

          Found it.

          I’m redirecting all DNS requests from LAN to the opnsense. As I already wrote, on the opnsense UNBOUND is running. I have to think about creating seperate rules for the mailcow, or leave the workaround with the forward-zone.

          Question remains why did it work in version 2024-07 (obviously because of changing the healthcheck script), and what reason for is DNS working inside of the unbound-container working with ping, dig and nslookup. Why in general, changing the script? Running mailcow behind a proper configured firewall will cause hickups.

          I’ll stop this now. Maybe someone can mark this thread as solved or tell me, how to do it.

          BTW - did I overlook something in the doku? Can’t find anything about this special? issue. Is it special to redirect any DNS request from a LAN to a firewall and let the firewall do the job? AFAIK there are reasons to configure a FW in this way…

            I read this. I do understand. My opnsense is using unbound as resolver. Because I do know about the problems with external resolvers. There are reasons why a sysadmin forces any device in the LAN to use only the resolver from a firewall.

            What I don’t like is drilling holes in a firewall… of course a mail server needs ports (25, 465, 587) to communicate with other mail servers. Why icmp and DNS can’t be used from a firewall, IDK.

            Anyway - as I know the pro’s and con’s of my setup, I’ll stay with a forward-zone in the mailcow pointing to the IP of my opnsense.

            You didn’t answer to my question, why the healthscript worked before. I didn’t change anything in my firewall. Do you know the reason?

            a month later

            I am having this issue with a fresh mailcow install.

            After the heathcheck fails, I exec into the container and run the dig command from the healthcheck and get an error

            Seems unbound isn’t actually running here? Thoughts/suggestions?

            a month later

            I have the same issue. Manually updating healtchec.sh to @127.0.0.11 solve this healtcheck issue, but unbound is still not workuing correctly for the other docker containers. As i use multiple docker networks i use a non standard IPV4_NETWORK=172.40.1 in mailcow.conf which might correlate with the problem.

              h2owasser

              1. Just want to mention that everything works without problems if you insert @127.0.0.11 in healtcheck: sed 's/127.0.0.1 /127.0.0.11 /' ./data/Dockerfiles/unbound/healthcheck.sh > ./data/Dockerfiles/unbound/healthcheck.sh

              2. delete all dns: entries and its items in docker-compose.yml

              3. exec docker build data/Dockerfiles/unbound -t mailcow/unbound:own

              4. add in docker-compose.overwrite.yml:
                services:
                unbound-mailcow:
                build: ./data/Dockerfiles/unbound
                image: mailcow/unbound:own

              5. execute update.sh

                18 days later

                I just upgraded to the November release and had this exact problem. I did find a root cause IN MY SETUP. Sharing in case it helps.

                Setup:

                • Mailcow DNS with forwarding domain to high-powered Pfsense box sitting next to mailcow (no need for two unbounds here).
                • PFSense configured with NAT to redirect all LAN DNS requests to itself
                • PFSense running PFBlocker to block outbound DNS-over-HTTP (DOH) and DNS-Over-TCP queries

                Issue:

                • PFBlocker, by default, blocks trafic of ALL Protocols types to the addresses in it’s DOH block lists
                • Block lists include 1.1.1.1, 8.8.8.8, 9.9.9.9 which Mailcow uses to check the health of Unbound

                Solution:

                • Edit the DOH rule to only block TCP & UDP protocols, thereby allowing ICMP to pass
                • I can imagin this can occur with other firewall softwares
                • In PFSense, to do this: PFBlocker -> IP -> IPv4 -> DoH_IP -> Advanced Outbound Firewall Rule Settings ->Custom Protocol -> TCP/UDP
                a month later

                Skittluier Do you have a special setup for you server? Any local firewall running on the host system which may block DNS requests from inside the docker network? The PITA-award-winning selinux enabled?

                    DocFraggle Hey DocFraggle! Again, thanks for your swift answer. You definitely deserve that “Moolevel 200”.

                    Do you have a special setup for you server?
                    Not that I know. I’m using the Mailcow Docker container, Caddy and Cloudflare for making this entire connection.

                    Any local firewall running on the host system which may block DNS requests from inside the docker network?
                    Nope.

                    The PITA-award-winning selinux enabled?
                    Yes, SELinux is enabled. Although the state of SELinux is permissive, it doesn’t enforce rules but gives warnings instead.

                    I do have some more information on this matter. The thing that broke Mailcow for me is my server only giving back an IPv6 address.

                    I’ve managed to give it an IPv4 address as well now thanks to this thread, but now I’m having that DNS issue: Super User Icon How do I make Ubuntu Server get IPv4 address?

                    Super User Icon Super User
                    How do I make Ubuntu Server get IPv4 address?
                    I'm running Ubuntu Server in VirtualBox. When I select the internal network option for the network adapter and start up the VM, I only get IPv6 address. I need an IPv4 address as well. My host (run...
                    Super User

                      Did you restart the stack after adding the IPv4 address?

                      docker compose down
docker compose up -d

                        DocFraggle Yup, with the help of the update.sh script. This unfortunately didn’t change the situation.

                          7 days later

                          sadly, i got the same issue

                          edit: but with a fresh install

                          Which kernel? And which docker version? Local firewall? Selinux?

                          No one is typing