DNS settings ignored?

I’m having trouble getting dockers to have valid DNS settings.

gareth@cube-server ~/d/qbittorrent> docker --version
Docker version 24.0.6-ce, build 1a7969545d73
gareth@cube-server ~/d/qbittorrent> docker-compose --version
Docker Compose version 2.22.0
gareth@cube-server ~/d/qbittorrent> cat docker-compose.yml
version: "2.1"
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
      - PUID=1000
      - PGID=100
      - TZ=Etc/UTC
      - WEBUI_PORT=18080
      - /data.local/qbittorrent/config:/config
      - /torrents/downloads:/downloads
      - 18080:18080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

gareth@cube-server ~/d/qbittorrent> cat /etc/docker/daemon.json

  "log-level": "warn",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  "dns": [ "", "", "" ]
gareth@cube-server ~/d/qbittorrent> docker exec qbittorrent cat /etc/resolv.conf
search localdomain
options ndots:0
gareth@cube-server ~/d/qbittorrent> docker exec qbittorrent ping google.com
ping: bad address 'google.com'
gareth@cube-server ~/d/qbittorrent [1]> docker exec qbittorrent ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=0.077 ms
64 bytes from seq=1 ttl=64 time=0.139 ms
64 bytes from seq=2 ttl=64 time=0.137 ms
64 bytes from seq=3 ttl=64 time=0.177 ms

^ on OpenSuse Tumbleweed.

What am I missing?

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.

Please, share how you installed Docker and the output of the following commands:

docker version
docker info

I don’t see any sign of using Docker Desktop which is the category of your topic.

Installed via zypper from the tumbleweed-oss repo.

gareth@cube-server ~/d/qbittorrent> docker version
 Version:           24.0.6-ce
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        1a7969545d73
 Built:             Wed Oct 11 00:00:00 2023
 OS/Arch:           linux/amd64
 Context:           default

  Version:          24.0.6-ce
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       1a7969545d73
  Built:            Wed Oct 11 00:00:00 2023
  OS/Arch:          linux/amd64
  Experimental:     true
  Version:          v1.7.7
  GitCommit:        8c087663b0233f6e6e2f4515cee61d49f14746a8
  Version:          1.1.9
  GitCommit:        v1.1.9-0-gccaecfcbc907
  Version:          0.2.0_catatonit
gareth@cube-server ~/d/qbittorrent> docker info
 Version:    24.0.6-ce
 Context:    default
 Debug Mode: false
  buildx: Docker Buildx (Docker Inc.)
    Version:  0.11.2
    Path:     /usr/lib/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.22.0
    Path:     /usr/lib/docker/cli-plugins/docker-compose

 Containers: 33
  Running: 33
  Paused: 0
  Stopped: 0
 Images: 51
 Server Version: 24.0.6-ce
 Storage Driver: btrfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 oci runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8c087663b0233f6e6e2f4515cee61d49f14746a8
 runc version: v1.1.9-0-gccaecfcbc907
 init version: 
 Security Options:
   Profile: builtin
 Kernel Version: 6.5.6-1-default
 Operating System: openSUSE Tumbleweed
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 31.26GiB
 Name: cube-server
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: true
 Insecure Registries:
 Live Restore Enabled: false

Oops, I skimmed over ‘desktop’, I forget that is a thing.

Should I move the question?

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.

1 Like

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 :slight_smile:

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 As @rimelek pointed out: it is required for service discovery to resolve container names.

Can I query what the built in resolver is configured with?

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)

That’s actually a great question.

As I never had the need to look at the configuration, I have no idea where the configuration is stored or can be accessed.

1 Like

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

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

network_mode: bridge

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 :frowning: (the first one that is spawned is to check the domain name to be used, so DNS is pretty important to it)

Today’s notes:

  • Plausibly the same issue as No dns inside container
  • How does 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.

^ is the solution, sorry I didn’t mention the first DNS server being on the same host, that didn’t occur to me as relevant.