ndots:5 slow DNS: Every external lookup tries several cluster suffixes before succeeding

A pod's resolver is configured with ndots:5, so any name with fewer than five dots is tried against the cluster search domains first. For external hostnames that means several wasted queries per lookup.

Applies to: All Kubernetes versions

What it means

Kubernetes writes /etc/resolv.conf in each pod with a search list of cluster suffixes and options ndots:5. The ndots value means: if the queried name contains fewer than five dots, treat it as relative and try each search domain before trying it as absolute. This exists so that my-service and my-service.other-ns resolve conveniently. The cost lands on external names — api.example.com has two dots, so the resolver first asks for api.example.com.default.svc.cluster.local, then two or three more variants, each returning NXDOMAIN, before finally asking for the name itself. On a busy service this multiplies DNS load several-fold and adds latency to every outbound connection.

Most common causes

• The default ndots:5 combined with an application that makes frequent external calls.
• A hostname written without a trailing dot, so it is treated as relative.
• Connection pooling that is disabled or ineffective, so each request resolves again.
• A large search list, which multiplies the number of failed queries per lookup.
• CoreDNS under load, where the extra queries are the load.

How to diagnose it

1. Read the pod's resolver config: kubectl exec POD -- cat /etc/resolv.conf and note ndots and the search list.
2. Count the queries a single lookup generates by watching CoreDNS logs with query logging enabled.
3. Compare latency for a fully qualified name with a trailing dot against the same name without: time nslookup api.example.com. versus time nslookup api.example.com.
4. Check CoreDNS query volume against the number of requests the application actually makes — a large multiple confirms it.

How to fix it

1. Use fully qualified names with a trailing dot for external hosts, which bypasses the search list entirely.
2. Set dnsConfig.options with a lower ndots value on pods that mostly talk to external services. Lowering it cluster-wide breaks bare Service names, so it belongs on specific workloads.
3. Enable NodeLocal DNSCache so the extra queries are answered locally rather than crossing the network.
4. Reuse connections in the application so lookups happen less often.

Notes

This is not an error and produces no failure message — it shows up as latency and as DNS query volume several times higher than expected. It is worth knowing about before it is diagnosed as a CoreDNS capacity problem, because adding replicas treats the symptom.

Related

• DNS timeout — Cluster DNS did not answer
• no such host — DNS answered that the name does not exist

Sources

• Kubernetes documentation — DNS for Services and Pods: pod DNS config
• Kubernetes documentation — Debugging DNS Resolution