curl: (6) high
curl: (6) Could Not Resolve Host / Temporary Failure in Name Resolution
curl, wget, or a cron job can’t turn a hostname into an IP because the box has no working DNS resolver.
What you see
curl: (6) Could not resolve host: api.example.com curl: (6) Could not resolve host: example.com Temporary failure in name resolution
What’s actually happening
A command or script that hits a URL dies instantly with curl: (6), or Python/wget reports “Temporary failure in name resolution.” It usually fails the same way for every external host but works for raw IPs, which tells you DNS is the broken layer, not the network. Cron jobs are a common victim — they run with a stripped environment and sometimes a different resolver path than your interactive shell.
Common causes
- /etc/resolv.conf is empty, missing, or lists a nameserver that’s unreachable (common inside containers and minimal VMs).
- Outbound UDP/TCP port 53 is blocked by a firewall, security group, or network policy, so queries leave but answers never return.
- A typo or trailing space in the hostname, or a variable that expanded to an empty/garbled string in a script.
- The upstream resolver (or systemd-resolved / dnsmasq on the box) is down or having a transient outage.
- In Docker/Kubernetes, the container’s DNS config or the cluster DNS service (CoreDNS) is misconfigured or not running.
How to fix it
- Prove it’s DNS and not the networkTry the host by IP: curl https://93.184.216.34 -H 'Host: example.com'. If that connects but the name fails, it’s resolution. Then run dig example.com or nslookup example.com — “connection timed out; no servers could be reached” points straight at resolv.conf or a blocked port 53.
- Check and repair /etc/resolv.confcat /etc/resolv.conf. If there’s no nameserver line, add a known-good one, e.g. nameserver 1.1.1.1 or nameserver 8.8.8.8. On systems running systemd-resolved the file is a symlink — fix it via netplan/NetworkManager, or restart with systemctl restart systemd-resolved, instead of hand-editing a managed file.
- Confirm port 53 egressTest the resolver directly: dig @8.8.8.8 example.com. If a specific public resolver works but the default one doesn’t, your configured nameserver is the problem. If nothing resolves and connections time out, port 53 is firewalled — open it in the security group / iptables, or point at an allowed internal resolver.
- Sanity-check the hostname in scriptsEcho the exact URL the script builds (printf '%s\n' "$URL"). A trailing newline, space, or unset variable produces “could not resolve host” for a name that looks correct. Quote variables and validate input before the curl call.
- Fix container/cron environmentIn Docker, pass --dns 8.8.8.8 or set dns in daemon.json; in Kubernetes, check CoreDNS pods are Running and the pod’s /etc/resolv.conf points at the cluster DNS IP. For cron, source the right environment or use FQDNs, since cron’s PATH/resolver context differs from your login shell.
Stop it recurring
Add a startup health check (dig +short your-critical-host) so a broken resolver is caught before the job that depends on it runs.
Related errors