Eingaben
Beispiel
example.com -> DS im Parent, DNSKEY im Child, RRSIG-Evidenz und secure/bogus Resolverstatus.
DNSSEC-Validator
Bewertet DS-, DNSKEY- und RRSIG-Strukturinventar sowie das DNSSEC-Urteil des validierenden Resolvers für eine Domain.
Nutze es, um DNSSEC-Evidenz zu prüfen, ohne Record-Präsenz mit bewiesener Resolver-Validierung zu verwechseln.
Woraus eine DNSSEC-Kette wirklich besteht
DNSSEC-Ausfälle haben ein charakteristisches Symptom: Die Domain funktioniert für einen Teil der Nutzer und ist für den Rest tot. Validierende Resolver antworten bei gebrochener Kette mit SERVFAIL, nicht-validierende liefern die Records munter weiter — der Ausfall folgt also der Resolverwahl, nicht der Geografie oder dem Netz. Wer Quad9 nutzt, sieht einen Ausfall; wer am alten Provider-Resolver hängt, merkt nichts. Diese Teilausfälle sind gerade deshalb verwirrend, weil die Zonendaten selbst völlig in Ordnung sind.
Hinter jedem solchen Vorfall steht eine Kette mit genau einem gebrochenen Glied. Die Elternzone veröffentlicht einen DS-Record — einen Digest des Key-Signing-Keys des Kindes. Das Kind veröffentlicht sein DNSKEY-Set und signiert seine Record-Sets mit RRSIGs. Die Validierung läuft vom Trust-Anchor durch jede Delegation, und jedes Glied muss halten: DS muss zu einem lebenden DNSKEY passen, Signaturen müssen aktuell sein, Algorithmen müssen zusammenpassen. Dieses Tool holt diese Evidenz für eine Domain — DS, DNSKEY, RRSIG und das Urteil des Resolvers — und zeigt, wo die Geschichte aufhört zu stimmen.
Vom Symptom zum gebrochenen Glied
Beginne beim Resolverstatus, denn er bestimmt die Problemklasse. Secure heißt: Die Kette validiert durchgehend. Insecure heißt: Am Parent existiert kein DS — die Zone ist schlicht unsigniert, ein Policy-Zustand, kein Fehler. Bogus ist der Akutfall: signiert, aber kaputt, und validierende Resolver verweigern die Antwort. Nur bogus legt die Domain lahm — und diese Unterscheidung entscheidet, ob du Feuerwehr spielst oder planst.
Bei einem Bogus-Befund prüfst du die beiden Klassiker der Reihe nach. Erstens Signaturfrische: RRSIGs tragen explizite Ablaufzeitpunkte, und eine abgelaufene Signatur bedeutet fast immer, dass die Re-Signierungs-Automatik vor Tagen gestorben ist — der Ausfall beginnt nicht, wenn das Tooling bricht, sondern wenn die letzte Signatur abläuft. Zweitens der DS-zu-DNSKEY-Abgleich: Nach einem Key-Rollover bricht ein DS am Parent, der noch den ausgemusterten Schlüssel digestiert, die gesamte Kette — deshalb muss der alte Schlüssel publiziert bleiben, bis das Parent-Update samt TTL durch ist.
Was die Browseransicht validieren kann — und was nicht
Eingefügte Records bleiben lokal; Live-Abfragen laufen nur auf Anforderung, per Browser-DNS-over-HTTPS mit Same-Origin-Fallback. Die Seite zeigt das Validierungsurteil des benannten Resolvers und strukturelles Ketteninventar; sie rechnet nicht jede Signatur selbst nach und zeigt NSEC/NSEC3 nur als Kontext. Nacktes SERVFAIL, Timeout oder ein generischer Fehler ist unavailable Evidenz und kein Bogus-Beweis; diese Einstufung verlangt ein explizites Resolverurteil oder DNSSEC-spezifische EDE-Evidenz. Das autoritative Offline-Urteil bleibt Sache eines lokal validierenden Resolvers.
Häufige Fragen
Manche Netze erreichen die Domain, andere bekommen Fehler — DNSSEC?
Dieses Muster kann zu einem DNSSEC-Validierungsfehler passen, beweist ihn aber nicht. Nacktes SERVFAIL bleibt unavailable, weil viele andere Fehler dasselbe erzeugen. Erst ein explizites Bogus-Urteil des Resolvers oder DNSSEC-spezifische EDE-Evidenz rechtfertigt die Einstufung bogus.
Was unterscheidet insecure von bogus?
Insecure: Der Parent hat keinen DS, die Zone ist unsigniert, Resolver erwarten keine Signaturen. Bogus: Die Zone behauptet, signiert zu sein, aber die Validierung scheitert. Insecure ist eine Entscheidung, bogus ist ein Ausfall.
Wie verursachen RRSIG-Ablaufzeiten Ausfälle?
Signaturen gelten nur innerhalb ihres Zeitfensters. Zonen signieren automatisch nach — und wenn diese Automatik ausfällt, passiert erst einmal nichts Sichtbares, bis die erste Signatur abläuft. Dann verwerfen validierende Resolver die Zone. RRSIG-Ablauf zu überwachen heißt, die Signier-Pipeline zu überwachen.
Warum brach meine Domain nach einem Schlüsselwechsel?
Sehr wahrscheinlich passt der DS am Parent noch zum alten Schlüssel, oder der alte DNSKEY wurde zurückgezogen, bevor das Parent-Update samt TTL propagiert war. Rollover brauchen beide Schlüssel während des Übergangsfensters — wer den Schritt überspringt, macht aus einer Routinerotation eine Bogus-Zone.
Spielen KSK und ZSK beim Lesen der Ausgabe eine Rolle?
Ja. Der DS am Parent gehört zum Key-Signing-Key, der wiederum den Zone-Signing-Key signiert, der die normalen Records signiert. Passt der DS zu keinem sichtbaren DNSKEY, vergleiche gezielt gegen den KSK — das ist das Glied, das der Parent verankert.
Ist eine angezeigte Algorithmusnummer eine Sicherheitsbewertung?
Nein, sie ist Inventar. Sie hilft, veraltete Algorithmen und Diskrepanzen zwischen DS und DNSKEY zu erkennen — die Anzeige beweist aber nicht, dass diese Seite die Kryptografie unabhängig verifiziert hat.