How to Debug Kubernetes DNS Resolution Failures

DNS failures inside Kubernetes can affect only one pod, one node, internal Service names, or all external domains. The fastest diagnosis begins by defining that scope, then follows the request from the pod’s resolver configuration to the cluster DNS Service, CoreDNS, and any upstream resolver.

Reproduce the exact failure

From the affected pod, inspect its resolver configuration and query both an internal Service and an external name:

kubectl exec POD -n NAMESPACE -- cat /etc/resolv.conf
kubectl exec POD -n NAMESPACE -- nslookup kubernetes.default.svc.cluster.local
kubectl exec POD -n NAMESPACE -- nslookup example.com

If the application image has no DNS tools, create an approved temporary diagnostic pod in the same namespace:

kubectl run dns-debug --rm -it --restart=Never -n NAMESPACE \
  --image=registry.k8s.io/e2e-test-images/dnsutils:1.3 -- sh

Record whether the response is NXDOMAIN, SERVFAIL, a timeout, or connection refused. These indicate different failure layers.

Check the search path and DNS policy

Inspect the pod specification:

kubectl get pod POD -n NAMESPACE -o yaml

Review dnsPolicy, dnsConfig, hostNetwork, and /etc/resolv.conf. Most workload pods use ClusterFirst. A pod using dnsPolicy: Default inherits the node’s resolver behavior, while a hostNetwork pod commonly needs ClusterFirstWithHostNet to resolve cluster Services.

Short Service names depend on namespace search domains. Test the fully qualified name to separate a search-path problem from a DNS server failure:

SERVICE.NAMESPACE.svc.cluster.local

Inspect the cluster DNS Service

The Service is commonly named kube-dns even when CoreDNS provides the implementation:

kubectl get service kube-dns -n kube-system -o wide
kubectl get endpointslice -n kube-system \
  -l kubernetes.io/service-name=kube-dns -o wide

Confirm that the DNS server address in the pod’s /etc/resolv.conf matches the cluster DNS Service IP and that the Service has ready endpoints on UDP and TCP port 53.

Check CoreDNS pods and logs

kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=200
kubectl describe deployment coredns -n kube-system

Look for crash loops, readiness failures, denied upstream requests, forwarding loops, timeouts, and configuration parse errors. Also determine whether failures correlate with a particular CoreDNS pod or node.

Inspect the active configuration without editing it:

kubectl get configmap coredns -n kube-system -o yaml

Do not immediately restart CoreDNS or replace its ConfigMap. Preserve logs and establish whether the fault is internal records, upstream forwarding, or network reachability first.

Test DNS transport and NetworkPolicies

DNS normally uses UDP port 53 and can fall back to TCP for larger or truncated responses. Policies must allow both protocols between workload pods and cluster DNS:

kubectl get networkpolicy -A

If policy permits diagnostic traffic, query the cluster DNS IP explicitly from an affected namespace. A query to the DNS Service IP that times out while other Service traffic works narrows the issue to policy, service routing, CoreDNS endpoints, or port 53 handling.

Compare pods and nodes

Run the same queries from pods in another namespace and on another node:

kubectl get pods -A -o wide

If only pods on one node fail, inspect that node’s CNI, service routing, and resolver state. If internal names work but external names fail everywhere, focus on CoreDNS forwarding and the upstream resolver configured by CoreDNS or the nodes.

Node resolver files that point to a local stub such as 127.0.0.53 can cause forwarding problems when the kubelet passes an unsuitable resolv.conf to cluster DNS. Verify the distribution and kubelet configuration before changing it.

Diagnose it with Rumus

Diagnose Kubernetes DNS failures for this workload. Establish whether the failure
affects one pod, namespace, node, internal Services, or external names; inspect the
pod DNS policy and resolv.conf, kube-dns Service and EndpointSlices, CoreDNS health,
logs and configuration, UDP/TCP port 53 policy, node distribution, and upstream
resolvers. Start read-only and do not restart CoreDNS, edit ConfigMaps, or change
network policy without approval.

Confirm the fix

Repeat internal and external queries from the original pod and a second pod on another node:

nslookup kubernetes.default.svc.cluster.local
nslookup example.com

Confirm both UDP and TCP DNS paths work where relevant, CoreDNS remains ready, logs show no recurring timeout or forwarding errors, and application requests succeed without relying on a manually inserted IP address.