Skip to main content
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 private domains or add hostname mappings, see Configure DNS overrides on CKS instead.

​
What you are seeing

DNS problems from a Pod usually surface as one of these symptoms: 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.
  • 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. Replace [POD-NAME] and [NAMESPACE] with the failing Pod and its namespace, and [SERVICE-NAME] with the Service you’re trying to resolve:
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.

​
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.

​
Intermittent REFUSED responses after adding a DNS override

If DNS queries intermittently return REFUSED after adding a custom zone, check that every custom server block on port 53 includes bind 0.0.0.0. The managed server blocks use this directive. Mixing server blocks with and without it can create competing listeners that answer different queries. Update the override and verify DNS resolution again. Restarting Pods doesn’t correct the configuration. For the supported ConfigMap format, see Configure DNS overrides on CKS.

​
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, replace [CLIENT-DEPLOYMENT] with the affected Deployment’s name:
For a durable fix, remove the hardcoded resolver directive from the client’s configuration. A stable Service IP alone doesn’t prevent a persistent connection from retaining a stale resolver Pod mapping.

​
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 isn’t something you fix by editing the Node’s /etc/resolv.conf. The Node resolver is managed by the system and isn’t the right layer for cluster DNS changes. Use Pod dnsConfig or the node-local-dns-overrides ConfigMap.
  • 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.
Alongside the details every ticket needs, listed in Support ticket templates, 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 and Error message lookup for related symptoms. Server Errors
Last modified on October 21, 2026