Runbook „Pod kann DNS nicht resolven“

Ein Runbook „Pod kann DNS nicht resolven“ ist in Kubernetes-Umgebungen eines der wertvollsten Standard-Runbooks überhaupt, weil DNS-Probleme extrem häufig auftreten, aber in sehr unterschiedlichen Formen. Ein Pod, der keine Namen auflösen kann, wirkt zunächst wie ein „Anwendungsfehler“: Requests laufen ins Timeout, Image Pulls scheitern, Healthchecks schlagen fehl, Service-to-Service-Kommunikation bricht sporadisch ab. In Wirklichkeit ist DNS ein Querschnittsthema aus mehreren Schichten: Pod-Konfiguration (resolv.conf, search domains), CoreDNS (Kapazität, Upstream, Cache), Netzwerkpfad (NetworkPolicy, CNI-Drops, MTU), Node-Subsysteme (Conntrack, IRQ/CPU-Saturation) und externe Abhängigkeiten (Upstream-Resolver, Firewall, Proxy). Ein gutes Runbook zwingt zu einem strukturierten Vorgehen, das schnell zwischen „lokales Pod-Problem“, „Namespace-Policy“, „CoreDNS-Outage“ und „Upstream-Problem“ trennt. Dieses Runbook ist bewusst so gestaltet, dass es Einsteigern klare Schrittfolgen gibt, aber auch Profis genug Tiefe bietet, um komplexe Failure-Modes zu entwirren. Ziel ist, in wenigen Minuten belastbar zu wissen: Wo liegt der Fehler, wie groß ist der Blast Radius und welche sichere Mitigation ist möglich, ohne blind an DNS oder Netzwerk herumzuschrauben.

Problemdefinition: Was bedeutet „kann DNS nicht resolven“ konkret?

Bevor Sie diagnostizieren, müssen Sie den Fehler sauber einordnen. DNS-Probleme haben unterschiedliche Symptome, die zu unterschiedlichen Ursachen passen. Sammeln Sie zuerst 2–3 konkrete Beispiele (Pod/Namespace, Zielname, Zeitpunkt, Fehlermeldung) und ordnen Sie sie grob ein.

• Timeouts: „i/o timeout“, „context deadline exceeded“, „DNS query timed out“
• SERVFAIL: Resolver antwortet, kann aber nicht erfolgreich auflösen
• NXDOMAIN: Name existiert laut Resolver nicht (kann echt sein oder durch falsche Search Domains entstehen)
• Refused/No response: häufig Policy/Firewall/Port-Block oder CoreDNS nicht erreichbar
• Intermittierend: nur unter Last, nur auf bestimmten Nodes oder nur in bestimmten Namespaces

DNS-Grundlagen im Kubernetes-Kontext, insbesondere wie Services und Pods aufgelöst werden, finden Sie hier: DNS for Services and Pods.

Schnellcheck: Blast Radius feststellen

Der wichtigste frühe Schritt ist die Frage: Ist das Problem pod-spezifisch, namespace-spezifisch, node-spezifisch oder clusterweit? Das bestimmt, ob Sie lokal mitigieren können oder sofort eskalieren müssen.

• Nur ein Pod betroffen: eher Pod-Konfiguration, Pod-Netzwerkpfad, Sidecar, lokale DNS-Settings
• Nur ein Namespace betroffen: häufig NetworkPolicy/Egress-Regeln, DNS-Policy, ServiceAccount/Admission
• Nur bestimmte Nodes betroffen: Node-Netzwerk (CNI, conntrack, IRQ/CPU, iptables), lokale Drops
• Clusterweit: CoreDNS-Outage, Upstream-Resolver, zentrale Firewall/Proxy, Plattform-Change

Praktischer Minimaltest: Starten Sie in einem betroffenen Namespace und in einem bekannten „guten“ Namespace jeweils einen Debug-Pod und testen Sie denselben FQDN. Wenn nur ein Namespace scheitert, ist das ein sehr starkes Policy-/Konfigurationssignal.

Schritt 1: In-Pod-Prüfung – resolv.conf, DNS-Policy und Search Domains

Viele DNS-Probleme sind nicht „CoreDNS kaputt“, sondern falsche oder unerwartete Resolver-Konfiguration im Pod. Prüfen Sie deshalb zuerst die DNS-Konfiguration des betroffenen Pods.

• /etc/resolv.conf: Welche nameserver stehen drin? Welche search domains? Welche options (ndots)?
• dnsPolicy: ClusterFirst, Default, None – passt das zum erwarteten Verhalten?
• dnsConfig: Wurden custom nameserver/search/options gesetzt, die CoreDNS umgehen?
• ndots: Ein zu hoher ndots-Wert kann zu vielen Suchanfragen führen und Timeouts verstärken.

Typischer Fehler: Ein Pod nutzt durch dnsPolicy=Default den Node-Resolver und umgeht CoreDNS, während andere Pods korrekt über ClusterFirst laufen. Das kann „nur ein Pod hat DNS-Probleme“ erklären, obwohl CoreDNS gesund ist.

Suchdomain-Fallen: Warum NXDOMAIN manchmal „selbst gemacht“ ist

Wenn Anwendungen Namen ohne Punkt auflösen (z. B. „api“ statt „api.default.svc.cluster.local“), hängt das Ergebnis stark von search domains und ndots ab. Der Resolver probiert dann mehrere Varianten, was unter Last zu Verzögerungen führen kann. Ein Indikator ist eine hohe Zahl DNS-Queries pro Request oder auffällig viele NXDOMAIN-Antworten, bevor die korrekte Auflösung gelingt.

Schritt 2: Erreichbarkeit von CoreDNS prüfen (Netzwerkpfad im Cluster)

Wenn die Pod-Konfiguration plausibel ist, prüfen Sie als nächstes, ob der Pod CoreDNS überhaupt erreicht. Das ist häufig die Trennlinie zwischen „DNS-Server/Upstream“ und „Netzwerk/Policy“. CoreDNS läuft meist als Service (z. B. kube-dns) im Namespace kube-system.

• Service-IP erreichbar? Kann der Pod die ClusterIP des DNS-Services erreichen?
• UDP/TCP 53: Wird UDP/53 blockiert? Greift TCP-Fallback und ist TCP/53 erlaubt?
• Namespace-Policies: Gibt es NetworkPolicies, die Egress zu kube-system oder zum DNS-Service blocken?
• NodeLocal DNSCache: Falls eingesetzt: erreicht der Pod die lokale Cache-IP und ist diese gesund?

Viele NetworkPolicies erlauben Egress nur zu „app-internen“ Zielen und vergessen DNS. Das wirkt dann wie „Internet kaputt“, ist aber eine Policy-Lücke. Grundlagen zu NetworkPolicies: Kubernetes Network Policies.

Schritt 3: CoreDNS-Health – Kapazität, Errors, Latenz, Restarts

Wenn CoreDNS erreichbar ist, muss geprüft werden, ob CoreDNS korrekt antwortet und ob es unter Last stabil ist. DNS-Probleme sind häufig Kapazitäts- oder Upstream-Probleme, die erst bei Peaks auftreten.

• Pods Ready? Sind alle CoreDNS-Pods Ready und stabil (keine CrashLoops, keine ständigen Restarts)?
• CPU/Memory: Läuft CoreDNS an Limits oder wird es gedrosselt?
• Query-Latenz: P95/P99 steigt? Timeouts nehmen zu?
• Error-Klassen: SERVFAIL/REFUSED steigt? NXDOMAIN ungewöhnlich hoch?
• Cache-Hit-Rate: Niedrige Cache-Hits können Upstream überlasten und Latenz erhöhen.

Wenn Sie Metriken nutzen, sind das typische Pflichtsignale. Auch ohne Metriken gilt: Restarts und hohe CPU sind oft bereits ein klares Signal für Überlast oder Fehlkonfiguration. Für CoreDNS-Konfigurationsprinzipien ist die Projektseite hilfreich: CoreDNS Manual.

Kapazitätsindikator: Query Rate pro CoreDNS-Pod

Eine einfache, operational nützliche Betrachtung ist „Queries pro Sekunde pro CoreDNS-Pod“. Wenn die Last steigt, ohne dass skaliert wird, kippt Latenz zuerst, dann kommen Timeouts. Als grobe Kennzahl:

$\mathrm{QPS\_pro\_Pod}=\frac{\mathrm{DNS\_Queries\_pro\_Sekunde}}{\mathrm{Anzahl\_CoreDNS\_Pods}}$

Der absolute Grenzwert hängt stark von Umgebung und Query-Mix ab, aber die Relation hilft, Skalierungsbedarf sichtbar zu machen.

Schritt 4: Upstream-Resolver und externe Abhängigkeiten prüfen

CoreDNS ist selten die letzte Station. Für externe Namen (z. B. api.example.com) hängt CoreDNS am Upstream (VPC/VNet DNS, Unternehmensresolver, Public DNS via Firewall/Proxy). Wenn Upstream langsam oder blockiert ist, sehen Pods DNS-Probleme, obwohl CoreDNS „läuft“.

• Nur externe FQDNs betroffen? Interne Cluster-Namen funktionieren, externe nicht → Upstream/Egress/Firewall wahrscheinlich.
• Firewall/Proxy-Regeln: Ist UDP/TCP 53 nach außen erlaubt? Gibt es DNS-Inspection oder Rate-Limits?
• Split-Horizon DNS: Unterschiedliche Antworten je nach Quelle, oft in Unternehmensnetzen.
• EDNS/UDP-Größe: Große DNS-Antworten können bei MTU/Fragment-Blockaden scheitern.

Wenn EDNS/Fragmentierung eine Rolle spielt, ist es typisch, dass „kleine“ DNS-Antworten funktionieren, große aber timeouten. Das ist ein klassischer Hinweis auf MTU/ICMP/Fragment-Filterung.

Schritt 5: Node-spezifische Ursachen – Conntrack, IRQ/CPU und Drops

Wenn DNS-Probleme nur auf bestimmten Nodes auftreten oder unter Last intermittierend sind, liegt die Ursache oft auf Node-Ebene. DNS ist besonders empfindlich, weil es häufig UDP nutzt (keine Retransmits wie TCP) und weil viele kleine Pakete schnell hohe Paketlast erzeugen.

• Conntrack-Pressure: Wenn NAT/Conntrack überläuft, können UDP-Flows droppen, DNS wirkt „weg“.
• IRQ/CPU-Saturation: SoftIRQ-Spitzen können UDP-Pakete verlieren; DNS-Timeouts steigen.
• Interface Drops: RX drops/discards können genau DNS treffen, wenn die Paketrate hoch ist.
• CNI-Datapath: eBPF/iptables-Regeln oder Encapsulation können Node-spezifisch fehlschlagen.

Ein gutes Signal ist TCP-Retransmits plus DNS-Timeouts plus erhöhte softirq/irq CPU auf denselben Nodes. Dann ist „DNS kaputt“ nur das Symptom eines Node-Engpasses.

Schritt 6: Häufige Konfigurationsfehler, die DNS gezielt brechen

Einige Fehlerbilder tauchen so oft auf, dass sie in jedes Runbook gehören. Prüfen Sie diese Punkte gezielt, bevor Sie tiefer in Spezialanalysen gehen:

• NetworkPolicy blockt UDP/53: Egress erlaubt nur TCP/443, DNS vergessen.
• kube-dns Service falsch geroutet: Endpoints fehlen, Service zeigt auf falsche Selector-Labels.
• CoreDNS ConfigMap geändert: forward-Target falsch, loop, falsche StubDomains, fehlerhafte rewrite-Regeln.
• NodeLocal DNSCache halb aktiv: Daemon läuft auf manchen Nodes nicht, Pods zeigen aber auf lokale IP.
• Falsche dnsPolicy in Workloads: Default statt ClusterFirst, besonders bei hostNetwork oder speziellen Daemonsets.
• Search Domains/ndots unpassend: Query-Stürme durch unnötige Suchvarianten.
• MTU/Fragment-Blockade: Große DNS-Antworten scheitern, vor allem bei DNSSEC/EDNS.

Schritt 7: Sichere Mitigation – stabilisieren, ohne neue Risiken einzubauen

Mitigation hängt vom Blast Radius ab. Ziel ist, die Plattform zu stabilisieren, während Sie die Root Cause weiter eingrenzen. Maßnahmen sollten so gewählt sein, dass sie reproduzierbar und rückgängig zu machen sind.

• Wenn nur ein Namespace betroffen: NetworkPolicy-DNS-Egress ergänzen (UDP/TCP 53 zum DNS-Service oder NodeLocal).
• Wenn CoreDNS überlastet: CoreDNS replizieren/skalieren, Ressourcen erhöhen, Cache sinnvoll konfigurieren.
• Wenn Upstream langsam: CoreDNS Cache-TTLs prüfen, Upstream-Pfade stabilisieren, Egress-Regeln verifizieren.
• Wenn Node-spezifisch: betroffene Nodes isolieren (cordon/drain), Workloads verlagern, Nodepool-Health prüfen.
• Wenn MTU/EDNS-Problem: ICMP/PMTUD erlauben, MTU konsistent machen, falls nötig EDNS-Size anpassen.

Wichtig: „DNS-Server wechseln“ oder „random resolver“ ist selten eine saubere Mitigation im Cluster und kann Governance und Auditability verschlechtern. Besser sind gezielte, kontrollierte Änderungen am DNS-Pfad.

Schritt 8: Postmortem-Daten sichern – damit das Problem nicht wiederkommt

DNS-Probleme wiederholen sich gern, weil Teams nur „es geht wieder“ feststellen, aber nicht die Ursache absichern. Sammeln Sie deshalb standardisiert:

• Zeitraum und Korrelation: Wann begannen Timeouts? Welche Deployments/Changes liefen?
• Betroffene Dimensionen: Namespace, Nodepool, Zone, nur externe oder auch interne Namen.
• Metriken: CoreDNS QPS/Latenz/Errors, Node conntrack, irq/softirq, drops/retransmits.
• Konfiguration: CoreDNS ConfigMap (Version), NetworkPolicies, dnsPolicy/dnsConfig der betroffenen Workloads.
• Mitigation und Wirkung: Welche Maßnahme hat stabilisiert und wie schnell?

Minimal-Runbook als kompakte Schrittfolge

• Blast Radius: Pod vs. Namespace vs. Node vs. clusterweit klären
• Pod DNS Config: resolv.conf, dnsPolicy, search/ndots prüfen
• CoreDNS Reachability: UDP/TCP 53 erreichbar? Policy blockt?
• CoreDNS Health: Restarts, CPU, Latenz, Errors, Cache
• Upstream: nur externe Namen betroffen? Firewall/Resolver/EDNS prüfen
• Node Ursachen: conntrack, irq/softirq, drops/retransmits korrelieren
• Mitigation: gezielt stabilisieren (Policy fix, CoreDNS skalieren, Nodes isolieren)

Outbound-Quellen für vertiefende Informationen

• DNS for Services and Pods: Kubernetes-DNS-Verhalten und Konfiguration
• Kubernetes Network Policies: Egress/Ingress-Kontrolle und DNS-Freigaben
• CoreDNS Manual: Plugins, Forwarding, Cache und typische Konfigurationsmuster
• Kubernetes Networking Concepts: Netzwerkpfade und Fehlerklassen im Cluster

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.