Understanding DNS and Its Configuration in Kubernetes

DNS (Domain Name System) translates human‑readable domain names such as www.example.com into IP addresses, allowing users to access network resources without memorising numeric addresses.

It operates as an application‑layer protocol using a client‑server model, typically over UDP or TCP, and newer privacy‑enhancing extensions like DNS‑over‑TLS, DNS‑over‑HTTPS, and DNS‑over‑QUIC have been introduced.

In a Kubernetes cluster, each Pod receives an automatically generated /etc/resolv.conf file from the kubelet. A typical file looks like:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

The file contains three main directives:

nameserver : the IP address of the cluster DNS server (historically kube-dns , now usually CoreDNS ).

search : the suffixes appended to queries for domain‑name completion.

options ndots:5 : requires at least five dots in a name before it is considered a fully‑qualified domain name; otherwise the search suffixes are applied.

The kubelet’s command‑line flags --cluster-dns (or clusterDNS ) and --cluster-domain (or clusterDomain ) populate the nameserver and search fields respectively, while the options ndots:5 entry is hard‑coded in the kubelet source.

Pod DNS behaviour is also controlled by the dnsPolicy setting, which can be:

Default : uses the node’s resolv.conf as defined by the kubelet’s resolvConf option.

ClusterFirst : the default, queries the cluster DNS server.

ClusterFirstWithHostNet : used when the pod runs with hostNetwork .

None : ignores the default settings; the pod’s dnsConfig fully defines the resolv.conf.

Customising a pod’s /etc/resolv.conf can be done via dnsConfig . For example:

apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 192.0.2.1
searches:
- ns1.svc.cluster-domain.example
- my.dns.search.suffix
options:
- name: ndots
value: "2"

In summary, DNS in Kubernetes follows the standard client‑server model, with the cluster’s CoreDNS handling queries; the kubelet generates each pod’s /etc/resolv.conf based on its own configuration, the pod’s dnsPolicy , and any optional dnsConfig customisation, making these settings essential for troubleshooting and optimisation.