Kubernetes DNS Network Interaction

Kubernetes DNS Network Interaction describes how pods resolve service and pod names within a cluster, the network path a DNS query takes from a pod to the cluster's DNS service and back, and the ways DNS resolution intersects with the broader Service data plane and NetworkPolicy enforcement.

Cluster DNS Architecture

DNS as a Cluster Service

Cluster DNS is itself deployed as an ordinary Kubernetes Service, typically backed by a set of DNS server pods running a resolver such as CoreDNS, exposed through a stable ClusterIP. This means DNS queries from pods travel through the exact same Service data path, interception, DNAT, and forwarding to a backend pod, used by any other ClusterIP-based Service.

Pod-Level Resolver Configuration

Every pod's network namespace is configured, through its /etc/resolv.conf, to send DNS queries to the cluster DNS Service's ClusterIP by default, along with a search path that allows short, unqualified Service names to resolve correctly within the pod's own namespace before falling back to fully qualified cluster domain names.

Name Resolution Scope

Service Name Resolution

DNS records for Services are generated automatically and follow a predictable pattern combining the Service name, its namespace, and the cluster's configured domain suffix, allowing any pod in the cluster to resolve any Service by its fully qualified name, and pods within the same namespace to use the short, unqualified name.

Pod Hostname and Subdomain Records

Pods can also receive individual DNS records when explicitly configured with a hostname and subdomain tied to a headless Service, which is commonly used by stateful workloads that need stable, individually addressable network identities for each replica rather than being reached only through a load-balanced Service address.

Headless Service Resolution Behavior

For headless Services, which have no ClusterIP, DNS resolution returns the individual IP addresses of all backing pods directly rather than a single virtual address, meaning the DNS interaction itself becomes the load balancing mechanism, with the resolving client responsible for choosing among the returned addresses.

Query Path and Caching

Node-Local DNS Caching

To reduce load on cluster DNS server pods and reduce the latency and potential packet loss associated with routing every query through the Service data path, many clusters deploy a node-local DNS cache that runs on every node and intercepts DNS queries before they would otherwise be sent to the cluster DNS Service, serving cached responses directly or forwarding cache misses upstream.

Search Domain Expansion Cost

Because a pod's resolver configuration includes a search path with multiple domain suffixes, an unqualified name lookup can generate several sequential DNS queries as the resolver tries each suffix in turn, which is a common source of unexpectedly high DNS query volume and latency in clusters with many namespaces or deeply nested search domains.

Interaction With NetworkPolicy

DNS Egress Allowance Requirement

Because DNS queries are themselves network traffic subject to NetworkPolicy egress isolation, any pod isolated for egress traffic must have an explicit rule permitting traffic to the cluster DNS Service's port, typically UDP and TCP port 53, or the pod will be unable to resolve any name at all, including Service names required for its own application traffic.

External DNS Resolution

Upstream Forwarding

Queries for names outside the cluster's domain are forwarded by the cluster DNS servers to upstream resolvers, typically inherited from the node's own DNS configuration or explicitly configured, meaning cluster DNS interaction extends beyond the cluster network boundary whenever a pod needs to resolve an external hostname, subject to whatever egress network policy applies to that traffic path as well.

Failure Diagnosis

DNS-Specific Connectivity Symptoms

Because DNS queries traverse the Service data plane and depend on cluster DNS pods being healthy and reachable, failures at any point in that chain, a misconfigured NetworkPolicy, an unhealthy DNS pod, or Service data plane rule corruption, tend to manifest as application-level name resolution timeouts, which is why DNS interaction is treated as one of the first things checked when diagnosing seemingly unrelated pod connectivity issues.