Match NodeLocal DNSCache addressing to the kube-proxy mode

Bottom line: Choose the documented NodeLocal DNSCache branch from the actual kube-proxy mode. Reconcile its listen addresses with the kubelet DNS destination before rolling the configuration across nodes.

Source fact: documented behavior

The Using NodeLocal DNSCache in Kubernetes Clusters documentation is the primary reference.

The NodeLocal DNSCache guide labels the feature stable since Kubernetes 1.18 and runs the node-local caching agent through a DaemonSet. In the documented iptables mode, node-local-dns listens on both the CoreDNS Service IP and the chosen node-local address. In IPVS mode it listens only on the node-local address because the IPVS interface already uses the CoreDNS cluster IP. The guide requires changing the kubelet --cluster-dns destination to that local address for IPVS; its iptables branch does not require the same change.

What the source does not establish

This article follows the guide’s iptables and IPVS configuration branches. It does not prescribe behavior for an unlisted proxy implementation, choose a collision-free address for a real network or guarantee DNS availability. Keep resolver search paths, external domains and cache sizing under their separate reviews.

Applicability questions

• Which kube-proxy mode actually runs on the intended nodes?
• What approved node-local address will the cache use?
• Which address does the kubelet supply as the Pod DNS destination?
• How will the deployment owner restore the prior DNS path if the exercise fails?

DSE recommendation: review the listen-and-destination pair

DSE recommends a per-node-pool worksheet containing the observed proxy mode, CoreDNS Service address, proposed local cache address and intended kubelet DNS setting. Have the network owner review address allocation before editing the manifest. Keep examples from the documentation distinct from addresses approved for this cluster.

Select the corresponding manifest branch deliberately. Compare each substitution with the worksheet and preserve the resulting definition for review. Do not combine fragments from the iptables and IPVS examples merely because their names appear similar. Ask the node administrator to confirm which configuration source actually governs kubelet startup.

Plan the change and reversal together. Name a limited test population, expected nameserver observation and bounded query set. Retain the prior managed kubelet configuration and the test manifest under the established node-management process. Avoid broad rollout while an address or mode discrepancy remains unresolved.

Evaluate the actual workload context after deployment. Use harmless cluster-name queries and the intended resolver path, recording where each observation came from. Keep a successful administrative-host query separate from the selected Pod’s result. Require the application owner’s own DNS and request checks before declaring the deployment ready for that workload.

Verification and evidence

Proposed verification, not performed: prepare an approved test node pool with its actual documented proxy mode. Inspect the node-local cache listen addresses and the nameserver delivered to a disposable Pod, comparing both with the reviewed worksheet.

Run a fixed set of harmless lookups and retain query names, Pod namespace, resolver destination and actual answers or errors. If both modes are supported in separate labs, maintain separate records rather than switching production modes for this exercise. Test the approved reversal procedure and compare the restored DNS path. Report the exact configuration observed, without turning a few successful queries into a general latency or availability guarantee.

Official references

• Using NodeLocal DNSCache in Kubernetes Clusters — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.