In this article
Allowing UDP port 53 alone does not provide complete DNS connectivity. DNS also uses TCP, and blocking it may affect only some queries or responses. Test both transports and effective NetworkPolicy rather than relying on one successful short lookup.
Allowing UDP port 53 alone does not provide complete DNS connectivity. DNS also uses TCP, and blocking it may affect only some queries or responses. Test both transports and effective NetworkPolicy rather than relying on one successful short lookup.
Identify the actual DNS endpoint
Preserve the Pod’s resolv.conf, nameserver address and route to cluster DNS. NodeLocal DNSCache or another layer can change the relevant address and policy compared with direct access to a CoreDNS Service. Inspect namespace labels and egress selectors. NetworkPolicy requires supporting CNI behavior; a YAML object alone does not establish enforcement. Connect the workload, destination and enforcing plugin in the incident record.
Compare UDP and TCP
RFC 7766 requires TCP support for a complete DNS implementation. TCP is not limited to zone transfers: large or truncated responses can also lead to its use. Avoid a rule that treats all DNS as UDP merely because simple names currently work. Equally, do not treat every DNS timeout as proof of blocked TCP. Resolver failures, upstream behavior and UDP loss remain separate hypotheses requiring evidence.
Investigate partial failure
An illustrative policy permits UDP 53 to the resolver but omits TCP. A short response succeeds while another operation requiring TCP stalls. From a test Pod, issue permitted diagnostic queries over both transports to the same resolver. Preserve response codes, timing and relevant CNI observations. This explains why partial success is insufficient; it does not assert that every large response follows one fixed path under every configuration.
| Test | Evidence to compare |
|---|---|
| UDP to resolver | Delivery and response on that transport |
| TCP to the same address | Connection establishment and response |
| Test without policy | Baseline connectivity |
| Test with policy | Actual effect of selected rules |
Correct the rule scope
Permit required DNS protocols to appropriate endpoints for the CNI and resolver architecture. Do not open all production egress to investigate one dependency. Verify that selectors do not accidentally permit neighboring namespaces. Kubernetes NetworkPolicy is not a first-match firewall rule list; it has its own additive permission model. Assess all policies applying to the source Pod rather than only the edited document.
Retain a reproducible test
Repeat both transports and required internal and external names after the change. Check that restrictions on unrelated destinations remain effective. Preserve resolver path, selectors, CNI version and TCP/UDP observations. Reuse the test when changing DNS layers or network plugins. One resolved name confirms that particular test, while a working dependency still requires subsequent connection establishment and TLS validation. Keeping those stages separate prevents a DNS fix from being mistaken for complete application recovery.
Related operational reading: network and uptime; hardware security.