Kubernetes DNS

Most important commands to remember

• kubectl config current-context — check the selected cluster context.
• kubectl exec … -- cat /etc/resolv.conf — inspect the Pod’s resolver setup.
• kubectl exec … -- nslookup NAME — query DNS from inside that Pod.

Commands and flags

Command or option	Meaning
config current-context	Print the active kubeconfig context without changing it.
-n lab	Select namespace lab.
exec dns-lab -- COMMAND	Run COMMAND inside the existing Pod; -- ends kubectl options.
cat /etc/resolv.conf	Read the Pod’s resolver nameserver, search list, and options.
nslookup kubernetes.default	Resolve the Service name in namespace default.

No interactive terminal is needed. The diagnostic tools must already exist in the Pod; kubectl does not install them. The query runs from the Pod’s network and DNS context, not your laptop’s.

The concepts that matter

1. DNS gives changing backends a stable name

Pods can be replaced and receive new addresses. Kubernetes DNS lets clients find Services by names derived from their Service and namespace rather than embedding individual Pod addresses.

A normal Service commonly resolves to a stable virtual ClusterIP. A headless Service can instead return endpoint addresses. The name alone does not tell you whether a connection will pass through a Service virtual IP or go directly to an endpoint.

2. The namespace shapes short-name lookup

A Pod’s resolver search list normally includes its namespace’s service domain and wider cluster domains. A short name can therefore resolve to a Service in the same namespace, while a namespace-qualified name can select another namespace.

The cluster domain is configurable; cluster.local is common, not universal. Resolver options such as ndots affect whether names are tried with search suffixes first. This can produce several DNS queries from one application lookup.

3. The Pod resolver is a separate dependency

The kubelet configures Pod DNS behavior according to DNS policy and cluster settings. A cluster DNS service, commonly implemented by CoreDNS, answers cluster names and may forward other queries upstream.

Your laptop resolving a public website does not prove the Pod’s resolver path works. Likewise, cluster-name resolution can work while forwarding external names fails. Inspect the resolver configuration and query from the place where the application actually runs.

4. Resolution is only the first step

A DNS answer supplies an address or records. It does not establish network policy permission, a listening port, a ready backend, successful TLS, or a valid application response.

DNS caches also affect how quickly changes are observed. When a request fails, separate lookup failure from connection failure and application failure. Replacing DNS configuration because an HTTP endpoint returns an error can target the wrong layer.

One small example

Optional: verify that the current context is your intended test cluster before the exec commands. Use the already provisioned diagnostic Pod; this example creates no Kubernetes resources.

kubectl config current-context
kubectl -n lab exec dns-lab -- cat /etc/resolv.conf
kubectl -n lab exec dns-lab -- nslookup kubernetes.default

Inspect nameserver, search, and options in the resolver file. Then compare nslookup’s answer for kubernetes.default with the expected Service namespace. The printed DNS server address is the resolver, not necessarily the address of the Service being queried.

A returned answer demonstrates DNS resolution from that Pod. It does not authenticate to the Kubernetes API or test an HTTPS request. NXDOMAIN, a timeout, and a missing nslookup executable are different failures. No resource cleanup is needed because the commands only inspect and query.

Keep this idea: Kubernetes DNS maps Service names from the Pod’s context; successful resolution is a starting point for connectivity, not its final proof.