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.
\nThe Using NodeLocal DNSCache in Kubernetes Clusters documentation is the primary reference.
\nThe 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.
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.
\nDSE 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.
\nSelect 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.
\nPlan 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.
\nEvaluate 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.
\nProposed 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.
\nRun 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Using NodeLocal DNSCache in Kubernetes Clusters documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich kube-proxy mode actually runs on the intended nodes?\nWhat approved node-local address will the cache use?\nWhich address does the kubelet supply as the Pod DNS destination?\nHow will the deployment owner restore the prior DNS path if the exercise fails?\n\nDSE recommendation: review the listen-and-destination pair\nDSE 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.\nSelect 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.\nPlan 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.\nEvaluate 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.\nVerification and evidence\nProposed 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.\nRun 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.\nOfficial references\n\nUsing NodeLocal DNSCache in Kubernetes Clusters — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Using NodeLocal DNSCache in Kubernetes Clusters](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) documentation is the primary reference.\n\nThe 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which kube-proxy mode actually runs on the intended nodes?\n\n- What approved node-local address will the cache use?\n\n- Which address does the kubelet supply as the Pod DNS destination?\n\n- How will the deployment owner restore the prior DNS path if the exercise fails?\n\n## DSE recommendation: review the listen-and-destination pair\n\nDSE 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.\n\nSelect 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.\n\nPlan 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.\n\nEvaluate 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.\n\n## Verification and evidence\n\nProposed 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.\n\nRun 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.\n\n## Official references\n\n- [Using NodeLocal DNSCache in Kubernetes Clusters](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/", "url": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Match NodeLocal DNSCache addressing to the kube-proxy mode", "item": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/#article", "identifier": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/", "url": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/", "headline": "Match NodeLocal DNSCache addressing to the kube-proxy mode", "description": "Review the documented iptables and IPVS branches before changing the kubelet DNS destination for NodeLocal DNSCache.", "abstract": "Review the documented iptables and IPVS branches before changing the kubelet DNS destination for NodeLocal DNSCache.", "articleBody": "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.\nSource fact: documented behavior\nThe Using NodeLocal DNSCache in Kubernetes Clusters documentation is the primary reference.\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich kube-proxy mode actually runs on the intended nodes?\nWhat approved node-local address will the cache use?\nWhich address does the kubelet supply as the Pod DNS destination?\nHow will the deployment owner restore the prior DNS path if the exercise fails?\n\nDSE recommendation: review the listen-and-destination pair\nDSE 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.\nSelect 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.\nPlan 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.\nEvaluate 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.\nVerification and evidence\nProposed 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.\nRun 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.\nOfficial references\n\nUsing NodeLocal DNSCache in Kubernetes Clusters — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:29+00:00", "dateModified": "2026-10-30T06:05:14+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/match-nodelocal-dnscache-addressing-to-the-kube-proxy-mode/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Match NodeLocal DNSCache addressing to the kube-proxy mode" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 546, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Using NodeLocal DNSCache in Kubernetes Clusters", "url": "https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/" } } ] } }