CoreDNS

CoreDNS

#

Quelle

#

Das Projekt basiert auf dem CoreDNS GitHub Repository. Das Helm-Chart stammt aus dem CoreDNS Helm Charts Repository.

Dokumentation

#

• CoreDNS Dokumentation
• CoreDNS GitHub Repository

Funktion

#

CoreDNS ist ein fundamentaler Bestandteil des Kubernetes-Clusters und verantwortlich für die Namensauflösung (DNS). Es ermöglicht Pods und Services, sich gegenseitig über ihre Namen zu finden (z.B. my-service.my-namespace.svc.cluster.local). Es ist so konfiguriert, dass es Anfragen für interne Cluster-Domains beantwortet und alle anderen Anfragen an Upstream-DNS-Server weiterleitet.

Lokale Anpassungen

#

Die Konfiguration erfolgt über die values.yaml-Datei.

Wichtige Einstellungen

#

• Replikas: Es werden drei Replikate von CoreDNS betrieben, um Hochverfügbarkeit zu gewährleisten.
• Dual-Stack: Der Service ist für den Dual-Stack-Betrieb (IPv4 und IPv6) konfiguriert.
• Plugins: Eine Reihe von Plugins ist aktiviert, darunter:
  • kubernetes: Für die Auflösung von Kubernetes-Services und -Pods.
  • forward: Leitet Anfragen, die nicht vom kubernetes-Plugin aufgelöst werden können, an die DNS-Server in /etc/resolv.conf weiter.
  • cache: Cacht DNS-Antworten, um die Latenz zu verringern und die Last auf den Upstream-Servern zu reduzieren. Zusätzlich serve_stale und servfail 0 — siehe unten.
  • prometheus: Stellt Metriken für das Monitoring bereit.
• Standort-Zonen: Zonen von per VPN angebundenen Standorten sind hier bewusst nicht eingetragen. Die Weiterleitung läuft über dns.nameservers.split in apps/headscale und erreicht damit nur Tailnet-Clients — im LAN bleibt unsichtbar, dass die Zonen überhaupt existieren. Details in apps/vpn-site-b.
• Scheduling: CoreDNS-Pods werden bevorzugt auf den Control-Plane-Nodes ausgeführt und sind über topologySpreadConstraints auf verschiedene Nodes und Zonen verteilt, um die Ausfallsicherheit zu erhöhen.

Ausfallsicherheit bei toten autoritativen Nameservern

#

Fällt der DNS-Anbieter aus, hilft kein Fallback-Resolver: jeder fragt dieselben Maschinen. Nur zwischengespeicherte Daten helfen. Drei Einstellungen greifen dafür ineinander:

• serve_stale 720h verify 2s liefert abgelaufene Antworten aus, wenn niemand mehr antwortet. verify statt immediate, weil die dynamisch gepflegten A-Records sonst im Normalbetrieb aus dem Cache beantwortet würden. Die 720 h sind am Signaturfenster der Zone bemessen — länger wäre eine alte Antwort ohnehin nicht mehr DNSSEC-validierbar.
• servfail 0 schaltet das Cachen von SERVFAIL ab (Vorgabe: 5 s). Sonst legt sich im Ausfall ein frisches SERVFAIL über den abgelaufenen Eintrag.
• failover SERVFAIL REFUSED im forward-Block. Ohne das gilt laut CoreDNS-Dokumentation jede Antwort, die kein Netzwerkfehler ist, als gesunder Upstream — ein SERVFAIL von Pi-hole ginge unverändert an den Client und 8.8.8.8 würde nie gefragt.

Das Gegenstück ist apps/corenetworks-dns-operator: serve_stale hilft nur für Namen, die schon im Cache liegen, und ein Name, den niemand abfragt, ist dort nicht. Ein CronJob wärmt deshalb alle Namen der Zonen regelmäßig durch.

Installation

#

Die Anwendung wird mittels Kustomize und Helm durch ArgoCD im Kubernetes-Cluster bereitgestellt. Die Konfiguration befindet sich im apps/coredns-Verzeichnis. Eine manuelle Installation kann mit folgendem Befehl durchgeführt werden:

1kubectl kustomize --enable-helm apps/coredns | kubectl apply -n kube-system -f -

Abhängigkeiten

#

CoreDNS ist eine Kernkomponente von Kubernetes und hat keine externen Anwendungsabhängigkeiten, ist aber für die Funktion fast aller anderen Anwendungen im Cluster kritisch.