CoreDNS down: Symptome, Root Cause und Fix (K8s DNS Guide)

Red Snapper

1 month ago

Wenn CoreDNS down ist, wirkt Kubernetes plötzlich „kaputt“, obwohl Pods, Nodes und Deployments auf den ersten Blick gesund aussehen. Der Grund ist simpel: DNS ist eine Basisschicht, auf die fast jede Anwendung im Cluster angewiesen ist – von Service Discovery (myservice.myns.svc.cluster.local) über Container-Registries bis hin zu externen APIs. Fällt CoreDNS aus oder wird extrem langsam, sehen Sie in kurzer Zeit eine Kaskade aus Folgeproblemen: Pods starten nicht, Readiness-Probes schlagen fehl, Sidecars können ihre Control-Plane nicht erreichen, CronJobs brechen ab, und plötzlich steigen 5xx-Raten, obwohl „nur DNS“ betroffen ist. Dieses K8s DNS Guide-Runbook erklärt praxisnah die häufigsten Symptome, die realistischen Root Causes und die wirkungsvollsten Fixes – inklusive systematischer Debug-Schritte, mit denen Sie CoreDNS-Probleme schnell von NetworkPolicies, Upstream-DNS, MTU/Packet-Loss oder Ressourcenengpässen abgrenzen. Ziel ist nicht nur ein schneller Restore, sondern ein stabiler Betrieb: bessere Telemetrie, sinnvolle Limits und Konfigurationen, die DNS-Stürme und „Death Spirals“ verhindern.

Was CoreDNS in Kubernetes genau macht

CoreDNS ist der Standard-DNS-Server in vielen Kubernetes-Distributionen. Er beantwortet Anfragen innerhalb der Cluster-Domain (z. B. .cluster.local) und leitet externe Domains (z. B. api.example.com) an Upstream-Resolver weiter (VPC/VNet-DNS, Unternehmens-DNS, öffentliche Resolver – je nach Setup). Das Entscheidende: Pods verwenden in der Regel CoreDNS als einzigen Nameserver, der in /etc/resolv.conf im Container eingetragen ist. Wenn CoreDNS nicht erreichbar ist oder nicht performant antwortet, scheitert Namensauflösung – und damit jede Kommunikation, die auf Hostnamen basiert.

Service Discovery: Auflösung von Services und Endpoints innerhalb des Clusters.
DNS-Weiterleitung: Externe Domains werden an Upstream-Resolver geforwardet.
Caching: Häufige Anfragen werden zwischengespeichert, um Latenz zu senken und Upstream zu entlasten.
Health/Readiness: CoreDNS bietet Endpunkte, um Health-Zustand und Readiness zu prüfen.

Symptome: So erkennt man „CoreDNS down“ in der Praxis

DNS-Probleme äußern sich oft indirekt. Statt „DNS ist kaputt“ sehen Sie Timeouts, sporadische Errors oder startende/stoppende Pods. Typisch ist auch, dass interne und externe Auflösung unterschiedlich betroffen sind.

Pods können keine Services erreichen: Fehler wie „name resolution failed“, „no such host“ oder „temporary failure in name resolution“.
Readiness/Liveness-Probes schlagen fehl: Besonders wenn Probes Hostnamen nutzen oder Sidecars/Agenten externe Ziele prüfen.
Image Pull Issues: Container-Registry-Hostnames lassen sich nicht auflösen, Pulls hängen oder scheitern.
Intermittierende Fehler: DNS ist nicht komplett down, aber extrem langsam; P95/P99 der DNS-Latenz steigt stark an.
Nur externe Domains betroffen: Interne .svc-Namen gehen, externe nicht (Upstream-Problem oder Forwarding).
Nur bestimmte Namespaces betroffen: Häufig NetworkPolicy-Egress zu DNS ist blockiert oder Pods nutzen spezielle dnsPolicy/dnsConfig.

Quick Checks aus einem betroffenen Pod

Resolver prüfen: cat /etc/resolv.conf (Nameserver-IP, Search-Domains, ndots).
Intern testen: nslookup kubernetes.default.svc oder dig kubernetes.default.svc.
Extern testen: nslookup example.com (oder eine bekannte Domain).
Latenz sichtbar machen: Mehrfachanfragen und Response-Zeiten vergleichen; Timeouts vs. SERVFAIL unterscheiden.

Wichtige Unterscheidung: CoreDNS down vs. CoreDNS „degraded“

„Down“ bedeutet, dass CoreDNS nicht erreichbar ist (Pods crashen, Service-IP nicht routbar, NetworkPolicy blockt). „Degraded“ bedeutet, dass CoreDNS antwortet, aber langsam oder fehlerhaft – häufig durch Last, Upstream-Probleme oder Konfigurationsfehler. Für Incident Response ist diese Unterscheidung entscheidend, weil die Fixes unterschiedlich sind.

Down: Keine Antworten, DNS-Requests laufen in Timeouts; CoreDNS-Pods nicht Ready/CrashLoop; Service nicht erreichbar.
Degraded: Antworten kommen teilweise; erhöhte SERVFAIL/REFUSED-Raten; stark erhöhte Latenzen; sporadische Timeouts.

Root Causes: Die häufigsten Ursachen für CoreDNS-Ausfälle

CoreDNS-Probleme lassen sich grob in vier Klassen einteilen: Ressourcen/Skalierung, Netzwerk/Policies, Upstream-DNS sowie Konfiguration/Plugins. In der Praxis sind Mischformen häufig – etwa ein Upstream-Timeout, der zu Retries führt, die CoreDNS weiter überlasten.

Ressourcenengpass und fehlende Skalierung

CPU-Throttling: CoreDNS ist CPU-sensibel. Zu enge CPU-Limits führen zu hohen Latenzen und Timeouts.
Memory Pressure/OOM: Bei zu kleinem Memory-Limit kann CoreDNS OOMKill bekommen, besonders bei hohem Cache oder vielen gleichzeitigen Queries.
Zu wenig Replicas: Ein oder zwei CoreDNS-Pods reichen in großen Clustern oft nicht, insbesondere bei Burst-Last.
Node-Placement: Wenn CoreDNS auf wenigen Nodes konzentriert läuft und diese Nodes Probleme haben, entsteht ein Single Point of Pain.

DNS Storms: Explodierende Query-Raten aus Anwendungen

Hoher ndots-Wert: Viele Suchdomänen plus hoher ndots erzeugen mehrere Anfragen pro Lookup.
Retries ohne Backoff: Anwendungen oder Libraries retryen aggressive DNS-Lookups, wenn sie scheitern.
Short TTLs: Sehr kurze TTLs führen zu hoher Query-Rate, weil Caches wenig helfen.
Sidecar/Agent-Spam: Telemetrie-Agenten, Service Mesh oder Security-Scanner können DNS massiv belasten.

NetworkPolicy/Egress blockiert DNS

Default Deny ohne DNS-Exception: Pods dürfen nicht zu CoreDNS (UDP/TCP 53) sprechen.
Nur UDP erlaubt: Große DNS-Antworten oder bestimmte Fälle wechseln auf TCP; wenn TCP 53 geblockt ist, treten sporadische Fehler auf.
NamespaceSelector matcht nicht: Policies sollen DNS erlauben, matchen aber den CoreDNS-Namespace/Labels nicht.

Upstream-DNS ist langsam, down oder inkonsistent

VPC/VNet-Resolver Probleme: Cloud-DNS kann regional degradieren oder Limits erreichen.
On-Prem DNS über VPN/Direct Connect: Latenz, Packet Loss oder MTU-Probleme machen DNS instabil.
Split-Horizon/Conditional Forwarding: Falsch konfigurierte Zonen führen zu SERVFAIL oder NXDOMAIN.

CoreDNS-Konfigurationsfehler (Corefile) und Plugin-Fallen

Fehlerhafte Forwarder: Falsche IPs oder unreachable Resolver verursachen Timeouts.
Unpassende Timeouts: Zu kurze Timeouts erzeugen SERVFAIL, zu lange Timeouts blockieren Worker.
Cache falsch dimensioniert: Zu kleiner Cache bringt wenig, zu großer Cache kann Memory belasten.
Loop- und Rewrite-Probleme: Bestimmte Rewrite/Stubdomain-Setups können Schleifen erzeugen.

Debugging Step-by-Step: Vom Symptom zur Ursache

Das folgende Vorgehen ist so aufgebaut, dass Sie zuerst grob eingrenzen, dann zielgerichtet in die Tiefe gehen. Achten Sie darauf, pro Schritt nur eine Hypothese zu testen, damit Ursache und Wirkung klar bleiben.

Schritt 1: Ist DNS im Pod grundsätzlich erreichbar?

Nameserver-IP: Steht in /etc/resolv.conf die Cluster-DNS-IP (meist eine Service-IP)?
CoreDNS-Service erreichbar: Wenn möglich, testen Sie eine Verbindung zur Service-IP auf Port 53 (UDP/TCP). Wenn beides nicht geht, ist es oft Routing/Policy.
Unterscheiden: Interne Auflösung (kubernetes.default.svc) vs. externe Auflösung (z. B. example.com).

Schritt 2: CoreDNS-Pods: Ready, CrashLoop, Restart-Spikes?

Pod-Status: Läuft CoreDNS? Gibt es Restarts oder CrashLoopBackOff?
Logs: Suchen Sie nach Hinweisen wie Upstream timeouts, plugin errors, „panic“, „no route to host“.
Readiness/Health: Health-Endpunkte zeigen häufig, ob CoreDNS selbst intern blockiert oder überlastet ist.

Schritt 3: Metriken und Latenzen – ist es Last oder Netzwerk?

QPS: Wie viele Queries pro Sekunde? Plötzliche Spikes sprechen für DNS-Storms.
Antwortcodes: NXDOMAIN, SERVFAIL, REFUSED – jeder Code hat eine andere Aussage.
CPU/Memory: CPU nahe Limit, Throttling oder OOMKills sind harte Indikatoren für Ressourcenprobleme.

Schritt 4: NetworkPolicies prüfen (wenn nur manche Namespaces betroffen sind)

Default Deny? Wenn ja: Ist egress zu DNS explizit erlaubt?
UDP und TCP 53: Beide Protokolle berücksichtigen, insbesondere in gehärteten Umgebungen.
Ziel richtig selektiert: CoreDNS läuft meist in kube-system; Policies müssen diesen Namespace erreichen.

Schritt 5: Upstream-DNS testen (wenn nur externe Domains scheitern)

Von CoreDNS aus: Prüfen Sie, ob CoreDNS die Upstream-Resolver erreichen kann (Routing/Egress vom Node/Pod).
Alternative Resolver: Testweise einen bekannten, stabilen Resolver verwenden (nur wenn policy-konform) – als Diagnose, nicht als Dauerlösung.
Path-Probleme: VPN/Direct Connect/Firewall kann DNS-Pakete droppen oder fragmentieren (MTU).

Fixes: Schnelle Wiederherstellung und nachhaltige Stabilisierung

Ein guter Fix hat zwei Ebenen: Erstens „Restore Service“ (DNS wieder zuverlässig), zweitens „Prevent Recurrence“ (Ursache dauerhaft entschärfen). Im Incident ist oft zuerst Stabilität wichtiger als Perfektion – aber die Gegenmaßnahmen sollten nachvollziehbar und sicher bleiben.

Sofortmaßnahmen bei „CoreDNS down“

Replicas erhöhen: Mehr CoreDNS-Pods, um Last zu verteilen (besonders bei Burst-Lookups).
Ressourcen anpassen: CPU/Mem Requests/Limits so setzen, dass CoreDNS nicht throttled oder OOMt.
Pod-Neustart/rollout: Wenn CoreDNS in einem defekten Zustand hängt, kann ein kontrollierter Rollout helfen.
Node-Probleme umgehen: CoreDNS neu schedulen (z. B. durch Node-Drain der betroffenen Nodes) – wenn es node-spezifisch ist.

Nachhaltige Fixes gegen DNS-Storms und Latenzspitzen

ndots sinnvoll konfigurieren: Ein zu hoher Wert erzeugt unnötige Suchpfade und Queries.
Caching optimieren: Cache-Plugin nutzen und TTLs sinnvoll betrachten; Ziel ist weniger Upstream-Abhängigkeit.
Client-Verhalten verbessern: Anwendungen sollten DNS-Retries mit Backoff machen; aggressive Retry-Loops vermeiden.
Lastquellen identifizieren: Welche Deployments erzeugen die meisten Lookups? Oft sind es wenige „Top Talker“.

Fixes bei NetworkPolicy-Problemen

DNS-Exception definieren: Egress zu CoreDNS (UDP/TCP 53) und ggf. zu NodeLocal DNS (falls genutzt).
DNS über TCP berücksichtigen: Gerade bei großen Antworten, DNSSEC oder bestimmten Resolvern relevant.
Policies konsolidieren: Vermeiden Sie überlappende, widersprüchliche Policies, die Debugging erschweren.

Fixes bei Upstream-Problemen

Upstream-Redundanz: Mehrere Upstream-Resolver definieren (sofern konform), um Single Points zu vermeiden.
Stabiler Pfad: Bei On-Prem DNS über WAN/VPN Latenz und Loss reduzieren; MTU sauber einstellen.
Timeouts und Retries im Forwarding: Nicht zu aggressiv, nicht zu lax – so konfigurieren, dass CoreDNS nicht blockiert.

NodeLocal DNSCache: Wann es hilft und welche Failure Modes es hat

NodeLocal DNSCache (je nach Distribution/Setup) bringt DNS näher an den Node und kann Latenz senken sowie CoreDNS entlasten. Allerdings entsteht eine zusätzliche Komponente, die selbst ausfallen oder falsch geroutet sein kann. Wenn Sie NodeLocal einsetzen, müssen Sie ihn bewusst überwachen und in Policies berücksichtigen.

Vorteil: Weniger Hop-Latenz, weniger CoreDNS-Load, besseres Caching pro Node.
Risiko: Wenn NodeLocal nicht läuft oder falsch konfiguriert ist, sieht es aus wie „DNS kaputt“, obwohl CoreDNS gesund ist.
Policy-Aspekt: Pods sprechen dann ggf. zuerst NodeLocal an; Ihre DNS-Exceptions müssen dazu passen.

Observability: Telemetrie, die CoreDNS-Probleme früh sichtbar macht

DNS-Ausfälle eskalieren schnell. Gute Telemetrie erkennt nicht nur „DNS ist down“, sondern zeigt Vorboten: steigende Query-Raten, wachsende Latenzen, zunehmende SERVFAILs oder CPU-Throttling. Damit vermeiden Sie, dass DNS-Probleme erst als „App down“ auffallen.

DNS-Latenz: P95/P99 der Antwortzeiten, getrennt nach internen und externen Queries.
Antwortcodes: Anteil NXDOMAIN/SERVFAIL/REFUSED; plötzliche Veränderungen sind oft Root-Cause-Hinweise.
QPS/Top Domains: Welche Domains/Namespaces erzeugen Last? „Top Talker“ identifizieren.
Ressourcen: CPU Throttling, Memory, Restarts, OOMKills.
Upstream Health: Timeout-Raten und Response-Zeiten zum Upstream-Resolver.

Warum DNS-Latenz eine Multiplikatorwirkung hat

DNS sitzt im kritischen Pfad. Wenn jeder Request erst einen Lookup benötigt, multipliziert sich DNS-Latenz mit Ihrer Request-Rate. Ein scheinbar kleiner DNS-Delay kann große End-to-End-Latenzen und Timeouts erzeugen, insbesondere wenn Anwendungen mehrere Hostnames pro Request auflösen.

Zusatzlatenz = LookupsProRequest × DNS_Latenz

Prävention: Hardening-Checkliste für stabilen DNS-Betrieb

Ausreichende Replikas für CoreDNS, passend zur Clustergröße und erwarteten QPS.
Requests/Limits so setzen, dass CoreDNS nicht throttled; realistisch dimensionieren.
Pod-Affinity/Anti-Affinity nutzen, um CoreDNS auf mehrere Nodes/AZs zu verteilen.
Cache sinnvoll konfigurieren; TTLs und Memory-Budget im Blick behalten.
NetworkPolicies für DNS sauber und minimal definieren (UDP/TCP 53, Ziel korrekt selektiert).
Upstream-Redundanz und klarer Verantwortungsbereich (Cloud DNS vs. On-Prem DNS).
Client-Best-Practices: Retries mit Backoff, keine aggressiven DNS-Polling-Loops, vernünftige TTL-Nutzung.
Runbooks & Alerts: DNS-Latenz- und SERVFAIL-Alarme vor „App down“-Symptomen.

Outbound-Links zu relevanten Informationsquellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.