DNS timeout: Cluster DNS did not answer the query in time

A DNS lookup that times out means CoreDNS did not respond at all — as opposed to responding that the name does not exist. This is an availability or network problem, not a naming mistake.

Applies to: All Kubernetes versions

What it means

A timeout on a DNS query means no answer came back within the resolver's timeout, so the client retries and eventually fails. Unlike no such host, this says nothing about whether the name is valid. The usual causes are that CoreDNS is unhealthy or overloaded, that there are not enough replicas for the query volume, that a network policy is blocking traffic to the DNS service, or that packets are being lost between the pod and CoreDNS. Because almost every application resolves names constantly, DNS timeouts present as a broad, intermittent unreliability across unrelated services rather than as a single obvious failure — which is what makes them so disruptive to diagnose.

Most common causes

• CoreDNS pods are crash-looping, evicted, or scheduled onto an unhealthy node.
• CoreDNS is underprovisioned for the cluster's query rate and is dropping queries.
• A network policy in the pod's namespace blocking egress to kube-system on port 53.
• kube-proxy not programming the DNS Service correctly on some nodes.
• Packet loss or conntrack table exhaustion on the node.
• An upstream resolver that is slow, causing CoreDNS to hold queries for external names until they time out.

How to diagnose it

1. Check CoreDNS health and restarts: kubectl get pods -n kube-system -l k8s-app=kube-dns.
2. Read its logs for dropped or failing queries: kubectl logs -n kube-system -l k8s-app=kube-dns.
3. Test resolution from a pod on the affected node and from one on a healthy node, to see whether it is node-specific.
4. Check whether a network policy applies to the client's namespace: kubectl get networkpolicy -n NAMESPACE. A default-deny egress policy without a DNS exception is a very common cause.
5. Check conntrack usage on the node — a full table drops packets silently, and DNS is usually the first thing to suffer.
6. Separate internal from external names. If only external names time out, the problem is the upstream resolver.

How to fix it

1. Scale CoreDNS to match the cluster's query volume, and give it resource requests so it is not the first thing starved.
2. Add an explicit egress rule permitting UDP and TCP port 53 to the DNS service in every default-deny namespace.
3. Enable NodeLocal DNSCache, which puts a caching resolver on each node and removes most of this failure mode.
4. Fix the upstream resolver, or configure CoreDNS to fail fast on external lookups rather than holding them.
5. Raise the node's conntrack limits if the table is filling.

Notes

A default-deny egress NetworkPolicy that forgets DNS is one of the most common self-inflicted cluster outages, and its symptom — everything is intermittently slow — points away from the cause. Any default-deny policy needs a DNS exception written at the same time.

Related

• no such host — DNS answered that the name does not exist
• NetworkPolicy blocking traffic — A policy is dropping the connection

Sources

• Kubernetes documentation — Debugging DNS Resolution
• Kubernetes documentation — DNS for Services and Pods
• Kubernetes documentation — Network Policies