🚨 Linux Error: Temporary failure in name resolution — Cause, Fix, and Troubleshooting Guide

Summary

Temporary failure in name resolution is the glibc resolver’s EAI_AGAIN — the system tried to turn a hostname into an IP and the DNS lookup did not complete. It is a resolver/DNS problem, not a routing problem: the host either has no nameserver configured, cannot reach the one it has, or is running a broken local stub resolver. The word “temporary” is misleading; the failure usually persists until you fix DNS.

Common Symptoms

• apt update, curl, git, ping <hostname> all fail while ping 8.8.8.8 (a raw IP) succeeds.
• The error appears for every hostname, not just one domain.
• It starts after a network change, a VPN connect/disconnect, a container start, or a systemd-resolved restart.
• sudo prints a lag/warning because it cannot resolve the host’s own name.

Most Likely Causes of the ‘Temporary failure in name resolution’ Error

1. Empty or wrong /etc/resolv.conf — no nameserver line, or it points at an unreachable resolver.
2. systemd-resolved stopped or misconfigured — the 127.0.0.53 stub listener is down, so every lookup times out.
3. /etc/resolv.conf is a dangling symlink — on Ubuntu it should point into /run/systemd/resolve/; if that target is missing, there are zero usable nameservers.
4. Upstream DNS server is down or blocked — the configured resolver (router, corporate DNS) is unreachable or filtering.
5. Broken container/VM DNS — the container inherited a 127.0.0.53 resolv.conf from the host that does not exist inside the namespace.
6. Firewall dropping UDP/TCP 53 — outbound DNS is blocked by an egress rule.

Quick Triage

# Does raw IP work but names fail? -> confirms DNS, not connectivity
ping -c1 1.1.1.1
ping -c1 github.com

# What nameservers are actually in use?
cat /etc/resolv.conf

# Can we resolve at all, bypassing the app?
getent hosts github.com

Diagnostic Commands

# NSS-level resolution (honours /etc/nsswitch.conf, same path apps use)
getent hosts github.com

# Direct DNS query against the configured resolver, then a known-good one
dig github.com
dig @1.1.1.1 github.com +short
nslookup github.com          # if bind-utils/dnsutils installed

# What the resolver stack believes it should use
cat /etc/resolv.conf
resolvectl status            # per-link DNS servers (systemd-resolved)

# Is the stub resolver actually running and listening on 127.0.0.53?
systemctl status systemd-resolved
ss -tulpn | grep ':53'

# Can we even reach an upstream DNS server on port 53?
nc -vz 1.1.1.1 53

# Full request trace including the resolution phase
curl -v https://github.com

# Resolver logs (SERVFAIL, timeouts, upstream failures)
journalctl -u systemd-resolved --since "10 min ago"

If getent hosts fails but dig @1.1.1.1 succeeds, the problem is your local resolver config, not upstream DNS.

Fix / Remediation

1. Restart the stub resolver (Ubuntu/Debian with systemd-resolved):

   sudo systemctl restart systemd-resolved
   resolvectl status
   getent hosts github.com

2. Repair the /etc/resolv.conf symlink (Ubuntu):

   ls -l /etc/resolv.conf   # expect -> ../run/systemd/resolve/stub-resolv.conf
   sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

3. Set DNS servers on the link via systemd-resolved (persistent):

   sudo resolvectl dns <IFACE> 1.1.1.1 8.8.8.8
   # or edit /etc/systemd/resolved.conf: DNS=1.1.1.1 8.8.8.8  then restart

   On NetworkManager hosts (many RHEL/Rocky desktops), set DNS on the connection instead:

   sudo nmcli con mod "<CONN>" ipv4.dns "1.1.1.1 8.8.8.8"
   sudo nmcli con up "<CONN>"

   Warning: Directly editing /etc/resolv.conf on a systemd-resolved or NetworkManager host is overwritten on the next network event. Use resolvectl/nmcli so the change survives reboots and DHCP renewals.

4. RHEL/Rocky without systemd-resolved — /etc/resolv.conf is a real file (often managed by NetworkManager). Add nameservers:

   printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' | sudo tee /etc/resolv.conf

5. Containers — set DNS at the container/orchestrator level (docker run --dns 1.1.1.1, or dnsConfig in Kubernetes) rather than editing inside the container.

Validation

getent hosts github.com      # returns an IP
dig github.com +short        # returns answers
curl -sSI https://github.com | head -1
resolvectl status | grep -A2 'Current DNS Server'

All four should succeed with no “Temporary failure” message.

Prevention

• Manage DNS through resolvectl/nmcli, never by hand-editing /etc/resolv.conf on managed hosts.
• Configure at least two upstream nameservers so one outage does not break resolution.
• Alert on the systemd-resolved unit state and on synthetic getent hosts checks from monitoring.
• Give applications sane DNS timeouts and retries (options timeout:2 attempts:2 in resolv.conf) so a slow resolver degrades gracefully instead of hanging.
• For containers, pin explicit DNS in the runtime config and validate resolution in CI images.

Related Errors

• Name or service not known
• curl: (6) Could not resolve host
• sudo: unable to resolve host
• Docker: Temporary failure in name resolution
• Connection timed out

Final Notes

Treat Temporary failure in name resolution as “DNS is broken” until proven otherwise: confirm raw IPs work, then walk the stack from getent to the stub resolver to upstream dig. On modern Ubuntu the fix is almost always in systemd-resolved or the resolv.conf symlink; on RHEL it is usually NetworkManager or the resolv.conf file itself.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.