Introduction

ndots controls when the resolver treats a name as potentially absolute versus trying search domains first. Kubernetes commonly sets ndots:5, and that default is not arbitrary. It helps internal service discovery work smoothly, but it can also create extra DNS lookups for external names if you are not careful.

What ndots Actually Means

The resolver counts the dots in a hostname. If the number of dots is less than ndots, it first tries the configured search domains.

In a Kubernetes pod, /etc/resolv.conf often contains search domains such as:

• 'default.svc.cluster.local'
• 'svc.cluster.local'
• 'cluster.local'

With ndots:5, a lookup for redis is clearly treated as a relative cluster-style name, so the resolver tries the search domains and finds the in-cluster service.

Why Kubernetes Uses ndots:5

Kubernetes service names are often accessed in shortened forms:

• 'redis'
• 'redis.default'
• 'redis.default.svc'

Using a high ndots value means those names get expanded through the cluster search domains instead of being treated as absolute too early. That improves the developer experience for in-cluster service discovery.

For example, an app can connect to:

http://redis:6379

without spelling out the full cluster domain name.

The Tradeoff: Extra DNS Queries for External Hosts

The downside is that external names with fewer than five dots can trigger multiple failed search-domain expansions before the resolver finally asks for the absolute name.

A lookup for api.example.com has only two dots. With ndots:5, the resolver may try variations such as:

• 'api.example.com.default.svc.cluster.local'
• 'api.example.com.svc.cluster.local'
• 'api.example.com.cluster.local'

before finally resolving api.example.com.

That can increase:

• DNS query volume
• latency for external lookups
• load on CoreDNS

So ndots:5 is convenient for cluster-local names, but it is not always ideal for workloads that mostly call external services.

Best Practice Is Not "Always Change It"

The safest default is usually to leave the cluster-provided setting alone unless you have measured a real problem. Many workloads are perfectly fine with ndots:5.

You should consider tuning it only when:

• the application makes many external DNS lookups
• you see large DNS query amplification
• CoreDNS metrics or logs show avoidable search-domain traffic

Changing it blindly across the whole cluster can break expectations for service-name resolution.

Use FQDNs or Trailing Dots for External Names

A low-risk optimization is to use fully qualified external names more explicitly. In many resolver setups, adding a trailing dot marks the name as absolute.

api.example.com.

That can prevent search-domain expansion for that lookup. Whether your application stack preserves the trailing dot correctly depends on the language and library, so test it in the actual runtime.

Another approach is to use longer, fully qualified internal service names when clarity matters:

redis.default.svc.cluster.local

That reduces ambiguity, though it is more verbose.

Override DNS Options Per Pod When Needed

If a specific workload mostly talks to external systems, you can override DNS options for that pod instead of changing the whole cluster.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: external-heavy-client
5spec:
6  dnsConfig:
7    options:
8      - name: ndots
9        value: "2"
10  containers:
11    - name: app
12      image: busybox
13      command: ["sh", "-c", "sleep 3600"]

This keeps the adjustment scoped to the workloads that actually benefit from it.

Measure Before and After

The right answer is empirical. Useful signals include:

• CoreDNS request counts
• latency for external hostname resolution
• application logs showing slow outbound connections

If lowering ndots reduces query amplification without breaking internal service lookups, it can be a worthwhile targeted optimization.

Common Pitfalls

The biggest mistake is treating ndots:5 as either always correct or always wrong. It is a tradeoff. Another is changing the cluster-wide resolver behavior when only one application has an external-DNS-heavy traffic pattern. Developers also forget that many external names have fewer than five dots, so they trigger search-domain expansion. On the other side, lowering ndots too aggressively can make short in-cluster service names less convenient or behave differently than expected. The safe approach is to measure, scope changes carefully, and prefer targeted pod-level tuning over blanket changes.

Summary

• 'ndots controls when the resolver tries search domains before an absolute lookup.'
• Kubernetes commonly uses ndots:5 to support convenient in-cluster service naming.
• The tradeoff is extra DNS queries for many external hostnames.
• Do not change the setting blindly across the whole cluster.
• Use pod-level dnsConfig overrides for workloads that truly need tuning.
• Measure DNS behavior before and after any ndots change.