DNSSEC-Ausfälle diagnostizieren: von SERVFAIL zum gebrochenen Glied

Das Symptom, das den Fall verrät

DNSSEC-Ausfälle folgen der Resolverwahl, nicht der Geografie. Validierende Resolver — Quad9, viele ISP-Resolver, die meisten Firmen-Setups — antworten mit SERVFAIL, wenn die Kette einer Zone nicht validiert. Nicht-validierende Resolver liefern dieselben Records anstandslos. Das Ergebnis ist ein Ausfall, der für einen Teil der Nutzerschaft real und für den Rest unsichtbar ist — und der die Fehlersuche zuverlässig in die falsche Richtung schickt: Der Webserver ist gesund, die Zonendatei sieht gut aus, und die halbe Welt erreicht trotzdem nichts davon.

Der schnellste Weg zur Problemklasse: einen validierenden Pfad direkt fragen und das Urteil lesen. Der DNSSEC-Validator zeigt den Resolverstatus zusammen mit der Kettenevidenz — DS, DNSKEY, RRSIG — in einer Ansicht. Drei Urteile zählen: secure heißt, die Kette validiert. insecure heißt, am Parent existiert kein DS — die Zone ist unsigniert, ein Konfigurationszustand, kein Fehler. bogus heißt: Die Zone behauptet, signiert zu sein, und scheitert — das ist der Akutfall, der Traffic kostet.

Root Cause eins: die abgelaufene Signatur

RRSIG-Records tragen explizite Gültigkeitsfenster. Zonen signieren automatisch nach — und wenn diese Automatik stirbt, ein hängender Cron-Job, eine volle Platte, ein ausgemusterter Signer, dem die Zone noch gehörte, passiert zunächst nichts Sichtbares. Der Ausfall beginnt Tage später, wenn die letzte Signatur abläuft — weshalb der Bruch so selten mit irgendeiner Änderung korreliert, an die sich jemand erinnert.

Die diagnostische Signatur ist eindeutig: RRSIG-Ablaufzeitpunkte in der Vergangenheit. Die Behebung ist operativ, nicht kryptografisch — Signier-Pipeline wiederbeleben, neu signieren, und danach Monitoring auf RRSIG-Ablauf mit genug Vorlauf, um einen kaputten Signer zu reparieren, bevor das Fenster zugeht. Signatur-Laufzeiten zu überwachen ist das Monitoring der Signier-Pipeline; Ablauf-Alarme im Zertifikatsstil auf dem Zonen-Apex fangen diese Fehlerklasse vollständig.

Root Cause zwei: der Rollover ohne Überlappung

Der zweite Klassiker: Ein Key-Signing-Key-Wechsel, bei dem der DS-Record am Parent und das DNSKEY-Set des Kindes nicht mehr zusammenpassen — ein Rollover ohne Überlappung, ein Registrar-Transfer, der den DS stillschweigend verlor, oder ein neuer DNS-Provider, der mit frischen Schlüsseln signiert, während der alte DS noch am Parent sitzt. Die Validierung läuft DS zu DNSKEY zu RRSIG — und ein DS, der einen nicht mehr vorhandenen Schlüssel digestiert, bricht den Lauf am ersten Schritt.

Vergleiche den DS am Parent gegen den aktuell publizierten KSK — das ist exakt das Glied, das der Parent verankert. Während jedes geplanten Rollovers muss der alte Schlüssel publiziert bleiben und weitersignieren, bis der neue DS vollständig über die Parent-TTL propagiert ist. Und nach jeder Provider- oder Registrar-Migration ist der DS-Check der wertvollste einzelne Verifikationsschritt: Migrationen sind der Ort, an dem DS-Records leise sterben.

Eine Gewohnheit verhindert das meiste aus beiden Root Causes: DNSSEC-Änderungen mit derselben Zeremonie behandeln wie Zertifikatswechsel — gestaffelt, hinterher von außen verifiziert, und nie an einem Freitag. Läuft DANE auf der Zone, verdoppelt sich der Einsatz: Eine Bogus-Zone reißt die TLSA-Lookups mit — und damit die Mail-Zustellung validierender Sender. Der DANE-Validator zeigt diesen Wirkungsradius direkt.