Default-Deny Egress Silently Breaks Pod DNS Lookups

The Trap

An egress default-deny NetworkPolicy applied without a corresponding DNS allow rule, silently blocking every pod’s ability to resolve names via CoreDNS or kube-dns.

The Default State

Security teams roll out a baseline NetworkPolicy such as podSelector: {} with policyTypes: [Egress] and no egress rules, intending to force explicit allow-lists per namespace. CoreDNS itself is rarely covered by that first pass because it lives in kube-system, and nobody adds a rule permitting UDP/TCP port 53 to the k8s-app: kube-dns pods before the policy goes live. On EKS and some bare-metal builds, CoreDNS additionally runs with hostNetwork: true, so even a correctly written podSelector-based allow rule cannot match it, since NetworkPolicy has no concept of host-networked pod identity.

The Blast Radius

Pods can still resolve names cached before the policy applied, so failures appear staggered and intermittent rather than immediate. Application code sees connection timeouts to external APIs, databases, or object storage endpoints and logs generic exceptions such as connection refused or read timeout. Nothing in the stack trace mentions DNS. Engineers restart deployments, scale horizontally, or roll back unrelated recent changes, because the symptom pattern matches upstream service degradation rather than local resolver failure. Readiness and liveness probes that depend on hostname resolution start failing unpredictably, triggering pod evictions that make the outage look like a resource or scheduling problem. Mean time to resolution stretches for hours because kubectl exec -- nslookup is rarely the first diagnostic step when the assumption is an external dependency outage.

The Lead Mechanic Fix

Add an explicit egress rule to every default-deny NetworkPolicy permitting DNS before the policy is applied cluster-wide: a rule with to.namespaceSelector matching kubernetes.io/metadata.name: kube-system, to.podSelector matching k8s-app: kube-dns, and ports covering UDP 53 and TCP 53. Where CoreDNS runs with hostNetwork: true, replace the podSelector match with an ipBlock covering the node CIDR, or migrate to a CNI supporting DNS-aware egress such as Cilium’s toFQDNs and toEndpoints selectors that resolve kube-dns correctly regardless of network mode. Validate every namespace with kubectl exec <pod> -- nslookup kubernetes.default before promoting the policy past staging, and gate rollout with a CI check that greps for a DNS egress rule in every NetworkPolicy manifest before merge.