Fix: Temporary failure in name resolution

“Temporary failure in name resolution” is the glibc error (EAI_AGAIN from getaddrinfo) for a host that could not get any answer from its DNS resolvers. Every outbound connection by name fails at once: package installs, API calls, database hostnames, all of it. Unlike NXDOMAIN, nothing answered “no”; nothing usable answered at all. The problem is on the machine or the network path to its resolver, not in your DNS zone.

Temporary failure in name resolution

What this error means

When a program resolves a hostname, the resolver library reads /etc/resolv.conf (or asks systemd-resolved through its stub at 127.0.0.53), then sends queries to the listed nameservers. If every attempt times out or is rejected, the lookup fails with this error. The chain has a small number of links, and one of them is broken: the resolv.conf configuration, the local stub resolver daemon, the network route to the resolver, or the resolver itself.

Because DNS sits under everything, the symptom shows up as dozens of unrelated failures (apt, curl, application logs) that all reduce to this one line. Fix the resolution path and they all clear together.

Common causes

• /etc/resolv.conf is empty, missing, or a symlink pointing at a target that does not exist.
• systemd-resolved is stopped or crashed while resolv.conf still points at its 127.0.0.53 stub.
• The network is down or degraded: no default route, a detached interface, or DHCP failed to deliver nameservers.
• A firewall or security group blocks outbound UDP/TCP port 53, common after a security tightening pass.
• Inside a container: resolv.conf inherited a loopback resolver that does not exist in the container’s namespace.
• The upstream resolver itself is down, overloaded, or rate limiting (VPC resolver limits, a dead dnsmasq forwarder).
• VPN or overlay networking replaced the resolver config and did not restore it.

How to fix it

STABILIZE first. Point the host at a known-good public resolver so services can resolve again while you find the real break. This is a temporary measure, not the fix.

printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\n" > /etc/resolv.conf

1. Establish whether basic IP connectivity works at all, separating a DNS problem from a network problem:

ping -c 2 1.1.1.1
ip route show default

2. Inspect the resolver configuration and test the configured resolver and a public one directly:

cat /etc/resolv.conf
resolvectl status
dig example.com @1.1.1.1 +time=3 +tries=1
dig example.com +time=3 +tries=1

DIAGNOSE with those results. Ping to 1.1.1.1 fails: this is a network outage (route, interface, gateway), not DNS, so fix connectivity first. Ping works and dig @1.1.1.1 works but plain dig fails: the configured resolver is the broken link; look at what resolv.conf points to. If it points at 127.0.0.53, check systemd-resolved:

systemctl status systemd-resolved
journalctl -u systemd-resolved --since -1h --no-pager | tail -20

If even dig @1.1.1.1 times out while ping succeeds, port 53 is being blocked; check host firewall rules and the cloud security group or NACL for outbound UDP and TCP 53.

FIX the identified link. A stopped stub resolver:

systemctl restart systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

A wrong or empty resolv.conf on a systemd-resolved machine should be a symlink to the stub file as above, so the daemon manages it. On cloud VMs, prefer the VPC resolver your platform provides (for example 169.254.169.253 on AWS) over public DNS, since it serves private zones too. For containers, pass explicit DNS to the runtime rather than baking resolv.conf into images:

docker run --dns 1.1.1.1 --dns 8.8.8.8 myimage

Once the real fix is in, remove the hand-edited stabilization resolv.conf so the next DHCP lease or resolved restart does not fight your edit.

How to prevent it

• Monitor DNS resolution from each host or cluster as its own health check, separate from HTTP checks.
• Manage resolv.conf through one owner (systemd-resolved, netplan, or your config management), never by hand edits that other tools overwrite.
• Run a local caching resolver on busy hosts to cut UDP query volume and ride out short upstream blips.
• When tightening firewalls, include outbound port 53 (UDP and TCP) in the review checklist before rollout.
• In containers, set DNS at the runtime or orchestrator level and verify resolution in the image’s health check.

When to call a senior engineer

Call for help when resolution fails intermittently under load (conntrack exhaustion, resolver capacity, and cloud rate limits need real measurement), when Kubernetes cluster DNS degrades and every service feels flaky at once, or when split-horizon and VPN resolver setups keep overwriting each other. Erzon engineers can instrument the query path with packet captures, find the exact drop point, and design a resolver layout with caching and failover so a single DNS hiccup stops taking your platform down.