no such host: A DNS lookup returned no record for the name

Errors like dial tcp: lookup my-service on 10.96.0.10:53: no such host mean cluster DNS answered and said the name does not exist. The name is usually wrong, or in a different namespace.

Applies to: All Kubernetes versions

What it means

This is an NXDOMAIN — a definitive answer that no record exists. Cluster DNS is working; it simply has nothing for that name. Kubernetes gives Services names of the form service.namespace.svc.cluster.local, and a pod's resolver is configured with a search list so that a bare service resolves within the pod's own namespace. That convenience is exactly what causes this error: a bare name that works in one namespace fails in another, because the search path expands it differently. The distinction worth holding onto is that no such host means DNS answered, whereas a timeout means it did not — completely different problems.

Most common causes

• The Service name is misspelled.
• The Service is in a different namespace and was referenced by its bare name.
• The Service was deleted or has not been created yet.
• A headless Service being queried for a ClusterIP it does not have.
• An external name that genuinely does not resolve, where the failure is outside the cluster.
• A custom dnsConfig or dnsPolicy on the pod that removed the cluster search path.

How to diagnose it

1. Confirm the Service exists and note its namespace: kubectl get svc --all-namespaces | grep NAME.
2. Resolve from inside a pod in the same namespace as the client: kubectl exec POD -- nslookup my-service, then try the fully qualified my-service.other-namespace.svc.cluster.local.
3. Read the pod's resolver configuration: kubectl exec POD -- cat /etc/resolv.conf. The search list explains what a bare name expands to.
4. Check the pod's dnsPolicy. Default inherits the node's resolver and does not resolve cluster names at all.
5. Check that CoreDNS is running: kubectl get pods -n kube-system -l k8s-app=kube-dns.

How to fix it

1. Use the fully qualified name when crossing namespaces: service.namespace.svc.cluster.local.
2. Correct the spelling, or create the Service that is missing.
3. Set dnsPolicy: ClusterFirst so cluster names resolve. This is the default and is usually only wrong when someone changed it.
4. For headless Services, query the per-pod records rather than expecting a single ClusterIP.
5. If external names fail, check the upstream resolver configured in CoreDNS rather than anything in the pod.

Notes

A bare Service name that works from one pod and fails from another is nearly always a namespace difference rather than a DNS fault. Using fully qualified names in configuration removes the ambiguity entirely, at the cost of some verbosity.

Related

• DNS timeout — Cluster DNS did not answer
• Service has no endpoints — No ready pods behind the Service

Sources

• Kubernetes documentation — DNS for Services and Pods
• Kubernetes documentation — Debugging DNS Resolution
• Kubernetes documentation — Service