Docker flooding syslog with dns errors

Hi,
I just went though my logs and found out docker is flooding with dns errors like:

level=error msg=“[resolver] failed to query external DNS server” client-addr=“udp:127.0.0.1:47051” dns-server=“udp:127.0.0.1:53” error="read udp 127.0.0.1

Im just wondering why that is? Everything works normally and nslookup is working fine from inside containers.
would this be safe to ignore? and even if yes, how can I stop it from flooding my log?

thanks!

I’m not sure at the moment what exactly that error log indicates, but 127.0.0.1:53 is likely the stub resolver on the host and it looks as if a container or something wanted to send requests to that resolver and could not reach th IP or port.. I wrote about how Docker handles DNS here

How did you install Docker?

We usually need the following information to understand the issue:

  1. What platform are you using? Windows, Linux or macOS? Which version of the operating systems? In case of Linux, which distribution?

  2. How did you install Docker? Sharing the platform almost answers it, but only almost. Direct links to the followed guide can be useful.

  3. On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:

    docker info
    docker version
    

    Review the output before sharing and remove confidential data if any appears (public IP for example)

    dpkg -l 'docker*' | grep '^ii'
    snap list docker
    

    When you share the outputs, always format your posts according to the following guide: How to format your forum posts

thanks for the reply, here some more info about my setup:
the stub resolve on the Host is disabled, Adguard DNS container in host mode listens on port 53 and works well when testing with dig.
Platform is Debian Trixie (OMV8) with compose plugin for docker.
Docker Info:

Client: Docker Engine - Community
 Version:    29.2.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 26
  Running: 24
  Paused: 0
  Stopped: 2
 Images: 32
 Server Version: 29.2.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.73+deb12-amd64
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.4GiB
 Name: xxx
 ID: xxx
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

docker version:

Client: Docker Engine - Community
 Version:           29.2.1
 API version:       1.53
 Go version:        go1.25.6
 Git commit:        a5c7197
 Built:             Mon Feb  2 17:17:31 2026
 OS/Arch:           linux/amd64
 Context:           default

packages:

ii  docker-buildx-plugin      0.31.1-1~debian.13~trixie   amd64        Docker Buildx plugin extends build capabilities with BuildKit.
ii  docker-ce                 5:29.2.1-1~debian.13~trixie amd64        Docker: the open-source application container engine
ii  docker-ce-cli             5:29.2.1-1~debian.13~trixie amd64        Docker CLI: the open-source application container engine
ii  docker-compose-plugin     5.1.0-1~debian.13~trixie    amd64        Docker Compose (V2) plugin for the Docker CLI.

snap is not installed.

Thanks for the info. So I don’t have experience with ADGuard to know if that can cause those logs, but as far as I know, Docker would recognize whatever DNS you configured on the host in /etc/resolv.conf. Is it posisble that you have configs containing 127.0.0.1:53 while ADGuard is not listening on that? I don’t know why that would not break DNS reoslution on the host completely and why everything works, but you could also try directly setting the DNS server IP in the daemon.json to the one on which ADGuard’s DNS is available.

But then you would need to restart the daemon. Maybe this was the problem in the first place. If the DNS was changed after Docker was already running and containers were created. But again, if the DNS is wrong, Docker cannot forward requests to external DNS servers and it would not work from containers.

Adguard is listening in 127.0.0.1:53, I can for example do nslookup example.com 127.0.0.1 and get a valid response.
About the docker daemon restart… the only thing I was just thinking is, when restarting the docker daemon, all containers restart right? so in the beginning when the daemon starts, my adguard container is not yet running. I would assume that this doesnt matter because it will run a few seconds later though… Do you think this could be a problem?

That makes sense. So ADGuard is running in a container. That means exactly whaty ou wrote. There is no DNS resolution until that container starts and that explains why the daemon logs that but everything works right after the DNS server started.

When ADGuard started, do the DNS error logs stop or contiue “flooding”?

no it continues to log this.
I narrowed it down to some containers that cause it, they are on a docker network with traefik as proxy.. dont know if this has anything todo with that.
as a test, can I change the IP that docker uses for DNS? want to try what happens if I change it to 8.8.8.8 or my local lan IP instead of 127.0.0.1, but dont want to change resolv.conf

If you search for “dns” in the linked documentation, you will only find the relevant parameters to set in different ways. Or you can start a test container without changing the daemon and pass the dns parameters to the container.

finally found the problem!
Its Adguards rate limiting. One container was making a lot of requests every 5 minutes, and adguard rate limits them. I now added 127.0.0.1 to the rate limit exclusion list and the spamming is finally over! :slight_smile:
thanks for your help!

Thank you for sharing the solution. You can also click on the Solution checkbox below your last post so it will be shown right at the beginning of the topic.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.