If I manually edit /etc/resolv,conf in the running docker it works, but that will get over written in some future update I expect, so it’s not really a solution.
Thamk you for the details. Now I see you are using a not officially supported distribution. We discussed a DNS-related issue on OpenSuse Tubleweed recently:
It was about rootless Docker but that might help you as well. At the end of the discussion there is link to the OpenSuse bugtracker.
I moved it for you and also edited your first post. Please, share different type of outputs in separate code blocks. That helps people to understand your quetion easier.
Rather different issue, being network access for docker it self versus docker containers, but I tried the hack fix of replacing the hosts /etc/resolv.conf link with a file and that didn’t help.
If I remember correctly, it was about both, using the Docker daemon to pull images was just the first step because of Rootless Docker. A rootless Docker is a kind of Docker in container. But of course it’s a different issue. That was about rootless Docker and yours is probably not rootless. It is still on a not officially supported Linux distribution which I don’t use, except when I spend hours to reproduce the issue to help
In the other topic I linked the original issue was not being able to access the built-in DNS server of the Rootless Docker. Everything else was just a consequence. We could ping every IP there too. That’s why I think you could have a better luck finding a solution in an OpenSuse forum.
We could also ask for a bugtracker link in the other topic. I’m going to to that mentioning this topic too.
In the meantime, checking your question again I’ve noticed you set the DNS server in the compose file, although in case of user-defined Docker networks, don’t expect the resolv.conf containing those DNS servers. Since Docker lets you use service names as domain names, it has to run its own DNS server and forward request to your DNS servers when it doesn’t know about the domain.
It could make sense that docker uses the dns-servers as upstream resolver for the build-in dns resolver, which is reachable on 127.0.0.11. As @rimelek pointed out: it is required for service discovery to resolve container names.
Thinking of ways to look at this differently: I think this only occurs on the docker images I’m using docker-compose for, those I use a docker run script for get the setting I have in /etc/docker/daemon.json (which I understand wont work with coms between docker images, but that isn’t always important)
Containers started by docker run - without specifying a network - use the default bridge network.
The default bridge network does not provide service discovery, as such containers attached to it do not use the buildin dns-resolver 127.0.0.11
Only user defined networks support service discovery. Docker compose deployments by default create a user defined network. If a container is started with docker run --network aNetworkYouCreated .., it will also use a user defined network. In this case 127.0.0.11 will always be the nameserver in /etc/resolv.conf. Without it service discover can not work.
So I can probably get away with setting the docker-compose ones to bridged network and I’ll probably get the result I want. At least for those that don’t need service discovery (All of the ones I care about…):
This will effectively “jail” the container’s network to the default bridge. Once a network_mode is set, it won’t be possible to attach this container to any other user defined network.
I think it’s a valid solution for the qbittorrent container, but isn’t going to work for “nextcloud’s aio mastercontainer”. Apparently setting it still lets it join the “nextcloud-aio” network, but the containers it then spawns are only on the “nextcloud-aio” with the internal resolver DNS config, which means they can’t work (the first one that is spawned is to check the domain name to be used, so DNS is pretty important to it)
How does 127.0.0.11 work for DNS? I’ve also got a pihole docker image running on this machine, that would have port 53 bound do docker can’t be doing internatl dns resolution on that port.
(the first one that is spawned is to check the domain name to be used, so DNS is pretty important to it)