# Some DNS queries fail: why TCP and UDP port 53 both matter

Diagnose some DNS queries fail: why TCP and UDP port 53 both matter. Evidence to collect, a worked operational example and recovery checks.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/kubernetes-dns-udp-tcp-policy/
Language: en

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.


[Official reference 1](https://www.rfc-editor.org/rfc/rfc7766.html).

## 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.


[Official reference 2](https://kubernetes.io/docs/concepts/services-networking/network-policies/).

## 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 |


[Official reference 3](https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/).

## 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](/journal/network-and-uptime/); [hardware security](/journal/hardware-security/).