Introduction
Docker’s internal DNS works well when containers share the same custom network and the runtime is allowed to use the embedded resolver. When DNS resolution fails inside a Docker setup, the root cause is often not “DNS is broken” in the abstract. It is that the containers are not on the same network, the lookup name is wrong for the topology, or the resolver configuration is not what the operator thinks it is.
Symptoms
- One container cannot resolve another by service or container name
- Application connection strings work with IPs but not service names
nslookuporgetent hostsfails inside the container- The problem appears after network changes, Compose refactors, or daemon config edits
Common Causes
- The containers are attached to different networks
- The stack is relying on the default bridge model instead of a proper shared network
- The container expects host DNS behavior instead of Docker’s embedded resolver behavior
- Custom daemon DNS configuration interferes with expected service-name resolution
Step-by-Step Fix
- 1.Verify both containers share the same network
- 2.Name resolution by service or container name depends on network membership, not just on both containers running.
docker network inspect my-network- 1.Check the resolver configuration inside the container
- 2.Docker’s embedded resolver typically appears as
127.0.0.11inside the container.
docker exec my-container cat /etc/resolv.conf- 1.Use a custom user-defined network for multi-container setups
- 2.Service discovery is much more predictable on an explicit shared network than on ad hoc defaults.
docker network create my-network- 1.Retest name resolution using the actual service name
- 2.After attaching the right network, test the exact hostname the application uses.
Prevention
- Put related containers on explicit shared networks
- Document which service names should resolve on which networks
- Avoid assuming the default bridge network gives the same service discovery behavior as Compose networks
- Check container resolver configuration after daemon or network policy changes