What do the Kubernetes pod spec fields dnsPolicy and dnsConfig control, and what are the available dnsPolicy values?

## What these fields do Every pod gets an `/etc/resolv.conf` written for it. `dnsPolicy` chooses the template used to generate it; `dnsConfig` adjusts the result. Together they are the only supported way to change name resolution for a workload without editing files at runtime. ## The four dnsPolicy values **`ClusterFirst`** — the default when the field is omitted. The kubelet writes the cluster DNS Service address as `nameserver`, the namespace-scoped search list, and `options ndots:5`. Cluster names are answered by CoreDNS from its live view of Services and endpoints; anything else CoreDNS forwards to its configured upstream resolvers. The name is slightly misleading: it does not mean "try the cluster then try elsewhere" in the resolver — the resolver only ever talks to CoreDNS, and CoreDNS decides what to forward. **`ClusterFirstWithHostNet`** — behaves like `ClusterFirst`, but must be set explicitly on pods with `hostNetwork: true`. This is the single most common trap in this area: a host-network pod with the default policy does **not** get cluster DNS, because the pod shares the node's network namespace and the kubelet applies the node's resolver settings. The symptom is a node agent or exporter that cannot resolve any `*.svc.cluster.local` name while everything else works. The fix is one line. **`Default`** — the pod inherits the node's `/etc/resolv.conf` (whatever the kubelet was configured to treat as the host resolver). Cluster Service names will not resolve unless the node's resolver happens to know them. It is useful for workloads that must resolve exactly as the node does — some node-level tooling, or a debugging container — and its name causes endless confusion, because it is not the default. **`None`** — Kubernetes generates nothing. The pod's resolver configuration comes entirely from `dnsConfig`, which then becomes mandatory. Use it when a workload must talk to a specific resolver, for example a pod that queries an internal corporate DNS directly and must not inherit cluster search paths. ## dnsConfig Three fields: - `nameservers` — a list of resolver addresses. With `None` these are the only servers; otherwise they are appended to the generated one (with a limit on total entries, typically three for the standard resolver). - `searches` — extra search suffixes, appended to the generated list. Useful to give a workload a legacy internal suffix so that historic short names keep resolving. - `options` — resolver options as name/value pairs. The common uses are `ndots` (lowering it for egress-heavy workloads) and options that change how parallel queries are issued, which some teams use to work around a UDP query-collision race that causes multi-second resolution stalls. Merge semantics matter: with `ClusterFirst`, `dnsConfig` **adds to** what Kubernetes generated, and a repeated option overrides the generated one — so setting `ndots: "2"` replaces `ndots:5` while leaving nameserver and search list intact. With `None`, nothing is generated and omissions mean the setting is simply absent. ## Choosing correctly - Ordinary application → leave it alone; `ClusterFirst` is right. - Egress-heavy application making many external calls → `ClusterFirst` plus `dnsConfig` lowering `ndots`, after checking the workload does not depend on short cross-namespace names. - Node agent with `hostNetwork: true` that must reach in-cluster Services → `ClusterFirstWithHostNet`. - Node-level tool that must see exactly what the node sees → `Default`. - Workload that must use a specific external resolver and nothing else → `None` with an explicit `dnsConfig`. ## Operational notes These fields are part of the pod template, so changing them triggers a rollout — they are not runtime tunables. In a platform team, they are also a governance surface: a workload that sets `None` bypasses cluster DNS entirely, escaping any node-local caching, forwarding rules or query visibility the platform relies on. Admission policy is the usual place to constrain that, and to inject a default `ndots` for a workload class rather than asking every team to remember it. When debugging, always read the effective file rather than the manifest: `kubectl exec <pod> -- cat /etc/resolv.conf` shows what the pod actually received, which immediately reveals a host-network pod that never got cluster DNS.