---
# Strategic-merge patch capping the CoreDNS pod's DNS at three
# upstream servers to silence Kubernetes' DNSConfigForming warning
# (DEV-527).
#
# The Hetzner OS publishes four systemd-resolved upstreams
# (2a01:4ff:ff00::add:2, 2a01:4ff:ff00::add:1, 185.12.64.1, 185.12.64.2),
# and kubelet drops the fourth because Kubernetes limits pod resolv.conf
# to three nameservers. CoreDNS uses `dnsPolicy: Default` (inherit the
# node's resolv.conf) so it triggers the warning too.
#
# We keep the same three servers kubelet would have picked (the two
# Hetzner IPv6 anycast entries plus the first IPv4 entry) so CoreDNS's
# upstream forwarder (`forward . /etc/resolv.conf`) sees the same
# upstreams it already uses; only the noisy warning goes away.
# `dnsPolicy: None` is required so `dnsConfig` is authoritative —
# otherwise kubelet still merges the node's resolv.conf and we exceed
# the three-nameserver limit again.
#
# CoreDNS in k3s is an *Addon* whose source manifest lives on each
# control-plane node at `/var/lib/rancher/k3s/server/manifests/coredns.yaml`
# and is reconciled by the k3s addon controller. Applying this file
# via `kubectl patch` is durable in steady state (the addon controller
# only re-applies when the source file's checksum changes), but if the
# source file is ever regenerated (k3s upgrade, disaster recovery) the
# patch will be reverted. To keep the fix on regeneration, mirror the
# same `dnsPolicy` / `dnsConfig` block into the Deployment stanza of
# each CP node's `coredns.yaml` — see `docs/DEV-527-coredns-dns-config.md`.
#
# Apply / re-apply with:
#   kubectl -n kube-system patch deployment coredns \
#     --type=strategic \
#     --patch-file=apps/observability/patches/coredns-dns-config.yaml
spec:
  template:
    spec:
      dnsPolicy: None
      dnsConfig:
        nameservers:
          - 2a01:4ff:ff00::add:2
          - 2a01:4ff:ff00::add:1
          - 185.12.64.1
        searches:
          - .
        options:
          - name: edns0
          - name: trust-ad