Configure upstream DNS resolution in K3s

A custom DNS server can resolve internal names on the host while those same names fail inside K3s pods. Start by checking which resolver configuration K3s selected and where CoreDNS forwards external queries.

1. Inspect the resolver path

cat /etc/resolv.conf
kubectl -n kube-system get configmap coredns -o yaml

K3s checks common resolver files and may select an alternative when a file contains unsuitable nameservers. CoreDNS commonly forwards external queries through its own /etc/resolv.conf. A host loopback resolver such as 127.0.0.53 is not reachable at that address from an ordinary pod.

2. Set an explicit resolver file

On every node that may run CoreDNS, prepare a resolver file containing DNS servers reachable from the pod network. To use /etc/resolv.conf, first confirm its nameserver addresses meet that requirement. Merge this setting into the existing /etc/rancher/k3s/config.yaml; do not append duplicate YAML keys:

resolv-conf: /etc/resolv.conf

Use another absolute path if the host file points to a local stub resolver. Keep the file and its nameservers consistent across eligible nodes.

3. Restart and verify

Apply during a maintenance window, one node at a time. Restart the service appropriate to the node: sudo systemctl restart k3s on a server, or sudo systemctl restart k3s-agent on an agent. Once the nodes are healthy, recreate CoreDNS through its Deployment:

kubectl -n kube-system rollout restart deployment/coredns
kubectl -n kube-system rollout status deployment/coredns

From a workload pod with a DNS lookup tool, verify the internal name, a public hostname, and kubernetes.default.svc.cluster.local. A successful lookup on the host alone does not verify pod DNS.

For resolver selection and domain-specific forwarding alternatives, see K3s DNS configuration.