Problem: DNS resolution fails inside Docker containers (wget: bad address / Temporary failure in name resolution / Could not resolve host) —— Trove problem library

What you will run into

Accessing a domain inside a container fails to resolve (wget: bad address 'github.com' / curl: (6) Could not resolve host / Temporary failure in name resolution), while the same domain works on the host and direct IP access works too.

It often appears after configuring --dns on the container or switching network environments (campus/company network/proxy).

The classic trap: tutorials tell you to set --dns 8.8.8.8, but many CN networks are unfriendly to UDP 53 on 8.8.8.8.

Why this happens

The container resolves with its own /etc/resolv.conf. By default docker generates one inheriting the host's nameservers; but once overridden with docker run --dns, compose's dns:, or daemon.json's "dns", the container only asks the specified DNS.

If that DNS is unreachable, or the domain only has records on a specific DNS (intranet domains), resolution fails.

• The error text depends on the program: busybox reports bad address, glibc programs report Temporary failure in name resolution - the same problem, different looks.
• Direct IP works but the domain doesn't = a DNS-layer problem; layer first, then act.

Containers do not run their own DNS service; they just forward resolution requests to the nameservers listed in /etc/resolv.conf.

By default Docker inherits the host's nameservers to generate that file, but once you override with --dns, compose dns:, or daemon.json "dns", the container will only ask the servers you specified.

DNS is plaintext UDP/53, and dropped packets to 8.8.8.8 are common on many domestic networks — the "universal DNS from tutorials" may be exactly your break point.

Deterministic path: if direct IP works but the hostname does not, the problem is in the resolution chain; inspect cat /etc/resolv.conf inside the container to see which nameserver is used;

for intranet hostnames you must use the DNS handed out by your intranet/VPN — public DNS has no record for them, and swapping public DNS servers will never fix it.

Step by step

1. Layer-by-layer confirmation — Required

Host getent hosts github.com works -> check the resolution config inside the container:

docker run --rm <image> cat /etc/resolv.conf

nameserver overridden (possibly showing Overrides: [nameservers]) -> the problem is the specified DNS.

2. Specify a working DNS for a single container — Required

docker run --dns 223.5.5.5 --dns 119.29.29.29 ...

223.5.5.5 (Aliyun) / 119.29.29.29 (Tencent) CN public DNS, measured working.

3. Compose scenario — Required

services:
  app:
    dns:
      - 223.5.5.5
      - 119.29.29.29

4. Global default (affects all containers) — Required

Add "dns": ["223.5.5.5", "119.29.29.29"] to daemon.json and restart the daemon.

5. Test before configuring 8.8.8.8 — Required

timeout 5 bash -c 'echo > /dev/tcp/8.8.8.8/53' && echo reachable

Use it only if reachable; otherwise switch to CN public DNS. When intranet domain resolution fails, add the intranet/VPN-assigned DNS to --dns, alongside public DNS if needed.

How to confirm it works

docker run --rm --dns 223.5.5.5 <image> wget -qO- http://github.com >/dev/null && echo OK

No more resolution failure = success. Measured: default inheriting host DNS -> wget succeeds (exit 0); --dns 192.0.2.1 (guaranteed unreachable) -> bad address (exit 1); --dns 8.8.8.8 reachable on campus -> succeeds; --dns 223.5.5.5 -> succeeds.

Other environments

Symptom

Accessing a domain inside a container fails to resolve (the same domain works on the host):

wget: bad address 'github.com'                 # busybox/alpine wget
curl: (6) Could not resolve host: github.com    # curl
Temporary failure in name resolution            # ping / apt-get etc. (glibc programs)

Signs: direct IP works but the domain doesn't (wget http://<IP>/ succeeding proves it's the DNS layer); host resolution is fine but fails inside the container; often after configuring --dns or switching network environments (campus/company/proxy); WSL + Docker Desktop upgrades may also cause it occasionally (for-win#13808).

Cause

The container resolves with its own /etc/resolv.conf. By default docker generates one inheriting the host's nameservers; but once overridden with docker run --dns <ip>, compose's dns:, or daemon.json's "dns", the container only asks the specified DNS. If that DNS is unreachable (configuring 8.8.8.8 on CN networks is the classic trap: many CN networks block/drop UDP 53), or the domain only has records on a specific DNS (intranet domains), resolution fails. The error text depends on the program: busybox reports bad address, glibc programs report Temporary failure in name resolution - the same problem, different looks.

Solution

1. Layer first: host getent hosts github.com works -> cat /etc/resolv.conf inside the container to see the nameserver (overridden ones show Overrides: [nameservers]).
2. Specify a working DNS for a single container (most common): docker run --dns 223.5.5.5 ... (Aliyun) or --dns 119.29.29.29 (Tencent) - CN public DNS, measured working.
3. compose: add dns: [223.5.5.5, 119.29.29.29] under the service.
4. Global default: add "dns": ["223.5.5.5", "119.29.29.29"] to daemon.json and restart the daemon (affects all containers; confirm before changing).
5. Test before configuring 8.8.8.8 (CN networks vary a lot): timeout 5 bash -c 'echo > /dev/tcp/8.8.8.8/53' - use it only if reachable; otherwise switch to CN public DNS.
6. Intranet domains: when the container fails to resolve company/campus intranet domains, add the intranet DNS (or VPN-assigned DNS) to --dns, alongside public DNS if needed.

Related canonicals

Read in order: precondition -> same root / same domain / related:

• Only one specific website won't open (layer diagnosis) (adjacent: single-domain failures, same layering approach)
• Precondition (rule out first):
• Cannot connect to the Docker daemon (precondition: container runs = daemon OK)

• Same root:
• docker pull fails / mirror (same root: no such host is DNS-layer, host vs container)