Docker Container Unable to Resolve External Domain Names (DNS Failure)
A container that can reach the internet by IP but fails to resolve external domain names points specifically at DNS configuration inside the container — Docker's default DNS setup usually works fine, but several common host environment factors can break it specifically for containers while leaving the host machine itself completely unaffected.
The Problem
Commands inside a container that depend on DNS resolution fail:
curl https://api.example.com
curl: (6) Could not resolve host: api.example.com
ping google.com
ping: google.com: Name or service not known
The exact same domain resolves fine from the host machine directly, outside any container, which confirms the issue is specifically in how the container's own DNS resolution is configured, not a genuine network outage.
Why It Happens
Docker containers get their own DNS configuration, which doesn't automatically inherit or perfectly mirror the host's actual working DNS setup in every scenario. Common causes:
- The host is connected to a VPN that provides internal DNS servers only reachable from the host's own network namespace, and the container — existing in a separate, isolated network namespace — can't reach those same internal DNS servers, even though the host itself resolves domains fine through them
- Docker's default DNS configuration points to a public DNS server (commonly Google's 8.8.8.8) that's blocked or unreachable on certain restrictive corporate networks, even though the host's own DNS (configured differently, often to an internal corporate resolver) works fine on the same network
- The host's
/etc/resolv.confcontains a DNS server address that only makes sense in the host's own network context (like127.0.0.53, a common local systemd-resolved stub address), which Docker sometimes inherits inappropriately into the container where that address doesn't correspond to anything meaningful - A custom Docker network configuration that's missing an explicit DNS setting some container orchestration platforms otherwise handle automatically
The Fix
First, confirm the diagnosis by testing DNS resolution directly inside the container, isolating it from any other potential network issue:
docker exec -it your-container nslookup google.com
If this specifically fails while general IP-based connectivity works (test with ping 8.8.8.8 as a comparison), DNS is confirmed as the specific issue rather than a broader networking problem.
Explicitly set a known-working public DNS server for the container, overriding whatever Docker inherited by default:
docker run --dns=8.8.8.8 --dns=1.1.1.1 your-image
In Docker Compose:
services:
app:
dns:
- 8.8.8.8
- 1.1.1.1
If you're on a corporate network where public DNS servers like 8.8.8.8 are blocked, use your organization's own internal DNS server address instead, which you can typically find by checking the host's own working DNS configuration:
cat /etc/resolv.conf
# or, on systems using systemd-resolved:
resolvectl status
Use whatever DNS server address the host genuinely uses successfully (not necessarily what's literally written in /etc/resolv.conf, if that file contains a local stub address like 127.0.0.53 that doesn't directly correspond to a real, externally-reachable DNS server) as the explicit DNS setting for your containers.
For Docker Desktop specifically on macOS or Windows, DNS issues related to VPN connections are a known category of friction — check Docker Desktop's own network settings for VPN-specific configuration options, since some versions include specific settings intended to improve compatibility with common VPN setups.
To make a DNS fix apply consistently across every container without needing to configure it individually each time, set it at the Docker daemon level instead:
# /etc/docker/daemon.json
{
"dns": ["8.8.8.8", "1.1.1.1"]
}
sudo systemctl restart docker
Still Not Working?
If explicit DNS servers are configured correctly but resolution still fails intermittently rather than consistently, check whether the issue is actually a firewall or security group blocking outbound DNS traffic (typically UDP port 53) specifically from the Docker network's IP range, distinct from the host's own IP — some network security configurations apply different rules based on source IP ranges, and a container's IP (usually in Docker's private bridge network range) can be treated differently by network-level firewall rules than the host machine's own IP address, even though both are ultimately the same physical machine from a purely physical networking perspective.