DNSSEC-SERVFAIL nach einem Nameserverwechsel: Diagnose und sichere Migration

Ein Wechsel der Nameserver kann in sämtlichen Verwaltungsoberflächen erfolgreich aussehen und die Website trotzdem unerreichbar machen. Die Domain ist aktiv, die neuen autoritativen Nameserver liefern die erwartete IP-Adresse und am Webserver hat sich nichts geändert. Dennoch melden validierende DNS-Resolver SERVFAIL. Häufig liegt das an einer DNSSEC-Delegierung, die weiterhin dem Signaturschlüssel des bisherigen DNS-Anbieters vertraut.

Bei dem hier untersuchten Vorfall schlugen normale DNS-Abfragen fehl, während dieselben Abfragen bei umgangener DNSSEC-Validierung erfolgreich waren. Die übergeordnete Zone veröffentlichte weiterhin einen alten DS-Eintrag, die neue autoritative Zone war dagegen zunächst unsigniert. Nachdem ein passender Schlüssel veröffentlicht und die neue Zone signiert worden war, lieferten die getesteten Resolver wieder validierte Antworten. Die entscheidende Erkenntnis ist nicht, dass man DNSSEC abschalten sollte, sondern dass der Wechsel der Nameserver und die Umstellung der DNSSEC-Vertrauenskette zwei getrennte Vorgänge sind.

Warum korrekte A-Records trotzdem zu SERVFAIL führen können

DNS beantwortet zwei unterschiedliche Fragen. Ein A-Record gibt an, welche IPv4-Adresse zu einem Namen gehört. DNSSEC ermöglicht einem validierenden Resolver zu prüfen, ob er dieser Antwort vertrauen kann. Korrekte Adressdaten bedeuten nicht automatisch, dass auch die DNSSEC-Vertrauenskette gültig ist.

Bei einer signierten Domain reicht diese Kette von einer vertrauenswürdigen übergeordneten Zone über einen DS-Eintrag (Delegation Signer) bis zu einem DNSKEY in der untergeordneten Zone. Die untergeordnete Zone veröffentlicht Signaturen (RRSIG-Records) für ihre DNS-Daten. Der DS-Eintrag enthält einen Hashwert, der einen autorisierten DNSKEY identifiziert. Er ist weder ein A-Record noch eine Kopie des privaten Schlüssels oder eine Einstellung in einem gewöhnlichen Zonendatei-Editor.

Nach einem Wechsel der autoritativen Nameserver kann die übergeordnete Zone weiterhin einen DS-Eintrag veröffentlichen, der zum bisherigen Signaturschlüssel gehört. Wenn die neue Zone weder den zugehörigen DNSKEY noch die erforderlichen Signaturen bereitstellt, kann ein validierender Resolver die Vertrauenskette nicht schließen. Normalerweise stuft er die Antwort dann als ungültig ein und gibt SERVFAIL zurück, statt eine ungeprüfte Adresse auszuliefern.

Das ist etwas anderes als ein HTTP-Ausfall: Die Anfrage erreicht den Webserver möglicherweise gar nicht. Ebenso wenig handelt es sich um ein abgelaufenes TLS-Zertifikat. DNSSEC validiert DNS-Daten, während HTTPS eine spätere Verbindung zwischen Browser und Server schützt.

Mit welcher Diagnose sich ein DNSSEC-Fehler von einem fehlenden Record unterscheiden lässt

Am aussagekräftigsten ist es, denselben Namen zweimal über denselben Resolver abzufragen. Zuerst eine normale Abfrage ausführen und dabei nicht nur die Antwort, sondern auch den Status prüfen:

dig example.com A +noall +comments +answer

Dann die Abfrage mit gesetztem CD-Bit (DNSSEC Checking Disabled) wiederholen:

dig example.com A +cdflag +noall +comments +answer

Beim beobachteten Fehler lieferte die normale Abfrage SERVFAIL, mit gesetztem CD-Bit erschien dagegen der erwartete A-Record. Dieser Unterschied deutete stark auf ein Problem bei der DNSSEC-Validierung hin und nicht auf einen fehlenden DNS-Eintrag oder eine nicht erreichbare Anwendung. Mit +cdflag wird ein rekursiver Resolver, der diese Option unterstützt, angewiesen, die übliche DNSSEC-Validierung für diese Anfrage zu unterlassen. Das ist ein Diagnosewerkzeug, keine Reparatur auf Browserseite und keine Möglichkeit, DNSSEC für Besucher abzuschalten.

Aus einer leeren Ausgabe mit +short sollte man nicht zu viel ableiten. Sowohl eine fehlende Antwort als auch SERVFAIL können mit diesem Ausgabeformat leer erscheinen. Bei der Fehlersuche sollte +comments aktiviert bleiben, damit status: SERVFAIL und status: NOERROR sichtbar sind.

Der CD-Vergleich allein zeigt noch nicht, welcher Teil von DNSSEC fehlschlägt. Er zeigt, wo die weitere Untersuchung ansetzen sollte. Auch eine vorübergehende Störung bei einem vorgelagerten Server ist möglich. Wiederholen Sie den Test daher gegebenenfalls und prüfen Sie die Delegierung in der übergeordneten Zone.

Den DS-Eintrag der übergeordneten Zone prüfen, nicht nur den DNS-Editor

Prüfen Sie, ob DS-Einträge für die Domain vorhanden sind:

dig example.com DS +noall +comments +answer

Für einen umfassenderen Blick auf den Delegierungspfad fragen Sie die DNS-Hierarchie direkt ab:

dig +trace example.com DS

Welcher autoritative Nameserver für die übergeordnete Zone zuständig ist, hängt von der Top-Level-Domain ab. Entscheidend ist der von dieser Zone veröffentlichte DS-Record-Satz, nicht bloß eine Zusammenfassung im Dashboard eines DNS-Hosters. Bei einem Registrarwechsel können die Nameserver unverändert bleiben; umgekehrt ist ein Nameserverwechsel ohne Registrarwechsel möglich. In beiden Fällen muss der DS-Eintrag der übergeordneten Zone zur aktiven autoritativen Zone passen.

Ein DS-Eintrag enthält vier wesentliche Felder: Key-Tag, Algorithmus, Digest-Typ und Digest. Der Key-Tag ist eine praktische Kennung bei der Fehlersuche, beweist für sich genommen aber nicht, dass ein DNSKEY passt. Auch der Digest und die Algorithmusangaben müssen mit einem Schlüssel übereinstimmen, den die autoritative Zone tatsächlich ausliefert.

Der entscheidende Zustand in diesem Fall war eindeutig: Die übergeordnete Zone veröffentlichte weiterhin die bisherigen DNSSEC-Vertrauensinformationen, während die neue autoritative Zone meldete, dass die Signierung deaktiviert war. Die A-Records waren vorhanden und ließen sich abrufen, wenn die Validierung umgangen wurde. Änderungen an der Anwendungskonfiguration oder wiederholte Änderungen desselben A-Records hätten diesen Widerspruch nicht behoben.

Zwei Wege, eine fehlerhafte DNSSEC-Delegierung wiederherzustellen

Es gibt zwei legitime Strategien zur Wiederherstellung. Beide beheben den Widerspruch in der Vertrauenskette, haben aber unterschiedliche betriebliche Folgen. Entscheiden Sie sich bewusst für eine davon, statt wahllos zwischen beiden zu wechseln.

Option 1: Veralteten DS-Eintrag entfernen und vorübergehend eine unsignierte Zone betreiben

Lassen Sie den veralteten DS-Eintrag über den aktuellen Registrar oder dessen unterstützte DNSSEC-Verwaltungsoberfläche aus der übergeordneten Zone entfernen. Sobald die übergeordnete Zone keine sichere Delegierung mehr vorgibt, können validierende Resolver eine unsignierte untergeordnete Zone als nicht DNSSEC-gesichert statt als ungültig behandeln. DNS funktioniert damit weiterhin, allerdings fehlt für die Domain vorübergehend die DNSSEC-Authentifizierung.

Das ist häufig die einfachere Notfalllösung, sofern sich der DS-Record-Satz der übergeordneten Zone zuverlässig ändern lässt. Lassen Sie die bestehende Signierungskonfiguration unverändert, bis zuvor zwischengespeicherte alte DS-Einträge bei rekursiven Resolvern abgelaufen sind. Allein die Entfernung eines DS-Eintrags in einer Verwaltungsoberfläche ist noch kein ausreichender Nachweis: Prüfen Sie den Eintrag der übergeordneten Zone von außen und berücksichtigen Sie seine TTL. HTTPS bleibt von der DNSSEC-Einstellung unabhängig. Der vorübergehende Übergang zu einer unsignierten Zone wird auch in RFC 8078 beschrieben.

Option 2: Die neue Zone signieren und einen passenden DS-Eintrag veröffentlichen

Alternativ können Sie DNSSEC beim neuen autoritativen DNS-Anbieter aktivieren, dort DNSKEY-Schlüsselmaterial erzeugen, die Zone signieren und den zugehörigen DS-Eintrag in der übergeordneten Zone veröffentlichen. Ein validierender Resolver kann dann einen vertrauenswürdigen Pfad zum neuen DNSKEY aufbauen und den A-Record validieren.

Genau dieser Weg wurde bei der Wiederherstellung beobachtet. Die DNS-Verwaltungsoberfläche meldete, dass sie Schlüssel erzeugt, die Zone signiert und einen neuen DS-Eintrag veröffentlicht hatte. Eine anschließende Abfrage der übergeordneten Zone zeigte den neuen DS-Eintrag neben dem bisherigen. Validierende rekursive Abfragen lieferten wieder den erwarteten A-Record; bei einem späteren Test erschien außerdem NOERROR mit gesetztem ad-Flag, was anzeigte, dass dieser Resolver die Daten authentifiziert hatte.

Die Reihenfolge ist wichtig: Ein veröffentlichter DS-Eintrag hilft nur, wenn der passende DNSKEY und gültige Signaturen bereits vom autoritativen DNS-Dienst bereitgestellt werden. Die Meldung „published“ in einem Dashboard ersetzt keine externe Prüfung. Zwischengespeicherte DS-, DNSKEY-, RRSIG- und NS-Einträge können dazu führen, dass sich verschiedene Resolver zu unterschiedlichen Zeiten erholen.

Warum zwei DS-Einträge die Website nicht zwangsläufig weiter lahmlegen

Überraschend war, dass die übergeordnete Zone zeitweise sowohl einen veralteten als auch einen neuen, gültigen DS-Eintrag enthielt und die DNSSEC-Validierung trotzdem funktionierte. Das ist kein Widerspruch. Ein DS-Record-Satz kann mehrere Einträge enthalten, wie es etwa bei Schlüsselwechseln üblich ist. Ein Validator verlangt nicht, dass jeder DS-Eintrag einen aktuell nutzbaren Schlüssel bezeichnet. Es genügt ein gültiger Authentifizierungspfad über einen geeigneten DS-Eintrag zu einem DNSKEY und gültigen Signaturen. RFC 6840 stellt klar, dass Validatoren einen einzigen gültigen Pfad akzeptieren sollten.

Deshalb sollte man veraltete Schlüssel trotzdem nicht dauerhaft behalten. Ein überholter DS-Eintrag erschwert die Betriebsübersicht und sollte entfernt werden, sobald die neue Vertrauenskette überprüft ist. Das ist jedoch eine Wartungsmaßnahme und kein Grund für einen weiteren riskanten DNSSEC-Reset, während validierte Abfragen bereits wieder erfolgreich sind.

Eine besonders gefährliche Falle steckt in manchen Verwaltungsoberflächen: Eine Aktion namens „emergency unpublish DS“ kann bedeuten, dass sämtliche DS-Einträge entfernt werden, auch der neue, funktionierende Eintrag. Ebenso kann das Abschalten der Zonensignierung den Ausfall sofort erneut auslösen, solange noch ein DS-Eintrag veröffentlicht ist. Keine dieser Aktionen entspricht dem gezielten Löschen eines einzelnen veralteten DS-Eintrags. Wenn sich in der Oberfläche kein einzelner Eintrag auswählen lässt, sollte die gezielte Änderung über den Registrar erfolgen statt über einen pauschalen Reset.

So wechseln Sie autoritative Nameserver sicher

Welche Reihenfolge am sichersten ist, hängt davon ab, ob der bisherige und der neue DNS-Anbieter ihre Schlüssel koordinieren können. Bei einer herkömmlichen Migration mit vorübergehend unsignierter Zone lässt sich der hier beobachtete Widerspruch mit der folgenden Reihenfolge vermeiden:

Zuerst die Zielzone vorbereiten. Übernehmen Sie alle benötigten A-, AAAA-, CNAME-, MX-, TXT- und sonstigen relevanten Einträge. Testen Sie die neuen autoritativen Nameserver direkt, bevor Sie die Delegierung umstellen.
DNSSEC in der übergeordneten Zone prüfen. Kontrollieren Sie, ob DS-Einträge existieren und wer sie ändern kann. Tun Sie das auch, wenn Sie DNSSEC nie selbst aktiviert haben: Manche DNS-Dienste signieren Zonen automatisch.
Den alten DS-Eintrag entfernen, solange die bisherige signierte Zone noch läuft. Bestätigen Sie die Änderung am autoritativen Server der übergeordneten Zone und warten Sie anschließend, bis zuvor zwischengespeicherte DS-Daten abgelaufen sind. Entscheidend sind die beobachteten TTLs, nicht eine pauschale Wartezeit in Minuten.
Die Nameserver-Delegierung umstellen. Lassen Sie den bisherigen autoritativen DNS-Dienst verfügbar, solange zwischengespeicherte NS-Delegierungen noch auf ihn verweisen könnten. Berücksichtigen Sie die NS-TTLs der übergeordneten Zone und prüfen Sie, welche Server verschiedene Resolver tatsächlich verwenden.
Über die erneute Aktivierung von DNSSEC entscheiden. Soll der neue Dienst unsigniert bleiben, veröffentlichen Sie keinen DS-Eintrag. Soll er signiert sein, prüfen Sie zuerst, ob der neue DNSKEY und die Signaturen korrekt ausgeliefert werden, bevor Sie den passenden DS-Eintrag veröffentlichen. Berücksichtigen Sie dabei noch vorhandene Caches mit alten NS-Einträgen, um einen erneuten Validierungsfehler zu vermeiden.
Unabhängig validieren. Prüfen Sie den DS-Eintrag der übergeordneten Zone, den autoritativen DNSKEY, die normale rekursive Namensauflösung und das Ergebnis der Datenauthentifizierung bei validierenden Resolvern.

Wenn ein durchgehender DNSSEC-Schutz erforderlich ist, ist ein ausdrücklich koordinierter Schlüsselwechsel oder eine Multi-Signer-Umstellung dem unsignierten Zwischenzustand vorzuziehen. Dafür müssen beide DNS-Anbieter die nötige Schlüssel- und Signierungskonfiguration unterstützen. Den alten DS-Digest einfach zum neuen Anbieter zu kopieren, ist kein Schlüsselwechsel.

Kurze Checkliste zur Überprüfung nach der Migration

Prüfen Sie nach jeder DNSSEC-bezogenen Änderung sowohl die DNS-Einträge als auch, ob Resolver die zugehörigen Nachweise akzeptieren:

dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answer

Verwenden Sie für die Prüfung authentifizierter Antworten einen validierenden rekursiven Resolver. NOERROR zusammen mit dem erwarteten A-Record bedeutet, dass die Namensauflösung erfolgreich war. Ein zusätzliches ad-Flag zeigt an, dass der Resolver die Antwort gemäß seiner DNSSEC-Richtlinie authentifiziert hat. Fehlt das ad-Flag, ist das allein noch kein Beweis für einen Fehler: Fähigkeiten und Richtlinien der Resolver sowie die verwendeten Abfrage-Flags unterscheiden sich. Falls DNSKEY-Abfragen während eines Ausfalls über einen validierenden Resolver fehlschlagen, fragen Sie im Rahmen der Untersuchung auch den aktiven autoritativen DNS-Dienst direkt ab.

Beenden Sie die Überprüfung nicht nach der ersten erfolgreichen Resolverantwort. Verschiedene Caches können vorübergehend unterschiedliche Delegierungen und Schlüssel enthalten. Aktualisieren Sie außerdem gegebenenfalls offene Supportanfragen: Die frühere Anweisung, sämtliche DS-Einträge zu entfernen, wird gefährlich, sobald ein neuer funktionierender DS-Eintrag veröffentlicht wurde. In einer Rückmeldung sollte ausdrücklich festgehalten werden, dass der aktive Schlüssel erhalten bleiben und bei Bedarf ausschließlich der veraltete Eintrag entfernt werden soll.

Die Ursache des Fehlers war keine falsche Webserveradresse. Der Ausfall entstand, weil der Ort geändert wurde, von dem DNS-Antworten kamen, ohne zuvor die Vertrauensinformationen anzupassen, anhand derer Resolver diese Antworten prüfen. Deshalb lautet die entscheidende Frage vor jedem Nameserverwechsel: Welche DS-Einträge veröffentlicht die übergeordnete Zone, und können DNSKEY und Signaturen des neuen Anbieters diese erfüllen?