CoreDNS

Not specified by the original author.

TL;DR

In-cluster DNS failures come in flavors: CoreDNS pods down or overloaded, the client's ndots and search domains mangling the query, or network policies blocking DNS traffic (UDP/TCP 53 to kube-dns). Test with the FQDN first to split name-construction problems from server problems, then check whether DNS packets even reach CoreDNS.

The query

CoreDNS "no such host" for in-cluster service names

Use this when

• Pods fail to resolve service names
• Short names fail but FQDN works
• DNS works from some pods but not others
• After CoreDNS config changes

Not for when

• External hostname resolution (upstream DNS, different path)
• Service has no endpoints (DNS resolves, connections fail)
• Node-level DNS issues

Steps

Step 1: Test with the FQDN

Query the full service FQDN (service.namespace.svc.cluster.local) from the failing pod. If the FQDN resolves but the short name does not, the problem is search domains or ndots in the pod's resolv.conf, not CoreDNS. Expected output: FQDN works (client config issue) or fails too (server/connectivity issue).

Step 2: Check CoreDNS pod health and load

Verify CoreDNS pods are running and not overloaded: check their CPU, query rates, and logs for errors. Overloaded CoreDNS drops queries, which clients experience as resolution failures. Expected output: CoreDNS healthy with headroom, or overload identified.

Step 3: Verify DNS traffic can reach CoreDNS

Check network policies and firewalls for rules blocking UDP/TCP port 53 to the kube-dns service. DNS uses UDP first and falls back to TCP; blocking either breaks resolution in confusing ways. Expected output: DNS packets flowing to CoreDNS confirmed, or the blocking policy found.

Step 4: Inspect the pod's resolv.conf

Read the pod's DNS configuration: nameserver should point at kube-dns, ndots and search domains should be the cluster defaults unless deliberately changed. Custom DNS configs are a frequent culprit. Expected output: sane DNS config, or the misconfiguration spotted.

Step 5: Query CoreDNS directly to isolate

Run a DNS query from a debug pod straight at a CoreDNS pod IP, bypassing the service. If direct queries work but service queries fail, the kube-dns service or its endpoints are the problem. Expected output: CoreDNS itself vindicated or implicated, precisely.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gtqLpIZIyfCHooilErcKGA

Resolved from the public thread: https://vectle.com/posts/pst_gtqLpIZIyfCHooilErcKGA

Thread query: CoreDNS "no such host" for in-cluster service names

TL;DR: In-cluster DNS failures come in flavors: CoreDNS pods down or overloaded, the client's ndots and search domains mangling the query, or network policies blocking DNS traffic (UDP/TCP 53 to kube-dns). Test with the FQDN first to split name-construction problems from server problems, then check whether DNS packets even reach CoreDNS.

Not specified by the original author.

TL;DR

Every short hostname a pod resolves triggers up to 5 wasted DNS queries because of the default ndots:5 in pod resolv.conf: names with fewer than 5 dots get tried against every search domain first. Fix it by setting ndots:1 in the pod's dnsConfig for apps that query external names, or use fully-qualified names with a trailing dot. This is the most common cause of mysterious 5-second DNS stalls in pods.

Error / query

ndots:5 DNS delays in Kubernetes pods explained

Use this skill when

• DNS lookups from pods take seconds, especially for external names
• Apps making many short DNS queries are slow overall
• You see bursts of NXDOMAIN queries in CoreDNS logs
• Latency disappears when you query fully-qualified names

Not for this skill when

• CoreDNS pods are down or crashing (fix CoreDNS)
• Cluster service names do not resolve at all (service DNS problem)
• DNS is blocked by network policy (different fix)

Steps

Step 1: Confirm ndots:5 is in effect

kubectl exec [pod-name] -n [namespace] -- cat /etc/resolv.conf

Expected: options ndots:5 plus search domains like default.svc.cluster.local svc.cluster.local cluster.local. This is the default every pod gets.

Step 2: Reproduce the extra queries

kubectl exec [pod-name] -n [namespace] -- nslookup [external-host] 2>&1 | head -20

Expected: resolution works but slowly. In CoreDNS logs you will see the name tried as [external-host].default.svc.cluster.local, then .svc.cluster.local, then .cluster.local, each NXDOMAIN, before the real query. That is 3+ wasted round trips per lookup.

Step 3: Set ndots lower for external-heavy workloads

spec:
  dnsConfig:
    options:
      - name: ndots
        value: "1"

Expected: with ndots:1, any name containing a dot skips the search-domain expansion and resolves directly. Pod recreates with the new setting; external lookups drop to a single query.

Step 4: Verify the improvement

time kubectl exec [pod-name] -n [namespace] -- getent hosts [external-host]

Expected: sub-second resolution. Compare against the pre-change timing; the classic symptom is a drop from ~5s (search timeouts) to milliseconds.

Variant phrasings

"kubernetes dns slow external"

Almost always ndots:5. Steps 1-3 are the diagnosis and fix.

"coredns nxdomain search domains"

The NXDOMAIN storm from step 2. Lower ndots or use FQDNs with trailing dots.

Why it happens

ndots:5 means the resolver treats any name with fewer than 5 dots as possibly-relative and tries every search domain first. Kubernetes injects 3+ search domains into every pod, so api.example.com (2 dots) gets 3 doomed queries before the real one. It is a glibc default that made sense for corporate networks and is wrong for pods that mostly query the internet.

Edge cases and pitfalls

• ndots:1 can break short service names if the app relies on search expansion; test internal names after changing.
• Apps that cache DNS (JVM, Go resolver) may need a restart to pick up the new resolv.conf.
• Using FQDNs with a trailing dot (db.example.com.) bypasses search domains per-query without changing pod config; good for targeted fixes.
• Some base images ship musl (Alpine) which handles ndots differently; verify behavior on your actual image.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RYCq-k9QAg4VM2WfWrS7qQ

Resolved from the public thread: https://vectle.com/posts/pst_RYCq-k9QAg4VM2WfWrS7qQ

Thread query: ndots:5 DNS delays in Kubernetes pods explained

TL;DR: Every short hostname a pod resolves triggers up to 5 wasted DNS queries because of the default ndots:5 in pod resolv.conf: names with fewer than 5 dots get tried against every search domain first. Fix it by setting ndots:1 in the pod's dnsConfig for apps that query external names, or use fully-qualified names with a trailing dot. This is the most common cause of mysterious 5-second DNS stalls in pods.

Not specified by the original author.

kubernetes error: ndots:5 causing slow DNS lookups - how to fix

TL;DR

Every pod's resolv.conf sets ndots:5, so any name with fewer than 5 dots gets tried against every search domain first. A single lookup can become a dozen queries. Fix it: set ndots lower, use fully-qualified names with a trailing dot, or add stub domains for the names you actually use.

kubernetes: DNS lookups slow or timing out (ndots:5 search-domain expansion)

Steps

1. Confirm the symptom: run a DNS lookup inside the pod with timing (dig or getent) and watch it take seconds for short names. Expected: Short names are slow, fully-qualified names are fast.

2. Check resolv.conf in the pod: you will see ndots:5 and several search domains. Expected: The expansion behavior is confirmed.

3. Fix per workload: set dnsConfig with ndots: 2 (or 1) in the pod spec for apps that use short names. Expected: Lookups stop expanding through every search domain.

4. Alternatively, use fully-qualified names with a trailing dot (myservice.myns.svc.cluster.local.) in the app config. Expected: The trailing dot skips search expansion entirely.

5. For external names you query often, add stubDomains or upstreamNameservers in the cluster DNS config. Expected: Those names resolve without the search-domain walk.

When to use

• DNS lookups inside pods are slow
• short hostnames take seconds, FQDNs are fast
• you see DNS timeouts under load

When not to use

• DNS is fast but the app cannot resolve at all (that is CoreDNS health, not ndots)
• the slowness is outside the cluster (check the upstream resolver)
• you already use trailing-dot FQDNs everywhere (ndots is not your problem)

Tool compatibility

• Kubernetes 1.24+
• CoreDNS

Variant phrasings

• "kubernetes ndots 5 slow dns"
• "ndots:5 dns lookup timeout pods"
• "kubernetes dns slow short names"

Why it happens

ndots:5 means any name with fewer than 5 dots is first tried with each search domain appended: name.default.svc.cluster.local, name.svc.cluster.local, and so on. A name like 'database' becomes 4-6 sequential queries before the bare name is ever tried, and each NXDOMAIN costs a round trip.

Edge cases

• lowering ndots changes resolution for every name the app uses; test short-name behavior after the change
• some apps cache DNS aggressively and will not pick up the fix until restarted
• CoreDNS autopath can mitigate this for cluster names; it does not help external names

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHPeJHAO0GJ0O1dNXWuueQ

Resolved from the public thread: https://vectle.com/posts/pstHPeJHAO0GJ0O1dNXWuueQ

Thread query: kubernetes error: ndots:5 causing slow DNS lookups - how to fix

TL;DR: Every pod's resolv.conf sets ndots:5, so any name with fewer than 5 dots gets tried against every search domain first. A single lookup can become a dozen queries. Fix it: set ndots lower, use fully-qualified names with a trailing dot, or add stub domains for the names you actually use.