Runbook „Pod kann DNS nicht resolven“: Ursachen + schnelle Fixes

Wenn ein Pod DNS nicht resolven kann, wirkt das Problem auf den ersten Blick banal („Name lookup failed“), ist in der Praxis aber oft ein Symptom für tieferliegende Störungen im Cluster-Netzwerk, in CoreDNS oder in der Egress-Konnektivität. In Kubernetes hängt fast jede Abhängigkeit indirekt an DNS: Service Discovery innerhalb des Clusters, Zugriff auf externe APIs, Container-Registries, Observability-Backends und häufig auch Authentifizierung (OIDC, OAuth, STS-Endpunkte). Deshalb ist ein DNS-Ausfall für einzelne Pods oder ganze Namespaces ein klassischer „High-Impact“-Incident. Dieses Runbook führt Sie Schritt für Schritt durch Ursachen, schnelle Fixes und valide Prüfungen – von der Pod-Ebene (resolv.conf, DNSPolicy, NetworkPolicy) über den Cluster-DNS (CoreDNS, kube-dns Service, NodeLocal DNSCache) bis hin zum Underlay/Egress (NAT, Firewall, Route Tables). Ziel ist, innerhalb weniger Minuten einzugrenzen, ob es sich um ein lokales Problem (ein Pod/ein Node/ein Namespace) oder um ein systemisches Problem (CoreDNS/Netzwerk/Upstream-Resolver) handelt, und zugleich schnelle, risikoarme Mitigations bereitzuhalten.

Symptome und erste Einordnung (Impact bestimmen)

Beginnen Sie immer damit, den Scope zu bestimmen: Betrifft es nur einen Pod, einen Namespace, alle Pods auf einem Node oder den gesamten Cluster? DNS-Probleme lassen sich oft anhand typischer Fehlermeldungen unterscheiden.

• „Temporary failure in name resolution“: DNS-Server nicht erreichbar, Timeout oder Upstream-Probleme.
• „NXDOMAIN“: Name existiert nicht oder Suchdomänen/Namespace-Kontext ist falsch.
• „SERVFAIL“: Resolver konnte Anfrage nicht korrekt beantworten (Upstream, CoreDNS-Plugins, DNSSEC, Ressourcenmangel).
• Intermittent: Sporadische Timeouts deuten häufig auf Überlast (CoreDNS/Node), conntrack-Druck, Drops oder MTU/Fragmentation hin.

Notieren Sie außerdem, ob nur Cluster-intern (z. B. Service-Namen) betroffen sind oder auch extern (z. B. api.github.com). Das ist ein sehr schneller Hinweis darauf, ob das Problem bei CoreDNS selbst oder bei dessen Upstream-/Egress-Pfad liegt.

Schnelltest: DNS direkt im betroffenen Pod prüfen

Führen Sie im betroffenen Pod einen minimalen Check aus. Wenn der Pod keine Shell oder Tools hat, nutzen Sie einen temporären Debug-Pod im gleichen Namespace und (wenn möglich) auf dem gleichen Node.

• Auflösung eines Service-Namens: z. B. kubernetes.default.svc.cluster.local
• Auflösung eines externen Namens: z. B. example.com
• Direkte Abfrage des DNS-Servers aus /etc/resolv.conf (statt über Suchdomänen)

Interpretation der Ergebnisse

• Interne Namen failen, externe gehen: Häufig Service/Cluster-DNS-Konfiguration, kube-dns Service oder CoreDNS.
• Interne gehen, externe failen: Meist Upstream-Resolver, Egress/Firewall/NAT oder CoreDNS-Forwarding.
• Beides failt: DNS-Server nicht erreichbar, NetworkPolicy blockt UDP/TCP 53 oder Node-/CNI-Problem.

Prüfen: /etc/resolv.conf und DNSPolicy im Pod

Viele DNS-Probleme entstehen nicht durch CoreDNS, sondern durch falsche Pod-Konfiguration. Prüfen Sie im Pod die Datei /etc/resolv.conf und die DNSPolicy im PodSpec.

• nameserver: Zeigt auf die Cluster-DNS-IP (typisch kube-dns Service ClusterIP). Wenn hier eine falsche IP steht, ist Auflösung praktisch unmöglich.
• search: Enthält die erwarteten Suchdomänen (z. B. <namespace>.svc.cluster.local).
• options: ndots kann die Anzahl der Suchversuche beeinflussen; hohe Werte verursachen mehr Queries und Latenz.

Häufige Fehlkonfigurationen und schnelle Fixes

• DNSPolicy falsch (Default ist ClusterFirst): Wenn dnsPolicy: Default gesetzt ist, nutzt der Pod Node-DNS statt Cluster-DNS. Schneller Fix: dnsPolicy: ClusterFirst (oder bei HostNetwork: ClusterFirstWithHostNet).
• dnsConfig überschreibt falsche Server: Manchmal werden externe Nameserver hart gesetzt, die aus dem Cluster nicht erreichbar sind. Schneller Fix: dnsConfig entfernen oder Cluster-DNS als primären nameserver setzen.
• ndots zu hoch: Bei vielen kurzen Namen kann ndots:5 eine Query-Flut erzeugen. Schneller Fix: In kritischen Fällen ndots reduzieren (mit Vorsicht und Tests).

Hintergrund zu Kubernetes DNS und Pod DNSPolicy finden Sie in der offiziellen Dokumentation: DNS for Services and Pods.

Prüfen: Ist der Cluster-DNS-Service erreichbar?

Als nächstes prüfen Sie, ob der Pod die Cluster-DNS-IP überhaupt erreichen kann. Typischerweise ist das der Service kube-dns im Namespace kube-system. Wenn der Service oder die Endpoints fehlen, kann kein Pod korrekt resolven.

• kube-dns Service existiert? ClusterIP notieren.
• Endpoints vorhanden? Zeigen sie auf CoreDNS-Pods (IP:Port 53/9153 je nach Setup).
• Connectivity: UDP 53 und TCP 53 erreichbar (TCP wichtig für große Antworten/Truncation).

Schnelle Fixes bei Service-/Endpoint-Problemen

• Keine Endpoints: CoreDNS-Pods down oder nicht ready. Sofort: CoreDNS Deployment/DaemonSet prüfen und Pods restart/rollout.
• Service zeigt auf falsche Selector-Labels: Nach Änderungen an Labels/Charts möglich. Sofort: Service Selector korrigieren oder CoreDNS Labels anpassen.
• NetworkPolicy blockt DNS: Temporär eine Allow-Policy für UDP/TCP 53 zum kube-dns Service (Scope so klein wie möglich).

CoreDNS selbst prüfen: Health, Logs und typische Failure Modes

CoreDNS ist der Standard-DNS-Server in vielen Kubernetes-Distributionen. Wenn CoreDNS überlastet ist, falsch konfiguriert wurde oder der Upstream nicht erreichbar ist, äußert sich das oft als Timeout, SERVFAIL oder stark erhöhte Latenz.

CoreDNS Health-Checks

• Pods Ready? Readiness/Liveness-Probes ok.
• Ressourcen: CPU throttling, Memory pressure, OOMKills.
• Logs: Häufige Fehler wie „plugin/forward“, „i/o timeout“, „no route to host“.
• QPS-Spikes: Plötzliche Query-Flut (z. B. durch ndots, CrashLooping Apps, aggressive Retries).

CoreDNS ConfigMap: Was ist kritisch?

Die CoreDNS-Konfiguration (Corefile) entscheidet, wie Anfragen intern aufgelöst und extern weitergeleitet werden. Typische Stolpersteine:

• forward: Upstream-Resolver falsch, nicht erreichbar oder zu langsam.
• cache: Zu kleiner Cache kann Last erhöhen, zu aggressives Caching kann „stale“ Antworten liefern.
• max_concurrent (bei forward): Zu niedrige Parallelität kann Queues erzeugen, zu hoch kann Upstream überfahren.
• log/errors: Hilfreich für Troubleshooting, kann unter hoher Last aber zusätzliche I/O erzeugen.

Weitere Details zur CoreDNS-Konfiguration finden Sie in der offiziellen Dokumentation: CoreDNS Manual.

Upstream-DNS und Egress: Wenn externe Domains nicht auflösbar sind

Wenn interne Service-Namen funktionieren, externe Domains aber nicht, liegt das Problem häufig außerhalb von CoreDNS: Der Resolver kann seine Upstream-Server nicht erreichen, oder Egress-Traffic wird eingeschränkt.

• Upstream-Resolver erreichbar? (z. B. VPC/VNet Resolver, Corporate DNS, öffentliche Resolver)
• Egress-Policies: NetworkPolicy, egress firewall, cloud security controls, proxy requirements.
• NAT/Route: NAT Gateway, egress gateway, route tables, private endpoints.

Schnelle Fixes, ohne Dependencies zu brechen

• Temporär zweiten Upstream hinzufügen: Wenn Ihr Setup es erlaubt, kann ein redundanter Upstream Resolver Stabilität erhöhen (mit Governance und Security-Abstimmung).
• Egress für DNS explizit erlauben: UDP/TCP 53 zu den Upstream-Resolvern, idealerweise restriktiv über IPs/Ports.
• Wenn ein Proxy Pflicht ist: DNS kann nicht „über HTTP-Proxy“ funktionieren. Prüfen Sie, ob Ihre Umgebung interne Resolver bereitstellt, die erreichbar sind.

NetworkPolicy, CNI und „DNS wird geblockt“

Ein sehr häufiger Grund, warum ein Pod DNS nicht resolven kann, sind NetworkPolicies. Besonders bei „default deny egress“ wird DNS oft vergessen. Dazu kommt: DNS nutzt in der Regel UDP 53, fällt aber bei großen Antworten auf TCP 53 zurück. Wenn nur UDP erlaubt ist, gibt es intermittierende Fehler (besonders bei großen TXT-Records, DNSSEC oder vielen A/AAAA-Records).

• Prüfen, ob Egress-Policies aktiv sind (Namespace-Level, Pod-Selector).
• DNS-Pfade erlauben: UDP 53 und TCP 53 zum kube-dns Service und ggf. zu Upstream-Resolvern (wenn direkte Auflösung genutzt wird).
• FQDN-Policies: Einige CNIs unterstützen FQDN-basiertes Egress, andere nicht oder nur eingeschränkt.

Schneller Fix: Minimal-Policy für DNS

Wenn Sie kurzfristig mitigieren müssen, ist eine gezielte Allow-Policy für DNS oft der schnellste und sicherste Schritt. Achten Sie darauf, den Scope klein zu halten (Namespace, Labels) und danach sauber zu härten.

• Allow zu kube-dns ClusterIP auf UDP/TCP 53
• Optional: Allow zu NodeLocal DNSCache IP, falls genutzt
• Beobachten: Nach dem Fix sollten DNS-Timeouts und App-Fehler unmittelbar sinken

Node-spezifische Ursachen: Warum DNS nur auf manchen Nodes ausfällt

Wenn DNS-Probleme nur Pods auf bestimmten Nodes betreffen, ist die Wahrscheinlichkeit hoch, dass es sich um ein Node- oder CNI-spezifisches Problem handelt. Häufige Ursachen sind conntrack pressure, iptables-Regeln, Drops oder Ressourcenengpässe.

• conntrack nahe Limit: Neue UDP-Flows werden gedroppt, DNS bricht zuerst.
• CPU/SoftIRQ Overload: Paketverarbeitung stockt, UDP-Timeouts nehmen zu.
• iptables/nftables Drift: Regeln inkonsistent, kube-proxy/CNI-Regeln kollidieren.
• NodeLocal DNSCache Inkonsistenz: Cache-Pod down oder falsch konfiguriert, aber Pods zeigen darauf.

Schnelle Fixes auf Node-Ebene

• Pods evakuieren: Betroffenen Node cordon/drain (kontrolliert) und Workloads umplanen.
• CoreDNS Spread erhöhen: Mehr Replikas oder Anti-Affinity, damit nicht zu viele DNS-Anfragen auf wenige Nodes konzentriert sind.
• conntrack entlasten: Ursache finden (Retry Storm, NAT-Churn), Limits und Timeouts prüfen (mit Vorsicht und Change-Management).

Skalierungs- und Lastprobleme: DNS-Überlast erkennen und entschärfen

DNS-Ausfälle sind oft Lastsymptome. Eine einzelne Fehlkonfiguration (z. B. zu hohe ndots-Werte, aggressive Retries, CrashLooping Deployments) kann CoreDNS und Upstream-Resolver in Sekunden überfordern. Typisch ist dann: DNS wird langsam, Apps retryen, Last steigt weiter – ein negativer Kreislauf.

Pragmatische Last-Indikatoren

• CoreDNS CPU steigt stark und bleibt oben, während Query-Latenz steigt.
• Upstream timeouts in CoreDNS-Logs (forward).
• QPS-Anstieg ohne Traffic-Anstieg der eigentlichen Applikation (Hinweis auf Retry Storm).

Schnelle Fixes bei Überlast

• CoreDNS horizontal skalieren: Replikas erhöhen (sofern Control Plane/Nodes Kapazität haben).
• NodeLocal DNSCache aktivieren: Reduziert Latenz und Last auf CoreDNS, besonders bei großen Clustern (vorher testen).
• Caching optimieren: Cache-Plugin sinnvoll konfigurieren (nicht blind erhöhen, sondern anhand Query-Profile).
• Query-Generator stoppen: CrashLooping Workloads, fehlerhafte Health Checks oder aggressive Retry-Clients identifizieren.

Eine Einführung zu NodeLocal DNSCache und DNS-Architektur kann über die Kubernetes-Dokumentation und ergänzende Ressourcen erfolgen, z. B. über das DNS-Konzeptkapitel: Kubernetes Networking Concepts.

MTU, Fragmentation und „DNS geht manchmal“

DNS wirkt klein, aber es gibt Situationen, in denen Antworten groß werden: viele A/AAAA-Records, große TXT-Records, DNSSEC, oder wenn Antworten „truncated“ sind und TCP-Fallback benötigt wird. Wenn UDP-Fragmente gedroppt werden oder TCP 53 geblockt ist, entsteht ein intermittierendes Fehlerbild.

• Symptom: Kleine Domains gehen, bestimmte Domains (mit großen Antworten) fehlschlagen.
• Typische Ursachen: MTU-Mismatch (Overlay/Underlay), Fragmentation wird gedroppt, TCP 53 nicht erlaubt.
• Schneller Fix: TCP 53 zusätzlich zu UDP 53 erlauben; MTU-Settings und Encapsulation prüfen.

Validierung nach dem Fix: Nachweisbar „grün“ werden

Nach jeder Mitigation sollten Sie nicht nur „es funktioniert wieder“ feststellen, sondern messbar verifizieren, dass sich die Lage stabilisiert. Nutzen Sie ein paar wiederholbare Checks und, wenn verfügbar, Metriken.

• Reproduzierbarer Test: Interne und externe Namensauflösung mehrfach ausführen (auch mit „großen“ Antworten).
• CoreDNS-Metriken: Latenz (P95/P99), error codes, forward timeouts.
• App-Signale: Rückgang von Timeouts, 5xx, Retry-Raten.

Einfacher Stabilitätsindikator über Fehlerrate

$\mathrm{dns\_error\_rate}=\frac{\mathrm{dns\_errors}}{\mathrm{dns\_queries}}$

Auch wenn Sie diese Rate nicht exakt messen können, hilft die Logik: Nach dem Fix sollte die Fehlerrate (Timeouts/SERVFAIL) deutlich sinken und die Latenz stabil bleiben.

„Cheat Sheet“: Häufigste Ursachen und schnellster Fix

• NetworkPolicy blockt DNS: Allow UDP/TCP 53 zu kube-dns (und ggf. Upstream).
• CoreDNS nicht ready / keine Endpoints: CoreDNS Deployment prüfen, Pods restart/rollout, Ressourcen erhöhen.
• Externe Domains failen, interne ok: Upstream-Resolver/Egress prüfen, forward-Timeouts in Logs, Egress-Freigaben.
• Nur bestimmte Nodes betroffen: Node drain/evakuieren, conntrack und Drops prüfen, iptables drift checken.
• Intermittent bei bestimmten Domains: TCP 53 fehlt oder MTU/Fragmentation-Probleme; TCP erlauben und MTU prüfen.
• „dnsPolicy: Default“ versehentlich: Auf ClusterFirst korrigieren, dnsConfig prüfen.

Prävention: Damit „Pod kann DNS nicht resolven“ seltener passiert

DNS-Probleme sind oft Wiederholungstäter. Mit einigen Baselines und Standards reduzieren Sie die Häufigkeit deutlich.

• Standard-Policies: Eine geprüfte, minimale DNS-Allow-Policy als Baustein für Namespaces mit „default deny“.
• CoreDNS-Kapazitätsplanung: Replikas, Requests/Limits, Anti-Affinity, autoscaling (wo sinnvoll).
• NodeLocal DNSCache: In großen Clustern als Lastpuffer – aber nur mit sauberem Rollout und Monitoring.
• Observability: DNS-Latenz und Errors als First-Class-Signal (nicht erst bei App-Timeouts reagieren).
• Change-Disziplin: Änderungen an CNI, iptables/nftables, NetworkPolicy oder DNS-Konfiguration immer mit Canary und Post-Checks.

Wenn Sie eine saubere Referenz für DNS- und Service-Discovery-Grundlagen benötigen, sind die Kubernetes-DNS-Konzepte der beste Startpunkt: DNS for Services and Pods. Für tiefergehende Resolver-Details und Plugin-Verhalten ist das CoreDNS-Handbuch sehr hilfreich: CoreDNS Manual.

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.