Every name lookup on a Linux server pauses for roughly five seconds and then succeeds. The network is otherwise healthy and the returned addresses are correct. What is the host doing, and what would you change?

## Read the number first A distinctive, repeatable delay is a configuration default announcing itself. Five seconds is `RES_TIMEOUT`, the glibc resolver's default per-query wait, changeable with `options timeout:N` in `/etc/resolv.conf`. Roughly five seconds followed by a *correct* answer therefore means: a query was sent, no reply arrived, the resolver waited out its timeout, and a retry succeeded. Nothing is wrong with the data; something is swallowing one query. That framing matters, because the instinctive reading — "DNS is slow" — sends people to the nameserver's own metrics, which will look perfectly healthy since it answered every query it received. ## Cause one: a dead first nameserver The resolver walks the `nameserver` list in order. If the first entry is powered off, firewalled, or listening but silently dropping UDP port 53, there is no error to detect — only silence — so the resolver must wait the timeout before trying the next entry. Because it keeps no state about server health, **every lookup pays that penalty again**. A server that actively refuses is much less painful: an ICMP port-unreachable, or a TCP reset, lets the resolver move on immediately. The pathological case is precisely the one that produces *no* response. The fix is to remove or repair the entry. `options timeout:1 attempts:2` bounds the damage and is a reasonable stopgap, but it is a smaller wound, not a cure, and shortening the timeout too aggressively can cause spurious failures on a genuinely slow-but-working link. ## Cause two: the A and AAAA pair `getaddrinfo()` asks for both address families by default, and glibc sends the A and AAAA queries back to back, in parallel, from the same source port. That is a performance optimisation with a well-known failure mode: some resolvers and middleboxes handle only the first query, or cannot cope with two outstanding queries on one socket, and one of the two replies never arrives. The resolver has an answer for one family and waits out the full timeout for the other, then retries. The distinguishing symptom is that a lookup restricted to a single family returns instantly while the normal dual lookup stalls. `/etc/resolv.conf` offers three relevant switches: - `single-request` — send the two queries sequentially instead of in parallel. - `single-request-reopen` — keep them parallel but use a fresh socket for the second query, which is the usual remedy when a middlebox is confused by two replies to one port. - `no-aaaa` — suppress AAAA queries altogether (glibc 2.36 and later); appropriate only on a host with no IPv6 connectivity at all. ## Isolate before you tune Establish which resolver is actually in front of you. If `/etc/resolv.conf` points at a loopback stub, you are timing that daemon's retry behaviour rather than glibc's, and its timeouts differ; query the upstream servers directly to separate the two. Then compare paths: ```bash time getent ahosts app.example.com >/dev/null time dig +short @10.0.0.53 app.example.com ``` If the direct query to each configured server is fast but the NSS path is slow, the delay is in the resolver's walk, not in any server. If the first configured server is the slow one and the second is fast, you have cause one. If single-family queries are fast and the dual-family path stalls, you have cause two. ## Why it hurts more than it looks A five-second resolution delay rarely stays a five-second delay. Request handlers hold threads or connections while blocked, so a per-lookup stall becomes queue growth, then pool exhaustion, then timeouts several layers up — and the failures surface as symptoms in services that never mention DNS. Meanwhile short-lived processes that resolve once at start-up pay it on every invocation. This is also why a local caching resolver is a genuine architectural improvement rather than a convenience: it collapses repeated lookups into cache hits and puts the retry policy in one component you can observe, instead of leaving every process to rediscover a dead server through a timeout.