Self-Healing CI: Handling DNS Resolution Failures
A hostname that fails to resolve once almost always resolves on the next attempt - DNS hiccupped, the name and the network are fine.
The problem
A step that reaches a hostname fails with could not resolve host or Temporary failure in name resolution. The URL is correct and the service is up; a human re-runs the job and the lookup succeeds with no change.
curl: (6) Could not resolve host: registry.example.com
# or
getaddrinfo EAI_AGAIN registry.example.com ... Temporary failure in name resolutionWhy it happens
DNS lookups depend on a resolver that can be briefly overloaded, rate-limited, or slow to respond. A single failed query surfaces as an unresolvable host even though the record is valid and the next query succeeds.
Fresh CI runners start with cold DNS caches and may hammer the resolver early in a job, making transient EAI_AGAIN/SERVFAIL responses more likely at startup than anything in your code suggests.
The manual fix
Manual handling for DNS blips:
- Re-run the job so the lookup is retried against a warmed resolver.
- Wrap network calls in retry-with-backoff so a single failed lookup does not fail the step.
- Configure a reliable resolver or local DNS cache on the runner to reduce repeat lookups.
How this gets automated
A name-resolution failure has a clear, detectable signature and a safe default response: wait briefly and retry the lookup. A self-healing CI pipeline detects the DNS error, retries the step with backoff, and only escalates if the name stays unresolvable across attempts - which is the real signal of a misconfiguration rather than a blip.