Why is DNS resolution failing from my Pod?

DNS resolution fails from a Pod when the name does not exist, the wrong search domain is appended, or a resolver in the query path cannot answer. Run kubectl exec [POD-NAME] -n [NAMESPACE] -- nslookup [NAME] and read the node-local-dns logs to isolate the failing hop. Common fixes: correct the Pod’s dnsConfig or search domains, set dnsPolicy: ClusterFirstWithHostNet for host-network Pods, and allow DNS egress to node-local-dns in any NetworkPolicy. This covers DNS failures from inside a Pod on CoreWeave Kubernetes Service (CKS): names that fail to resolve, intermittent lookups, or slow resolution. It explains how DNS works on CKS, how to test resolution from a Pod, and the common pitfalls. To forward queries for your own private domains, see Forward DNS queries to your private or internal domains instead.

What you are seeing

DNS problems from a Pod usually surface as one of these symptoms:

Symptom	What it usually means
`NXDOMAIN` / `Name or service not known`	The name genuinely does not exist, or the wrong search domain is being appended.
`SERVFAIL`	A resolver was reached but failed to answer, often a misconfigured forward zone pointing at an unreachable upstream.
Intermittent failures or timeouts	A stale client connection pinned to an old resolver Pod, or a `NetworkPolicy` blocking DNS egress.
Slow resolution	Too many search-domain attempts (high `ndots`), or upstream latency for external names.

A quick discriminator: NXDOMAIN means the name was looked up and not found, while SERVFAIL means a resolver was reached but could not produce an answer. NXDOMAIN points at the name or the search path. SERVFAIL points at a broken forwarder.

How DNS works on CKS

Understanding the path tells you which component to check.

Pod /etc/resolv.conf
  -> node-local-dns (DaemonSet, link-local 169.254.0.1, label k8s-app=node-local-dns)
    -> CoreDNS (cluster DNS)
      -> upstream resolvers (for external names)

Pods with the default dnsPolicy: ClusterFirst send queries to the node-local-dns cache running on each Node at the link-local address 169.254.0.1.
node-local-dns serves cluster zones such as *.svc.cluster.local and forwards everything else. It runs as a DaemonSet in kube-system with the label k8s-app=node-local-dns, which you use as the target both for log reads and for DNS egress allow rules.

Test resolution from a Pod

Run these read-only tests from the Pod that is failing.

# Resolve a cluster-internal Service name from inside a Pod.
# Safe to run anytime; read-only.
kubectl exec [POD-NAME] -n [NAMESPACE] -- nslookup [SERVICE-NAME].[NAMESPACE].svc.cluster.local

# Resolve an external name to confirm upstream forwarding works.
# Safe to run anytime; read-only.
kubectl exec [POD-NAME] -n [NAMESPACE] -- nslookup example.com

# Inspect the Pod's resolver configuration: nameserver, search list, ndots.
# Safe to run anytime; read-only.
kubectl exec [POD-NAME] -n [NAMESPACE] -- cat /etc/resolv.conf

If nslookup is not in the image, use getent hosts [NAME] or python3 -c "import socket; print(socket.gethostbyname('[NAME]'))".

Read the node-local-dns logs

You can read the node-local-dns logs directly. They show forwarding decisions and reloads.

# Tail node-local-dns logs across the cluster.
# Safe to run anytime; read-only.
kubectl logs -n kube-system -l k8s-app=node-local-dns --tail=50

Common pitfalls

The following sections describe the most common causes of Pod DNS failures and how to address each one.

Cluster names resolve but external names do not (or the reverse)

The direction of the failure points to the cause:

External works, *.svc.cluster.local fails: the Pod’s dnsConfig may override the cluster search domains, or a NetworkPolicy is blocking egress to node-local-dns. Confirm /etc/resolv.conf lists the cluster search domains, and that any default-deny policy allows DNS egress to node-local-dns. For the exact Cilium selector, see Cilium network policy on CKS.
Cluster works, external fails: the upstream forward path is failing. Check the node-local-dns logs for forwarding errors.

hostNetwork Pods use the wrong resolver

A Pod with hostNetwork: true and the default dnsPolicy uses the Node’s resolver, not cluster DNS, so cluster names fail. Set dnsPolicy: ClusterFirstWithHostNet so a host-network Pod resolves cluster Services.

# Required for host-network Pods that must resolve cluster Services.
spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

Stale connections after node-local-dns rolls

Long-lived clients that resolve once and reuse a pinned connection can break when node-local-dns Pods roll. A common case: an application or proxy configured with a hardcoded resolver address (for example, an nginx resolver directive pointing at a Service ClusterIP) opens a single connection that the data plane maps to one resolver Pod. When that Pod rolls, the client keeps using the dead path and DNS fails permanently until the client restarts. To recover and prevent recurrence:

# Immediate recovery: restart the client workload to re-resolve.
# This restarts your own workload; safe if a brief restart is acceptable.
kubectl rollout restart deployment/[CLIENT-DEPLOYMENT] -n [NAMESPACE]

For a durable fix, remove the hardcoded resolver address or point it at a stable in-cluster upstream rather than a pinned Pod IP.

ndots and search-domain overhead

A high ndots value causes the resolver to try each search domain before a name is resolved as absolute, which adds latency and can mask the real result. If a name resolves only with a trailing dot ([NAME].), the search list is the cause. Set an explicit dnsConfig.options ndots value on the Pod, or use fully qualified names.

What this is not

The following are common misconceptions about Pod DNS failures:

This is not a Service connectivity problem. If a name resolves correctly but the connection still fails, see Troubleshoot pod-to-service connectivity.
This is not something you fix by editing the Node’s /etc/resolv.conf. The Node resolver is managed by the system and is not the right layer for cluster DNS changes. Use Pod dnsConfig, or the override ConfigMap described in Forward DNS queries to your private or internal domains.
node-local-dns is not kube-dns. Policies and references that target kube-dns do not apply on CKS.

When to open a ticket

Open a support ticket when:

node-local-dns logs show forwarding errors that you cannot tie to your own ConfigMap overrides.
DNS fails cluster-wide from multiple Nodes for names that should resolve, with no NetworkPolicy in the path.

Include the failing name, the exact error (NXDOMAIN, SERVFAIL, or timeout), the Pod’s /etc/resolv.conf, and a sample of node-local-dns logs. See Troubleshoot networking for related symptoms. Server Errors

​What you are seeing

​How DNS works on CKS

​Test resolution from a Pod

​Read the node-local-dns logs

​Common pitfalls

​Cluster names resolve but external names do not (or the reverse)

​hostNetwork Pods use the wrong resolver

​Stale connections after node-local-dns rolls

​ndots and search-domain overhead

​What this is not

​When to open a ticket