Skip to main content
If DNS lookups from inside a pod succeed but external calls are slow, DNS itself may not be failing — the pod may simply be generating many extra DNS queries. A frequent root cause is the pod’s DNS options setting, commonly ndots:5. This article explains what ndots does, shows how it multiplies lookups, and describes practical fixes for Kubernetes pods.

​
What ndots means

The ndots option sets a threshold for how many dots must appear in a hostname before the resolver treats it as “absolute” and queries it as-is. If a name has fewer dots than the ndots value, the resolver first appends the configured search domains and tries each candidate before falling back to the original name. For example: api.github.com contains two dots. With ndots:5, 2 is less than 5, so the resolver will treat api.github.com like a short (potentially cluster-local) name and attempt the search-domain-expanded names first.
The image is a graphic explaining that a threshold of "ndots" equals 5, showing an example with "api.github.com" which has 2 dots, indicating 2 is less than 5.

​
How the resolver expands names

With ndots:5, a query for api.github.com will cause the resolver to try the search domains before the actual external name. Typical candidates (for a cluster with default search domains) are:
  • api.github.com.default.svc.cluster.local
  • api.github.com.svc.cluster.local
  • api.github.com.cluster.local
  • finally api.github.com
This sequence increases the number of queries for a single name. Example dig output for these attempts:
If the client requests both A (IPv4) and AAAA (IPv6) records, the resolver repeats the sequence for each record type, potentially doubling the number of queries. For high-volume applications, this flood of extraneous lookups can overload DNS servers such as CoreDNS.
The image is a diagram highlighting the complexity of DNS lookups for IPv4 and IPv6, showing that a single name requires 8 lookups in total.

​
Common mitigations

There are two straightforward mitigations to reduce unnecessary search-domain lookups:
  1. Use a trailing dot. Writing a fully qualified domain name (FQDN) with a trailing dot — for example, api.github.com. — tells the resolver the name is absolute and it will query that exact name immediately (no search-domain expansion).
  2. Lower ndots in the pod’s DNS configuration. Setting ndots to 1 or 2 keeps the ability to resolve short, cluster-local names while preventing most external hostnames from triggering the full search list.
The image describes two fixes related to domain name completion: adding a trailing dot and lowering ndots, with an example using "api.github.com" to illustrate.
Example pod spec that sets ndots to 2:

​
Quick comparison

Kubernetes default ndots is commonly 5 (the “ndots:5 trap”). Lowering ndots to 1 or 2 reduces wasted search-domain lookups for typical external hostnames while still allowing short cluster-local names to resolve.
Avoid globally setting ndots too low without testing: some legacy apps rely on search-domain expansion to resolve internal services. Validate behavior in a staging environment before changing production pod specs.

​
Additional resources

By understanding ndots and how search domains are applied, you can eliminate a common source of DNS-related latency inside Kubernetes pods and reduce load on your cluster DNS service.

Watch Video