Zum Hauptinhalt springen
CaptainDNS

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üfen Sie mit unserem DNSSEC Checker, ob Ihre Vertrauenskette intakt ist (siehe Aktionsplan am Ende des Artikels)

Sie haben gerade DNSSEC bei Ihrem Registrar aktiviert. Die ersten Tests laufen durch. Dann, ein paar Stunden später, melden Ihre 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. Ihr 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: Sie haben Ihre Zone signiert (DNSKEY und RRSIG existieren), aber der DS-Record wurde nicht beim TLD veröffentlicht. Der Resolver kann Ihre 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. Holen Sie den DS-Record von Ihrem DNS-Anbieter (Cloudflare, Route 53, OVHcloud)
  2. Tragen Sie ihn in der Oberfläche Ihres Registrars ein (Bereich DNSSEC)
  3. Warten Sie 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 Ihrer 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. Generieren Sie den korrekten DS-Record bei Ihrem DNS-Anbieter
  2. Löschen Sie in der Registrar-Oberfläche den alten DS und tragen Sie den neuen ein
  3. Falls Ihr 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 Ihr 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.

Gängige DNSSEC-Algorithmen (Quelle: IANA-Register DNS Security Algorithm Numbers):

AlgorithmusNameVerwendung
8RSA/SHA-256Weit verbreitet
13ECDSA P-256Empfohlen, kürzere Schlüssel
14ECDSA P-384Höhere Sicherheitsmarge
15Ed25519Am schnellsten, kürzeste Signaturen

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. Generieren Sie den DS-Record neu bei Ihrem DNS-Anbieter (er verwendet dann den richtigen Algorithmus)
  2. Aktualisieren Sie den DS beim Registrar
  3. Warten Sie 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. Warten Sie auf den Ablauf der TTL (prüfen Sie die TTL des DS-Records beim TLD)
  2. Leeren Sie den Cache wenn möglich:

Prävention: Senken Sie vor jeder DNSSEC-Änderung die TTL des DS-Records 24 h im Voraus (falls Ihr 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öffentlichen Sie beide DS-Records (alt + neu) beim Registrar. Warten Sie auf die vollständige Propagation des neuen DS, bevor Sie den alten entfernen. Löschen Sie den alten DS niemals, ohne vorher die Propagation des neuen bestätigt zu haben.

Kontinuierliche Überwachung

Prüfen Sie regelmäßig die DNS-Propagation Ihrer DNSSEC-Konfiguration. Ein falscher DS oder eine abgelaufene Signatur können unbemerkt auftreten. Ein automatischer Alert zum DNSSEC-Status Ihrer Domain erkennt Probleme, bevor Ihre 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ühren Sie dig captaindns.com +cd aus; kommt die Antwort mit +cd, aber nicht ohne, liegt es an DNSSEC
  2. Das gebrochene Glied identifizieren: Prüfen Sie DS, DNSKEY und RRSIG mit den drei Diagnosebefehlen
  3. Korrektur anwenden: Folgen Sie dem passenden Szenario (fehlender DS, falscher DS, abgelaufene RRSIG, Algorithmus, Cache)
  4. Reparatur überprüfen: Warten Sie die TTL ab und prüfen Sie mit dig captaindns.com +dnssec, ob das Flag ad vorhanden ist
  5. Vorfall dokumentieren: Notieren Sie Ursache, Korrektur und Lösungsdauer, um künftige Diagnosen zu beschleunigen

Starten Sie eine vollständige DNSSEC-Diagnose Ihrer 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?

Verwenden Sie das Flag +cd (Checking Disabled) in Ihrem 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. Identifizieren Sie zuerst die genaue Ursache. Ist der DS-Record falsch, korrigieren Sie ihn. Deaktivieren Sie DNSSEC nur, wenn Sie die Ursache nicht finden 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 der TTL weiter funktionieren.

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

Führen Sie dig captaindns.com +dnssec | grep flags aus. Ist das Flag ad (Authenticated Data) vorhanden, ist die Vertrauenskette validiert. Testen Sie 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