Skip to content
Latchkey

Kubernetes DNS "no servers could be reached" / SERVFAIL - Fix In-Cluster DNS in CI

Pods resolve Service names through CoreDNS at the cluster DNS IP. When lookups fail - no servers could be reached, SERVFAIL, or Temporary failure in name resolution - CoreDNS is unhealthy, traffic to it is blocked, or resolver config is wrong. Transient CoreDNS blips often clear on retry.

What this error means

An app or test fails to resolve *.svc.cluster.local (or external hosts) with no servers could be reached / SERVFAIL, while pod-to-pod by IP works. It can be intermittent when CoreDNS is overloaded or restarting.

pod shell
$ nslookup api.prod.svc.cluster.local
;; connection timed out; no servers could be reached
# or from the app:
Error: getaddrinfo EAI_AGAIN api.prod.svc.cluster.local

Common causes

CoreDNS unhealthy or overloaded

CoreDNS pods crashing, OOMKilled, or saturated cause lookups to time out or SERVFAIL. A transient restart produces intermittent failures that recover on their own.

Traffic to DNS blocked

A NetworkPolicy or firewall dropping UDP/TCP 53 to kube-dns means queries never reach CoreDNS, surfacing as "no servers could be reached".

Resolver/ndots misconfiguration

A wrong cluster DNS IP in the pod resolv.conf, or a high ndots causing many search-domain permutations, makes lookups slow or fail under load.

How to fix it

Check CoreDNS health and DNS reachability

Terminal
kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n kube-system logs -l k8s-app=kube-dns --tail=50
kubectl run dnstest --rm -it --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default

Restore DNS, then let transient blips retry

  1. If CoreDNS is crashing/OOM, fix its resources/config so it is healthy.
  2. If a NetworkPolicy blocks 53, allow egress to kube-dns explicitly.
  3. For a brief CoreDNS restart, a retry/backoff in the client clears the transient failure.

How to prevent it

  • Run CoreDNS with adequate resources/replicas and monitor its health.
  • Allow DNS egress (UDP/TCP 53) whenever you apply default-deny NetworkPolicies.
  • Keep cluster DNS config (resolv.conf, ndots) correct on nodes/pods.

Frequently asked questions

What causes "DNS "no servers could be reached""?
CoreDNS pods crashing, OOMKilled, or saturated cause lookups to time out or SERVFAIL. A transient restart produces intermittent failures that recover on their own.
How do I fix DNS "no servers could be reached"?
Check CoreDNS health and DNS reachability
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card