Kubernetes DNS Definition

Kubernetes DNS Definition is the precise characterization of the cluster's internal DNS system as a defined, standardized naming scheme and resolving service through which Services and, in specific cases, individual Pods are made addressable by name rather than by IP address, formally specified by the Kubernetes DNS specification and conventionally implemented by an in-cluster DNS server such as CoreDNS. Cluster DNS is not an optional convenience layered arbitrarily on top of the platform; it is a formally defined add-on whose naming conventions and record structure are part of Kubernetes' own specification for how Services should be discoverable.

Formal Naming Scheme

Service DNS Records

A Service of name <service> in namespace <namespace> is formally guaranteed a DNS A or AAAA record resolvable at the fully qualified name below, where <cluster-domain> defaults to cluster.local but may be configured differently per cluster.

<service>.<namespace>.svc.<cluster-domain>

Search Domain Shortening

A Pod's DNS configuration is formally populated with a search path derived from its own namespace, allowing shorter, unqualified or partially qualified names to resolve correctly when the referenced Service resides in the same or, with additional qualification, a different namespace.

kubectl exec -it debug-pod -n codartium-team -- nslookup codartium-api
kubectl exec -it debug-pod -n codartium-team -- nslookup codartium-api.codartium-team
kubectl exec -it debug-pod -n codartium-team -- nslookup codartium-api.codartium-team.svc.cluster.local

Record Types by Service Configuration

Normal (ClusterIP-bearing) Services

For a Service with an allocated virtual IP, cluster DNS formally returns a single A or AAAA record resolving to that virtual IP, regardless of how many Pods currently back it, since the DNS layer resolves to the Service's stable address, not to individual Pod addresses.

Headless Services

For a Service defined with clusterIP: None, cluster DNS formally returns multiple A or AAAA records, one per ready backing Pod address recorded in the corresponding Endpoints/EndpointSlice object, since no single virtual IP exists to resolve to instead.

spec:
  clusterIP: None
  selector:
    app: codartium-db

codartium-db-0.codartium-db.codartium-team.svc.cluster.local
codartium-db-1.codartium-db.codartium-team.svc.cluster.local

SRV Records

For named ports on a Service, cluster DNS formally also publishes SRV records, encoding the protocol, port name, and target hostname, allowing clients that support SRV-based discovery to resolve both the address and the correct port without hardcoding it.

Pod DNS Records

DNS for Individual Pods

Pods are formally assigned a DNS record only under specific conditions, most commonly as a byproduct of a headless Service selecting them, or when a StatefulSet's Pod-per-ordinal identity is exposed through its governing headless Service; a Pod belonging to no Service has no guaranteed DNS record of its own by default.

hostname and subdomain Fields

A Pod's spec.hostname and spec.subdomain fields formally control the specific DNS name assigned to it when combined with a governing headless Service, together constructing a predictable, stable per-Pod DNS entry.

spec:
  hostname: codartium-db-0
  subdomain: codartium-db

Resolution Configuration Within a Pod

resolv.conf Population

Each Pod's /etc/resolv.conf is formally populated by the kubelet based on the cluster's DNS policy setting, typically pointing at the cluster DNS service's virtual IP as the nameserver and including the namespace-derived search domains described above.

spec:
  dnsPolicy: ClusterFirst

dnsPolicy Values

ClusterFirst, the default, formally routes in-cluster names to cluster DNS and forwards anything not matching the cluster domain to the upstream nameserver inherited from the node; Default formally inherits the node's own DNS configuration directly; None formally requires DNS configuration to be supplied explicitly via dnsConfig, bypassing automatic cluster DNS configuration entirely.

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl exec -it debug-pod -- cat /etc/resolv.conf

Why DNS Is Formally Specified

Because Service and Pod naming conventions are fixed by specification rather than left to each cluster's discretion, any workload manifest that references another Service by its namespace-qualified DNS name behaves identically across any conformant cluster, a portability guarantee that depends entirely on cluster DNS following this defined naming scheme rather than an implementation-specific one.