Zum Hauptinhalt springen

SERVFAIL nach DNSSEC-Aktivierung: Diagnose und Behebung

Von CaptainDNS
Veröffentlicht am 25. Februar 2026

SERVFAIL-DNSSEC-Diagnose: Entscheidungsbaum zur Identifikation und Behebung der Ursache eines SERVFAIL nach DNSSEC-Aktivierung
TL;DR
  • Ein DNSSEC-bedingter SERVFAIL bedeutet, dass der Resolver die DNS-Antwort abgelehnt hat, weil ein Glied der Vertrauenskette ungültig ist
  • Fünf Ursachen decken nahezu alle Fälle ab: fehlender DS, falscher DS, abgelaufene RRSIG, inkompatibler Algorithmus, vergifteter Cache
  • Drei dig-Befehle reichen aus, um das Problem einzugrenzen (siehe Entscheidungsbaum am Ende des Artikels)
  • Prüfe mit unserem DNSSEC Checker, ob deine Vertrauenskette intakt ist (siehe Aktionsplan am Ende des Artikels)

Du hast gerade DNSSEC bei deinem Registrar aktiviert. Die ersten Tests laufen durch. Dann, ein paar Stunden später, melden deine Nutzer, dass die Website nicht erreichbar ist. Die Diagnose: SERVFAIL.

Der SERVFAIL ist kein Serverproblem. Es ist der DNS-Resolver, der die Antwort verweigert, weil die DNSSEC-Validierung fehlgeschlagen ist. Dein Server funktioniert, aber der Resolver blockiert ihn.

Dieser Guide behandelt die fünf SERVFAIL-Szenarien im Zusammenhang mit DNSSEC, jeweils mit dem passenden Diagnosebefehl und der exakten Korrektur.

SERVFAIL und DNSSEC: der Mechanismus

Wenn ein validierender Resolver (1.1.1.1, 8.8.8.8, 9.9.9.9) eine DNS-Antwort für eine DNSSEC-signierte Domain empfängt, prüft er die gesamte Vertrauenskette: Trust Anchor, DS-Record, DNSKEY, RRSIG.

Schlägt eine Prüfung fehl, markiert der Resolver die Antwort als BOGUS und gibt SERVFAIL an den Client zurück. Die Website wird für alle Nutzer unerreichbar, deren Resolver DNSSEC validiert (laut APNIC ca. 38 % der weltweiten DNS-Anfragen).

Die Schwierigkeit: Ein SERVFAIL verrät nicht, warum die Validierung fehlgeschlagen ist. Eine manuelle Diagnose ist nötig.

Schnelldiagnose: drei Befehle

Bevor wir die einzelnen Szenarien analysieren, hier die drei Befehle, die in den meisten Fällen ausreichen.

Befehl 1: DS-Record prüfen

dig DS captaindns.com +short

Gibt der Befehl nichts zurück, existiert kein DS-Record beim TLD. Die Vertrauenskette ist nicht aufgebaut.

Befehl 2: DS und DNSKEY vergleichen

dig DNSKEY captaindns.com +short

Der DS-Record enthält einen Hash des KSK (Flag 257). Stimmt der Hash mit keinem veröffentlichten DNSKEY überein, ist der DS-Record falsch.

Befehl 3: Signaturen prüfen

dig A captaindns.com +dnssec +cd

Das Flag +cd (Checking Disabled) weist den Resolver an, die Antwort ohne DNSSEC-Validierung zurückzugeben. Kommt die Antwort mit +cd, aber nicht ohne, liegt das Problem bei DNSSEC.

Die fünf Ursachen für SERVFAIL nach DNSSEC

Ursache 1: fehlender DS-Record

Symptom: dig DS captaindns.com +short gibt nichts zurück.

Erklärung: Du hast deine Zone signiert (DNSKEY und RRSIG existieren), aber der DS-Record wurde nicht beim TLD veröffentlicht. Der Resolver kann deine Zone nicht mit der übergeordneten Zone verknüpfen.

DNSSEC-Status: INSECURE (nicht BOGUS). Der Resolver validiert nicht, blockiert aber auch nicht. Dieser Fall verursacht nur dann einen SERVFAIL, wenn der Resolver noch einen DS aus einer früheren Konfiguration im Cache hat.

Korrektur:

  1. Hole den DS-Record von deinem DNS-Anbieter (Cloudflare, Route 53, OVHcloud)
  2. Trage ihn in der Oberfläche deines Registrars ein (Bereich DNSSEC)
  3. Warte auf die Propagation (TTL des DS beim TLD, oft 24-48 h)

Überprüfung:

dig DS captaindns.com +short
# Muss den DS-Record mit Key Tag, Algorithm, Digest Type, Digest zurückgeben

Ursache 2: falscher DS-Record

Symptom: Der DS-Record existiert, aber der Hash stimmt mit keinem veröffentlichten KSK überein.

Erklärung: Der DS beim TLD enthält einen Hash, der nicht zum KSK deiner Zone passt. Häufige Ursachen:

  • Copy-Paste-Fehler bei manueller Eingabe
  • KSK-Rotation ohne DS-Aktualisierung
  • DS mit falschem Hash-Algorithmus generiert (SHA-1 statt SHA-256)

DNSSEC-Status: BOGUS. Der Resolver gibt SERVFAIL zurück.

Diagnose:

# DS beim TLD abrufen
dig DS captaindns.com +short
# Beispiel: 12345 13 2 ABC123...

# DNSKEY abrufen
dig DNSKEY captaindns.com +short
# Nach dem KSK suchen (Flag 257)
# Prüfen, ob der Key Tag (12345) übereinstimmt

Korrektur:

  1. Generiere den korrekten DS-Record bei deinem DNS-Anbieter
  2. Lösche in der Registrar-Oberfläche den alten DS und trage den neuen ein
  3. Falls dein Registrar CDS/CDNSKEY unterstützt (RFC 7344), kann die Aktualisierung automatisch erfolgen

Überprüfung:

dig captaindns.com +dnssec | grep flags
# Das Flag "ad" muss vorhanden sein

Ursache 3: abgelaufene RRSIG-Signaturen

Symptom: Die DNS-Antwort enthält RRSIG mit überschrittenem Ablaufdatum.

Erklärung: Jede RRSIG-Signatur hat eine Gültigkeitsdauer (typischerweise 7 bis 30 Tage). Erneuert dein DNS-Anbieter die Signaturen nicht rechtzeitig, lehnen die Resolver sie ab.

DNSSEC-Status: BOGUS. SERVFAIL für alle Einträge, deren Signatur abgelaufen ist.

Diagnose:

dig A captaindns.com +dnssec +cd
# RRSIG-Feld prüfen: Inception und Expiration
# Format: RRSIG A 13 2 300 20260315120000 20260301120000 12345 captaindns.com. ABC...
#                               ^^^^^^^^^^^^^^^^ Expiration
#                                                ^^^^^^^^^^^^^^^^ Inception

Häufige Ursachen:

  • Selbst gehostetes BIND oder PowerDNS ohne konfigurierte automatische Erneuerung
  • Fehler im Re-Signing-Cronjob
  • DNS-Migration ohne Übertragung der Signaturschlüssel

Korrektur:

  1. Bei Managed DNS: Support des Anbieters kontaktieren
  2. Bei selbst gehostetem BIND: Signatur erneuern mit rndc sign captaindns.com
  3. Bei PowerDNS: pdnsutil rectify-zone captaindns.com ausführen

Ursache 4: inkompatibler Algorithmus

Symptom: Der DS-Record gibt einen anderen Algorithmus an als den der DNSKEY.

Erklärung: Der DS-Record verweist z. B. auf Algorithmus 8 (RSA/SHA-256), während der DNSKEY Algorithmus 13 (ECDSA P-256) verwendet. Der Resolver kann die Übereinstimmung nicht prüfen.

DNSSEC-Status: BOGUS. SERVFAIL.

Diagnose:

# Algorithmus des DS prüfen
dig DS captaindns.com +short
# Format: KeyTag Algorithm DigestType Digest
# Beispiel: 12345 8 2 ABC...  (Algorithmus 8 = RSA/SHA-256)

# Algorithmus des DNSKEY prüfen
dig DNSKEY captaindns.com +short
# Format: Flags Protocol Algorithm PublicKey
# Beispiel: 257 3 13 ABC...  (Algorithmus 13 = ECDSA P-256)

Unterscheiden sich die Algorithmusnummern zwischen DS und DNSKEY (Flag 257), ist das die Ursache.

Korrektur:

  1. Generiere den DS-Record neu bei deinem DNS-Anbieter (er verwendet dann den richtigen Algorithmus)
  2. Aktualisiere den DS beim Registrar
  3. Warte auf die Propagation

Ursache 5: Resolver-Cache (falscher SERVFAIL)

Symptom: Intermittierender SERVFAIL. Einige Resolver geben SERVFAIL zurück, andere nicht.

Erklärung: Der Resolver hat eine alte Antwort oder einen alten DS-Record im Cache. Nach einer DNSSEC-Änderung (Aktivierung, Schlüsselrotation, DNS-Anbieterwechsel) kann der Resolver-Cache inkonsistente Daten enthalten.

Diagnose:

# Mit einem anderen Resolver testen
dig A captaindns.com @1.1.1.1 +dnssec
dig A captaindns.com @8.8.8.8 +dnssec
dig A captaindns.com @9.9.9.9 +dnssec

Funktionieren einige Resolver und andere nicht, handelt es sich um ein Cache-Problem.

Korrektur:

  1. Warte auf den Ablauf des TTL (prüfe den TTL des DS-Records beim TLD)
  2. Leere den Cache wenn möglich:

Prävention: Senke vor jeder DNSSEC-Änderung den TTL des DS-Records 24 h im Voraus (falls dein Registrar das erlaubt).

SERVFAIL-DNSSEC-Entscheidungsbaum: Ursache mit drei dig-Befehlen identifizieren

DNSSEC-SERVFAIL verhindern

Drei Maßnahmen reduzieren das Risiko eines Ausfalls:

Managed DNS statt selbst gehostet

Managed-DNS-Anbieter (Cloudflare, Route 53, OVHcloud, Google Cloud DNS) übernehmen die Signatur automatisch: Schlüsselrotation, RRSIG-Erneuerung, DS-Veröffentlichung über CDS/CDNSKEY. Das SERVFAIL-Risiko ist mit Managed DNS nahezu null.

Doppelter DS während Übergangsphasen

Bei einer KSK-Rotation veröffentlichst du beide DS-Records (alt + neu) beim Registrar. Warte auf die vollständige Propagation des neuen DS, bevor du den alten entfernst. Lösche den alten DS niemals, ohne vorher die Propagation des neuen bestätigt zu haben.

Kontinuierliche Überwachung

Prüfe regelmäßig die DNS-Propagation deiner DNSSEC-Konfiguration. Ein falscher DS oder eine abgelaufene Signatur können unbemerkt auftreten. Ein automatischer Alert zum DNSSEC-Status deiner Domain erkennt Probleme, bevor deine Nutzer sie melden.

SERVFAIL-DNSSEC-Korrekturprozess: von der Erkennung bis zur Überprüfung nach der Behebung

Aktionsplan bei SERVFAIL

  1. Bestätigen, dass DNSSEC die Ursache ist: Führe dig captaindns.com +cd aus; kommt die Antwort mit +cd, aber nicht ohne, liegt es an DNSSEC
  2. Das gebrochene Glied identifizieren: Prüfe DS, DNSKEY und RRSIG mit den drei Diagnosebefehlen
  3. Korrektur anwenden: Folge dem passenden Szenario (fehlender DS, falscher DS, abgelaufene RRSIG, Algorithmus, Cache)
  4. Reparatur überprüfen: Warte den TTL ab und prüfe mit dig captaindns.com +dnssec, ob das Flag ad vorhanden ist
  5. Vorfall dokumentieren: Notiere Ursache, Korrektur und Lösungsdauer, um künftige Diagnosen zu beschleunigen

Starte eine vollständige DNSSEC-Diagnose deiner Domain, um zu prüfen, ob jedes Glied an seinem Platz ist.

Verwandte DNSSEC-Leitfäden

FAQ

Was ist ein DNS-SERVFAIL?

SERVFAIL (Server Failure) ist ein DNS-Antwortcode (RCODE 2), der anzeigt, dass der Resolver keine gültige Antwort erhalten konnte. Im DNSSEC-Kontext bedeutet ein SERVFAIL, dass die kryptografische Validierung fehlgeschlagen ist: Der Resolver hat die Antwort abgelehnt, weil ein Glied der Vertrauenskette ungültig ist.

Was ist der Unterschied zwischen SERVFAIL und NXDOMAIN?

NXDOMAIN bedeutet, dass die Domain nicht existiert. SERVFAIL bedeutet, dass die Domain wahrscheinlich existiert, der Resolver die Antwort aber nicht validieren konnte. Bei DNSSEC weist ein SERVFAIL auf ein Validierungsproblem hin (falscher DS, abgelaufene Signatur), nicht auf eine nicht existierende Domain.

Wie erkenne ich, ob ein SERVFAIL durch DNSSEC verursacht wird?

Verwende das Flag +cd (Checking Disabled) in deinem dig-Befehl: dig captaindns.com +cd. Kommt die Antwort mit +cd, aber nicht ohne, ist DNSSEC die Ursache des SERVFAIL. Ohne +cd validiert der Resolver DNSSEC und blockiert die Antwort.

Wie lange dauert die Behebung eines DNSSEC-SERVFAIL?

Die eigentliche Korrektur dauert wenige Minuten (Hinzufügen oder Ändern des DS-Records). Die Propagation kann je nach TTL des DS-Records beim TLD 1 bis 48 Stunden dauern. In dieser Zeit geben Resolver mit dem alten Wert im Cache weiterhin SERVFAIL zurück.

Sollte man DNSSEC bei SERVFAIL sofort deaktivieren?

Nein. DNSSEC im Notfall zu deaktivieren (DS-Record löschen, ohne die Zonensignierung zu stoppen) kann das Problem verschlimmern. Identifiziere zuerst die genaue Ursache. Ist der DS-Record falsch, korrigiere ihn. Deaktiviere DNSSEC nur, wenn du die Ursache nicht findest und die Website geschäftskritisch ist.

Warum betrifft der SERVFAIL nicht alle Nutzer?

Nur validierende Resolver (die DNSSEC prüfen) geben SERVFAIL zurück. Nicht-validierende Resolver ignorieren die Signaturen und liefern die Antwort normal aus. Zudem können Resolver, die noch die alte Antwort im Cache haben, bis zum Ablauf des TTL weiter funktionieren.

Wie prüfe ich, ob die DNSSEC-Korrektur funktioniert hat?

Führe dig captaindns.com +dnssec | grep flags aus. Ist das Flag ad (Authenticated Data) vorhanden, ist die Vertrauenskette validiert. Teste mit mehreren Resolvern (1.1.1.1, 8.8.8.8, 9.9.9.9), um die vollständige Propagation zu bestätigen.

Eliminiert Managed DNS das Risiko eines DNSSEC-SERVFAIL?

Nahezu vollständig. Managed-DNS-Anbieter (Cloudflare, Route 53, OVHcloud) übernehmen automatisch die Signierung, Schlüsselrotation und RRSIG-Erneuerung. Das einzige verbleibende Risiko ist ein falscher DS-Record beim Registrar, was bei der Ersteinrichtung oder einem Domaintransfer passieren kann.

Glossar

  • SERVFAIL: DNS-Antwortcode (RCODE 2), der anzeigt, dass der Resolver die Anfrage nicht abschließen konnte. Im DNSSEC-Kontext signalisiert er ein Validierungsversagen.
  • BOGUS: interner Status des Resolvers, wenn die DNSSEC-Validierung fehlschlägt. Der Resolver gibt SERVFAIL an den Client zurück.
  • INSECURE: Status einer Domain, deren Zone signiert ist, aber kein DS-Record beim TLD existiert. Der Resolver validiert nicht, blockiert aber auch nicht.
  • DS-Record: Eintrag beim TLD, der einen Hash des KSK enthält. Bindeglied zwischen der Zone und der übergeordneten Zone.
  • RRSIG: kryptografische Signatur eines DNS-Eintrags mit definierter Gültigkeitsdauer.
  • +cd (Checking Disabled): dig-Flag, das den Resolver anweist, DNSSEC nicht zu validieren. Nützlich, um festzustellen, ob DNSSEC einen SERVFAIL verursacht.

Quellen

Ähnliche Artikel