🚨 Kubernetes Error Guide: 'lookup <svc>.svc.cluster.local: no such host' DNS NXDOMAIN

Exact Error Message

An application cannot resolve a Service name and fails with a DNS NXDOMAIN, usually naming the cluster DNS server at 10.96.0.10:53:

Error: dial tcp: lookup payments.prod.svc.cluster.local on 10.96.0.10:53: no such host

Get "http://payments:8080/health": dial tcp: lookup payments on 10.96.0.10:53: no such host

no such host is the Go runtime’s rendering of a DNS NXDOMAIN (or an empty answer): the resolver asked CoreDNS at the cluster DNS ClusterIP and was told the name does not exist. The 10.96.0.10:53 is the cluster DNS Service the pod is querying.

What the Error Means

Pods resolve names through /etc/resolv.conf, which points at the cluster DNS Service (commonly 10.96.0.10, the kube-dns Service in front of CoreDNS). CoreDNS answers cluster names from the Kubernetes API: a Service payments in namespace prod is resolvable as payments.prod.svc.cluster.local. no such host means CoreDNS returned NXDOMAIN — the queried name does not map to any record.

This is a name resolution failure, strictly before any TCP connection. The cause is almost always one of: the name is wrong (typo, wrong namespace), the Service does not exist, ndots/search domain expansion produced a name CoreDNS rejected, or CoreDNS itself is unhealthy and returning errors. Because resolution happens first, fixing connectivity (firewalls, policies) will not help until the name resolves.

Common Causes

• Service name or namespace typo — payments vs payment, or querying from the wrong namespace without the .ns qualifier.
• Cross-namespace short name — using a bare Service name for a Service in another namespace; the short name only resolves within the same namespace.
• Service does not exist (yet) — the Service was never created, was deleted, or the app starts before it exists.
• ndots / search domain surprises — a name with few dots gets the search list appended, and the FQDN form fails while the short form would have worked (or vice versa).
• CoreDNS unhealthy or overloaded — CoreDNS pods are crash-looping, NXDOMAIN-ing everything, or rate-limited.
• Wrong cluster domain — the pod expects cluster.local but the cluster uses a custom domain, so FQDNs never match.
• NodeLocal DNSCache / upstream issues — a broken local DNS cache or upstream forwarder returns failures.

How to Reproduce the Error

Query a Service in another namespace using only its short name:

# 'payments' lives in namespace 'prod', but we query from 'default'
kubectl run dnstest --image=nicolaka/netshoot --rm -it --restart=Never -- \
  nslookup payments

Server:   10.96.0.10
Address:  10.96.0.10#53
** server can't find payments: NXDOMAIN

Adding the namespace (payments.prod or the full payments.prod.svc.cluster.local) resolves it.

Diagnostic Commands

# Confirm the Service actually exists in the namespace you expect
kubectl get svc -n <NS> <SERVICE>

# What does the pod's resolver config look like? (ndots + search list)
kubectl exec <POD> -- cat /etc/resolv.conf

# Resolve short, namespaced, and fully-qualified forms to isolate the issue
kubectl run dnstest --image=nicolaka/netshoot --rm -it --restart=Never -- sh -c '
  nslookup <SERVICE>;
  nslookup <SERVICE>.<NS>;
  nslookup <SERVICE>.<NS>.svc.cluster.local'

# Is CoreDNS healthy?
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50

# Confirm the cluster DNS ClusterIP matches resolv.conf
kubectl get svc -n kube-system kube-dns

Resolving the short vs. fully-qualified forms separately is the fastest way to tell a naming/search-domain problem from a CoreDNS outage.

Step-by-Step Resolution

1. Verify the Service exists and its namespace. kubectl get svc -n <NS> <SERVICE> must return the Service. A typo in the name or the wrong namespace is the single most common cause of NXDOMAIN.

2. Use the right name form for cross-namespace calls. A bare short name only resolves to a Service in the same namespace. To reach another namespace, use service.namespace or the FQDN service.namespace.svc.cluster.local. Update the app config or the calling code accordingly.

3. Understand ndots and the search list. Pod resolv.conf defaults to ndots:5 with a search list like <ns>.svc.cluster.local svc.cluster.local cluster.local. Names with fewer than 5 dots are tried with each search suffix first. If your FQDN ends in a trailing dot or doesn’t match cluster.local, expansion can produce NXDOMAIN. Test the explicit FQDN to confirm.

4. Check CoreDNS health. If even valid FQDNs NXDOMAIN, look at CoreDNS. Crash-looping or erroring CoreDNS pods break resolution cluster-wide. Confirm the pods are Running, ready, and their logs are clean (no plugin/errors floods or upstream failures).

5. Confirm the cluster domain. If the cluster uses a custom domain instead of cluster.local, FQDNs hard-coded as cluster.local will never resolve. Match names to the actual cluster domain (visible in resolv.conf’s search list).

6. Re-test after the fix. A correct, resolvable name returns an address instead of NXDOMAIN:

kubectl run dnstest --image=nicolaka/netshoot --rm -it --restart=Never -- \
  nslookup <SERVICE>.<NS>.svc.cluster.local

Prevention and Best Practices

• Prefer fully-qualified Service names (svc.ns.svc.cluster.local) for cross-namespace calls to avoid search-domain surprises.
• Use FQDNs with a trailing dot for external hostnames in high-QPS apps to skip the search list and reduce DNS load.
• Add readiness gating or retries so apps tolerate a Service that appears slightly after they start.
• Monitor CoreDNS pod health, latency, and NXDOMAIN/SERVFAIL rates as core cluster signals.
• Keep ndots defaults unless you have a measured reason to change them; lowering it can break short-name resolution. More in the Kubernetes & Helm guides.

Related Errors

• no endpoints available for service — the name resolves but the Service has no ready backends.
• dial tcp i/o timeout — resolution succeeded but the TCP connection is dropped.
• dial tcp connect: no route to host — the address resolves but is unreachable.
• connection to the server was refused — an active rejection after the name resolves.

Frequently Asked Questions

Does no such host mean CoreDNS is down? Not necessarily. It means CoreDNS returned NXDOMAIN — the name doesn’t exist. That is usually a typo, wrong namespace, or short-name-across-namespaces issue. If CoreDNS were down you’d more often see timeouts or SERVFAIL, not a clean NXDOMAIN. Check that the Service exists before blaming DNS.

Why does the short name work in one namespace but not another? Short names rely on the search list, which puts the pod’s own namespace first. A bare name resolves to a Service in the pod’s namespace; to reach another namespace you must qualify it with .namespace or use the FQDN.

What is ndots:5 doing to my queries? With ndots:5, any name containing fewer than 5 dots is first tried with each search suffix appended before being tried as-is. This makes short names resolve conveniently but adds extra queries; appending a trailing dot forces the name to be treated as absolute.

My FQDN ends in cluster.local but still NXDOMAINs. Why? Either the Service/namespace doesn’t exist, or your cluster uses a different cluster domain than cluster.local. Confirm the actual domain from /etc/resolv.conf and that kubectl get svc -n <ns> returns the Service.

Could a NetworkPolicy cause this? A policy blocking egress to kube-dns would typically cause DNS timeouts, not NXDOMAIN. no such host specifically means a negative answer was received, so resolution reached CoreDNS — the name simply did not resolve.