I'm fairly new to Docker and spent most of a day debugging a web app that I was containerizing. The frontend was running in a Caddy container on a DigitalOcean droplet, but it wasn't responding to requests. Initially, the container had crashed because it tried to bind to a port that was already in use. After fixing that, it still failed, and the logs contained vague errors about being unable to connect to the internet.
Running `nslookup web1` inside the container produced:
`Server: 127.0.0.53`
`Address: 127.0.0.53#53`
`** server can't find web1: SERVFAIL`
Adding `dns: [1.1.1.1, 8.8.8.8]` to the Compose configuration fixed the problem. I'm trying to understand how I could have reached that diagnosis independently. Is there a general debugging process or documentation that would point from vague network errors to Docker's DNS configuration? Was this an unusual environment-specific issue, or is there important Linux and Docker networking knowledge I should learn first?
2 Answers
The `127.0.0.53` address is the systemd-resolved stub resolver, not an external DNS server. It normally forwards queries based on the host’s configured upstream resolvers. Seeing it alone doesn’t necessarily prove that the container is broken, but a `SERVFAIL` tells you name resolution failed. A good first step is to test DNS and connectivity separately with commands such as `cat /etc/resolv.conf`, `getent hosts example.com`, and `curl` to a known IP and hostname.
Docker normally creates its own internal DNS service for containers on a user-defined network, commonly visible as `127.0.0.11`, and forwards external lookups through the host’s configured resolvers. On systems using systemd-resolved, the host’s stub configuration and Docker’s resolver behavior can interact badly if the upstream resolver list is missing or misconfigured. The practical lesson is less about memorizing this exact failure and more about narrowing the problem: check container status and logs, verify port bindings, inspect the container’s network and `/etc/resolv.conf`, test name lookup from inside the container, then test reachability by IP. Environment-specific DNS problems are genuinely easy to miss, so using targeted experiments is normal rather than a sign that you shouldn’t be using Docker.
It’s also worth checking the host’s resolver configuration and Docker daemon settings before hard-coding public DNS servers. Explicit DNS entries can work, but they may bypass local DNS, split-horizon names, or provider-specific settings.
That distinction helps. I treated the address in `resolv.conf` as if it were supposed to be directly reachable from every container, instead of checking what resolver Docker was actually providing.