Why a Proxy Container Does Not Automatically Use the DNS Container
Sharing a Docker host, sharing a network and selecting a resolver are three different arrangements. Follow the DNS query from inside the proxy.
Running a proxy and DNS server on one Docker host does not connect their DNS paths. Three separate relationships matter:
- Network reachability. Separate Compose projects normally have separate default networks. Put the services on a suitable shared network, either within one project or through an explicitly shared network between projects.
- Service discovery. A custom Docker network's embedded DNS can resolve container names. That lets an application discover a neighbor; it does not automatically select that neighbor as its DNS resolver.
- Resolver selection. Identify the resolver used inside the proxy container. Compose's
dnsfield takes DNS server addresses. A name such asdns.localresolving in an application does not make it a valid value for that field.
Trace the query from the proxy container to its configured resolver address. Confirm a route and a DNS listener at that address. Publishing host port 53 creates a host-side access path; it does not tell containers to use it. Containers sharing a network may instead communicate directly.
If configuration references the DNS container's address, keep it stable under compatible IPAM configuration. A dynamically allocated address copied from yesterday's container can fail on recreation. Also inspect the resolver's upstream path: forwarding unanswered queries back to itself creates a different failure from an unreachable resolver.
Finally, identify who resolves the destination. An HTTP proxy resolving a CONNECT name can use this container path; a SOCKS client resolving locally may not. A host lookup proves the host's route, not the proxy process's.