TL;DR

DNS-Fehler in Kubernetes liegen meist an falsch konfigurierten ndots-Werten, überlasteten CoreDNS-Pods oder fehlerhaften Corefile-Einträgen. Mit einem Debug-Pod, CoreDNS-Logging und gezielter ndots-Anpassung lassen sich 90% der DNS-Probleme in Minuten lösen. Dieser Guide zeigt die systematische Fehlersuche.

DNS-Debugging in Kubernetes mit CoreDNS

Wenn Pods keine Services erreichen, externe APIs nicht auflösen oder Startzeiten unerklärlich lang sind — die Ursache ist überraschend oft DNS. CoreDNS ist die zentrale Komponente für Namensauflösung in jedem Kubernetes-Cluster, und Fehlkonfigurationen wirken sich auf alle Workloads aus.

CoreDNS-Status prüfen

Bevor du tiefer einsteigst, prüfe den Grundzustand:

# CoreDNS-Pods und ihre Verteilung
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide

# Läuft der CoreDNS-Service?
kubectl get svc -n kube-system kube-dns

# Ressourcenverbrauch prüfen
kubectl top pods -n kube-system -l k8s-app=kube-dns

Ein häufiges Problem: CoreDNS läuft mit nur 2 Replicas, der Cluster hat aber 200+ Pods. Jeder DNS-Request geht über diese zwei Pods. Das führt zu Timeouts unter Last.

Der Debug-Pod: Dein wichtigstes Werkzeug

Starte einen Pod mit DNS-Tools, um Auflösungen direkt zu testen:

# Debug-Pod starten
kubectl run dns-debug --image=registry.k8s.io/e2e-test-images/agnhost:2.39 \
  --restart=Never -- sleep infinity

# DNS-Auflösung testen
kubectl exec dns-debug -- nslookup kubernetes.default
kubectl exec dns-debug -- nslookup google.com

# Detaillierte DNS-Abfrage mit dig
kubectl exec dns-debug -- dig +search +short kubernetes.default.svc.cluster.local
kubectl exec dns-debug -- dig +trace google.com

Wenn nslookup kubernetes.default fehlschlägt, ist CoreDNS selbst das Problem. Wenn nur externe Domains scheitern, liegt es an der Upstream-DNS-Konfiguration.

Die häufigsten DNS-Probleme

Problem 1: NXDOMAIN bei Service-Auflösung

Der Pod kann einen Service im selben Namespace nicht finden.

# Fehlerbild
kubectl exec dns-debug -- nslookup my-service
# Server:    10.96.0.10
# ** server can't find my-service: NXDOMAIN

Ursache ist meistens der Namespace. Kubernetes DNS löst Service-Namen nur innerhalb des eigenen Namespaces ohne Suffix auf. Über Namespace-Grenzen hinweg brauchst du den FQDN:

# Funktioniert nur im selben Namespace
nslookup my-service

# Cross-Namespace: FQDN verwenden
nslookup my-service.other-namespace.svc.cluster.local

Problem 2: Langsame DNS-Auflösung durch ndots

Die ndots-Einstellung in /etc/resolv.conf bestimmt, wann Kubernetes die Search-Domains anhängt. Der Standard ist ndots:5 — das bedeutet: jeder Name mit weniger als 5 Punkten wird erst mit allen Search-Domains probiert.

# resolv.conf im Pod anschauen
kubectl exec dns-debug -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

Bei einem Request an api.example.com (2 Punkte, weniger als 5) probiert Kubernetes:

1. api.example.com.default.svc.cluster.local — NXDOMAIN
2. api.example.com.svc.cluster.local — NXDOMAIN
3. api.example.com.cluster.local — NXDOMAIN
4. api.example.com — Treffer

Das sind 3 unnötige DNS-Queries pro Request. Fix: ndots im Pod-Spec anpassen oder FQDNs mit abschließendem Punkt verwenden.

apiVersion: v1
kind: Pod
metadata:
  name: optimized-app
spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"
  containers:
    - name: app
      image: my-app:latest

Problem 3: DNS-Timeouts unter Last

Wenn CoreDNS unter Last Timeouts produziert, hilft Skalierung und Node-Local-DNS-Cache.

# CoreDNS skalieren
kubectl scale deployment coredns -n kube-system --replicas=4

# Aktuelle Last prüfen
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 | grep -i "error\|timeout\|overflow"

Die Corefile verstehen und optimieren

Die Corefile ist die zentrale CoreDNS-Konfiguration. Sie steckt in einer ConfigMap:

kubectl get configmap coredns -n kube-system -o yaml

Eine typische Corefile sieht so aus:

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}

Corefile-Optimierungen

DNS-Logging aktivieren für Debugging:

kubectl edit configmap coredns -n kube-system

.:53 {
    log          # <-- Logging aktivieren (temporär!)
    errors
    health {
        lameduck 5s
    }
    # ... rest bleibt gleich
}

Nach dem Speichern die CoreDNS-Pods neustarten:

kubectl rollout restart deployment coredns -n kube-system

# Logs beobachten
kubectl logs -n kube-system -l k8s-app=kube-dns -f --tail=50

Cache-TTL erhöhen für weniger Upstream-Queries:

cache 60 {
    success 9984 60
    denial 9984 10
}

Spezifische Upstream-DNS für bestimmte Domains:

example.internal:53 {
    forward . 10.0.0.53 10.0.0.54
    cache 120
}

Das ist nützlich, wenn interne Domains über eigene DNS-Server aufgelöst werden müssen.

NodeLocal DNSCache

Für Cluster mit hohem DNS-Aufkommen ist NodeLocal DNSCache die effektivste Optimierung. Ein DaemonSet platziert einen DNS-Cache auf jedem Node:

# NodeLocal DNSCache deployen
kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml

Monitoring mit Prometheus

CoreDNS exportiert Metriken auf Port 9153. Die wichtigsten für DNS-Debugging:

# Metriken direkt abfragen
kubectl exec -n kube-system deploy/coredns -- \
  wget -qO- http://localhost:9153/metrics | head -30

# Wichtige Metriken:
# coredns_dns_requests_total - Gesamtzahl der Anfragen
# coredns_dns_responses_total{rcode="NXDOMAIN"} - Fehlgeschlagene Auflösungen
# coredns_forward_requests_total - Upstream-Anfragen
# coredns_cache_hits_total - Cache-Treffer

Ein hoher Anteil an NXDOMAIN-Responses deutet auf falsche ndots-Konfiguration oder fehlerhafte Service-Referenzen hin.

FAQ

Wie finde ich heraus, welcher Pod DNS-Probleme verursacht?

Aktiviere temporär das log-Plugin in der Corefile. Damit siehst du jede DNS-Anfrage mit Quell-IP. Über die Pod-IP kannst du den verursachenden Pod identifizieren. Deaktiviere das Logging danach wieder — es erzeugt erhebliche Log-Mengen.

Warum ist externe DNS-Auflösung langsam, aber interne schnell?

Fast immer liegt das an ndots. Interne Namen wie my-service werden direkt über die Search-Domains aufgelöst. Externe Namen wie api.stripe.com durchlaufen erst alle Search-Domains. Setze ndots auf 2 oder verwende FQDNs mit Trailing-Dot (api.stripe.com.).

Kann ich CoreDNS durch einen anderen DNS-Server ersetzen?

Technisch ja, aber es wird nicht empfohlen. CoreDNS ist der Standard seit Kubernetes 1.13 und das einzige offiziell unterstützte DNS-Plugin. Alternatives wie kube-dns sind veraltet.

Wie viele CoreDNS-Replicas brauche ich?

Als Faustregel: 1 Replica pro 100-150 Pods, mindestens 2 für Hochverfügbarkeit. Bei mehr als 500 Pods solltest du NodeLocal DNSCache einsetzen, statt nur Replicas hochzudrehen.

Was bedeutet der SERVFAIL-Fehler?

SERVFAIL zeigt an, dass CoreDNS die Upstream-DNS-Server nicht erreichen kann. Prüfe die forward-Konfiguration in der Corefile und ob die Upstream-Server aus dem Cluster-Netzwerk erreichbar sind.