stefan21 BTW - did I overlook something in the doku?
Yes: . It is NOT recommended to use any other external resolver and have unbound resolve everything for you, by directly using the root nameservers.
English
stefan21 BTW - did I overlook something in the doku?
Yes: . It is NOT recommended to use any other external resolver and have unbound resolve everything for you, by directly using the root nameservers.
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?
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?
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.
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
delete all dns:
entries and its items in docker-compose.yml
exec docker build data/Dockerfiles/unbound -t mailcow/unbound:own
add in docker-compose.overwrite.yml
:
services:
unbound-mailcow:
build: ./data/Dockerfiles/unbound
image: mailcow/unbound:own
execute update.sh
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:
Issue:
Solution:
Tagging @DocFraggle here as well. Maybe you know what I should do to debug this properly? Thank you! <3
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:
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.
sadly, i got the same issue
edit: but with a fresh install
Which kernel? And which docker version? Local firewall? Selinux?