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…):
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)