> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ndots5 Trap
> Explains ndots behavior in Kubernetes pods, how ndots 5 multiplies DNS queries causing latency, and fixes like trailing dots or reducing ndots to cut unnecessary lookups.
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.
## 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:
```bash theme={null}
$ dig api.github.com.default.svc.cluster.local A +short
; <<>> DiG 9.11.3 <<>> api.github.com.default.svc.cluster.local A +short
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
$ dig api.github.com.svc.cluster.local A +short
; <<>> DiG 9.11.3 <<>> api.github.com.svc.cluster.local A +short
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12346
$ dig api.github.com.cluster.local A +short
; <<>> DiG 9.11.3 <<>> api.github.com.cluster.local A +short
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12347
$ dig api.github.com A +short
151.101.129.140
```
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.
## 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.
Example pod spec that sets `ndots` to 2:
```yaml theme={null}
spec:
dnsConfig:
options:
- name: ndots
value: "2"
```
## Quick comparison
| Strategy | When to use | Pros | Cons |
| ------------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Trailing dot (`api.github.com.`) | Quick fix in application config or callers that build hostnames | No resolver-side changes; immediate absolute lookup | Requires changing callers or libraries; easy to forget |
| Lower `ndots` (`dnsConfig: ndots: "1"` or `"2"`) | Pod-level fix for many apps in a pod | Centralized; preserves short cluster-name resolution | Needs pod spec modification or redeploy; be careful with apps relying on search domains |
| Reduce search domains | Cluster-level optimization | Fewer candidate lookups for every query | May impact resolution of legitimate short names |
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
* [CoreDNS documentation](https://coredns.io/)
* [Kubernetes DNS policy and `dnsConfig`](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
* `man resolv.conf` — explains `ndots`, `search`, and other resolver options
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.