> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](/support/networking/articles/how-do-i-forward-dns-to-private-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. ```text theme={"system"} 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. ```bash theme={"system"} # 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 ``` ```bash theme={"system"} # Resolve an external name to confirm upstream forwarding works. # Safe to run anytime; read-only. kubectl exec [POD-NAME] -n [NAMESPACE] -- nslookup example.com ``` ```bash theme={"system"} # 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. ```bash theme={"system"} # 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](/products/networking/cilium-network-policy-cks-patterns#target-node-local-dns-for-dns-egress-not-kube-dns). * **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. ```yaml theme={"system"} # 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: ```bash theme={"system"} # 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](/support/networking/articles/why-cant-my-pod-reach-a-service). * 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](/support/networking/articles/how-do-i-forward-dns-to-private-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](/support/networking) for related symptoms. [Server Errors](/support/networking/tags/server-errors)