Introduction

When people say CoreDNS does not respect local DNS, they usually mean that names resolvable on the node itself stop resolving inside Kubernetes pods. That behavior is usually not CoreDNS ignoring you at random. It is a consequence of how pod DNS is generated, which upstream resolvers CoreDNS is told to use, and whether the node-local resolver is reachable from inside the cluster.

Understand the DNS Path in Kubernetes

Inside a Kubernetes cluster, a pod does not usually query the node resolver directly. The pod sends DNS queries to the cluster DNS service, often CoreDNS, and CoreDNS decides what to do next based on the Corefile.

A common configuration looks like this:

1.:53 {
2    errors
3    health
4    kubernetes cluster.local in-addr.arpa ip6.arpa
5    forward . /etc/resolv.conf
6    cache 30
7    loop
8    reload
9}

The key line is forward . /etc/resolv.conf. That does not mean "use whatever the pod sees in /etc/resolv.conf". It means CoreDNS reads its own resolver file inside the CoreDNS container. Depending on how the deployment is set up, that file may not contain the same servers or search domains as the host machine.

Why Node-Local DNS Often Fails

Many machines use a stub resolver on 127.0.0.1 or 127.0.0.53. That works on the host because the service is bound to the host loopback interface. But from inside a CoreDNS container, that address points to the container itself, not to the host resolver.

That leads to a confusing situation:

1. the node can resolve internal company names
2. the pod cannot resolve them
3. CoreDNS forwarding to the node loopback address fails or times out

In other words, CoreDNS is following its upstream configuration exactly, but the upstream target is unreachable from that network namespace.

Fix the Upstream Resolver Explicitly

The safest approach is to point CoreDNS at reachable upstream DNS servers instead of relying on an implicit local stub. For example:

1.:53 {
2    errors
3    health
4    kubernetes cluster.local in-addr.arpa ip6.arpa
5    forward . 10.0.0.2 10.0.0.3
6    cache 30
7    reload
8}

If your organization has internal DNS servers for private zones, forward directly to those addresses. That removes ambiguity and avoids dependence on the node's loopback resolver.

If you want pods to inherit a specific resolver file from the node, check the kubelet configuration. The resolvConf setting determines which resolver file kubelet uses when generating pod DNS settings.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
resolvConf: /run/systemd/resolve/resolv.conf

That is relevant when the default node file points at a stub resolver but another file contains the real upstream nameservers.

Verify What CoreDNS Actually Sees

Before changing anything, inspect the environment from inside the cluster rather than assuming it matches the host.

kubectl -n kube-system get configmap coredns -o yaml
kubectl -n kube-system exec deploy/coredns -- cat /etc/resolv.conf
kubectl run -it --rm dns-debug --image=busybox:1.36 --restart=Never -- nslookup example.internal

Those checks answer three different questions:

• what CoreDNS is configured to do
• what resolver file exists inside the CoreDNS container
• what a regular pod can actually resolve

You need all three when debugging.

Common Pitfalls

The most common mistake is forwarding to 127.0.0.1 or 127.0.0.53. Those addresses only make sense on the host where the stub resolver is running. Inside a container they usually point nowhere useful.

Another issue is assuming that host DNS search domains automatically appear in pods. Pod DNS settings are generated by kubelet and may be different from the host machine, especially when dnsPolicy or custom pod DNS options are involved.

It is also easy to focus only on CoreDNS and miss split-horizon DNS. An internal zone may resolve correctly only when queries go to a specific enterprise resolver. If CoreDNS forwards to a public DNS server, private records will never appear.

Finally, remember that CoreDNS handles both cluster service discovery and external forwarding. Changing the Corefile carelessly can break cluster name resolution even if you were only trying to fix an upstream DNS problem.

Summary

• CoreDNS usually serves as the pod DNS entry point, not the host resolver.
• 'forward . /etc/resolv.conf uses the resolver file visible to CoreDNS, not necessarily the node's local stub.'
• Loopback resolvers such as 127.0.0.53 often fail inside containers.
• Prefer explicit, reachable upstream DNS servers for private and public zones.
• Debug from inside the cluster by checking the Corefile, CoreDNS container resolver settings, and a real pod lookup.