How a Forgotten Search Domain in /etc/resolv.conf Broke Docker Container DNS and How I Restored It -

The first time I noticed the problem, a Docker‑based microservice was silently timing out on every outbound request. The logs were full of “no servers could be reached” errors, but the host machine could resolve the same hostnames without issue. After a quick check of the container’s /etc/resolv.conf, I saw an odd line: search mydomain.com. The host’s /etc/resolv.conf had no such entry. That single missing search domain was the root of the DNS failure inside containers.

The Symptom

$ docker run --rm alpine nslookup example.com
Server: 127.0.0.53
Address: 127.0.0.53#53

*** Can't resolve example.com: Server failed

The host resolved example.com fine:

$ nslookup example.com
Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

The discrepancy was clear: the container was using the host’s DNS server (127.0.0.53, the systemd‑resolved stub), but the search domain configuration was missing inside the container.

Root Cause Investigation

The first step was to confirm that the container was indeed inheriting the host’s resolver configuration. Docker mounts /etc/resolv.conf from the host into the container unless overridden by --dns or --dns-search. On my Debian 12 system, systemd-resolved provides the stub at 127.0.0.53 and writes the real DNS servers to /run/systemd/resolve/resolv.conf. The host’s /etc/resolv.conf looked like:

# Generated by systemd-resolved
nameserver 127.0.0.53
options edns0 trust-ad

No search line. Inside the container, however, cat /etc/resolv.conf returned:

# Generated by Docker
search mydomain.com
nameserver 127.0.0.53
options ndots:5

The search entry was injected by Docker from the host’s resolv.conf if the host had a search line. In my case, the host had a search line in /run/systemd/resolve/resolv.conf that Docker read, but the host’s /etc/resolv.conf had been truncated by a recent systemd update that removed the search directive for security reasons. Docker, however, still copied the stale value from /run/systemd/resolve/resolv.conf into the container, leading to a mismatch.

Understanding /etc/resolv.conf and Docker

Docker’s default behaviour is to copy the host’s /etc/resolv.conf into each container. The container’s resolver is a thin wrapper around the host’s DNS stack; it does not perform its own DNS resolution. Therefore, any misconfiguration on the host propagates to all containers unless you explicitly override it.

When the host uses systemd-resolved, the real resolver configuration lives in `/run/systemd/

linux open-source

The Symptom

Root Cause Investigation

Understanding /etc/resolv.conf and Docker

See also