DNSSEC-Prüfer
Fragt den DNSKEY-Eintrag einer Domain bei mehreren öffentlichen DNS-Resolvern (Google, Cloudflare u. a.) ab und prüft, ob die DNSSEC-Signaturkette korrekt validiert wird.
Eine DNSSEC-Vertrauenskette prüfen
Dieses Werkzeug fragt die DNSKEY-Einträge einer Domäne bei mehreren öffentlichen Auflösern ab und meldet, ob sich die DNSSEC-Signaturen bis nach oben bestätigen lassen. Es findet jenen Zustand, in dem DNSSEC eingeschaltet sein sollte, die Kette aber irgendwo unterwegs reißt.
**DNSSEC schützt davor, dass eine Antwort verändert wurde, nicht davor, dass ihr Inhalt öffentlich ist.** Was übertragen wird, bleibt so sichtbar wie eh und je; verbürgt wird allein die Echtheit. **Die häufigste Unterlassung ist, den DS-Eintrag bei der übergeordneten Zone nicht anzumelden.** Sie mögen Schlüssel in Ihrer eigenen Zone hinterlegen und diese signieren, doch **solange nicht über Ihren Registrar ein DS bei der übergeordneten Zone — etwa `.com` — eingetragen ist, reißt dort die Vertrauenskette und nichts wird bestätigt.** Umgekehrt wird, wenn ein Schlüsselwechsel misslingt und eine Unstimmigkeit hinterlässt, **die ganze Domäne von jedem prüfenden Auflöser aus unerreichbar.** Ein halb fertiger Zustand kann daher gefährlicher sein, als DNSSEC nie eingeschaltet zu haben.
So gehen Sie vor
- Geben Sie die Domäne ein Nennen Sie allein die Domäne, in der Form `example.com`.
- Lesen Sie das Ergebnis der Prüfung **Es beurteilt, ob die Kette der Signaturen bis zur übergeordneten Zone reicht.**
- Bestätigen Sie, ob ein DS-Eintrag besteht **Fehlt er, so wird nichts bestätigt, wie viele Schlüssel Sie auch hinterlegt haben.**
- Vergleichen Sie die Antworten mehrerer Auflöser Eine Abweichung deutet entweder auf einen Zwischenspeicher oder auf die Einrichtung.
Tipps für die Nutzung
- Das AD-Flag (Authenticated Data) wird nur gesetzt, wenn der abgefragte DNS-Resolver selbst die DNSSEC-Validierung durchgeführt hat. Resolver ohne DNSSEC-Unterstützung können kein aussagekräftiges Ergebnis liefern.
- „DNSSEC nicht aktiviert“ ist kein Fehler – die meisten Domains verwenden nach wie vor kein DNSSEC, und das hat keine direkte Auswirkung auf das Suchranking oder die E-Mail-Zustellbarkeit.
- Schlägt die Validierung fehl, prüfen Sie zuerst, ob Key-Tag und Digest des beim Registrar hinterlegten DS-Eintrags mit Ihrem aktuellen DNSKEY übereinstimmen.
- DNSSEC-Signaturen (RRSIG) haben ein Ablaufdatum. Prüfen Sie außerdem, ob die automatische Neusignierung Ihrer DNS-Software nicht gestoppt wurde.
- Direkt nach dem Aktivieren von DNSSEC kann die Validierung vorübergehend als „fehlgeschlagen“ angezeigt werden, bis sich der DS-Eintrag zur übergeordneten Zone propagiert hat.
Wofür Sie es nutzen können
Um nach dem Einschalten von DNSSEC zu prüfen
**Ein Häkchen in der Verwaltungsoberfläche lässt die Arbeit sehr oft unvollendet.**
Um einen Schlüsselwechsel zu Ende zu bringen
Sie können vor und nach dem Wechsel bestätigen, dass die Prüfung nicht gerissen ist.
Um einzugrenzen, warum ein Name nicht auflöst
**Eine DNSSEC-Unstimmigkeit lässt die Domäne allein für einen Teil der Nutzer wie verschwunden erscheinen.**
Um die Domäne eines Geschäftspartners zu prüfen
Sie erfahren, wie weit dieser die eigenen Vorkehrungen getrieben hat.
Begriffe zu DNSSEC
- DNSKEY
- Der Eintrag, der den öffentlichen Schlüssel einer Zone führt und beim Prüfen der Signaturen verwendet wird.
- DS-Eintrag
- **Der Eintrag, der den Fingerabdruck des Schlüssels einer untergeordneten Zone bei der übergeordneten anmeldet.** Ohne ihn reißt die Vertrauenskette.
- RRSIG
- Die Signatur selbst, jedem Eintrag beigefügt. Sie trägt eine Gültigkeitsdauer und wird in Abständen erneuert.
- Vertrauenskette
- Das Gefüge, in dem die Signaturen von der Wurzel über die übergeordnete bis zur untergeordneten Zone ineinandergreifen. **Ein Riss an einer einzigen Stelle macht die Prüfung unmöglich.**
- Schlüsselwechsel
- Die Arbeit, einen Schlüssel durch einen neuen zu ersetzen. **Ein Fehler im Ablauf macht die ganze Domäne unerreichbar.**
- Prüfender Auflöser
- Ein Auflöser, der die DNSSEC-Signaturen tatsächlich nachprüft. **Besteht eine Unstimmigkeit, so gibt er überhaupt keine Antwort.**
Häufig gestellte Fragen
Übrigens – warum DNS eine Möglichkeit brauchte, Spoofing zu verhindern
Als DNS 1983 entworfen wurde, gab es keine kryptografische Möglichkeit, den tatsächlichen Absender einer Antwort zu bestätigen. Ein Resolver vertraute jedem UDP-Paket, das mit einer plausibel aussehenden Transaktions-ID ankam – ein auf Treu und Glauben aufgebautes Protokoll, anfällig für IP-Spoofing und ID-Raten. 2008 zeigte der Sicherheitsforscher Dan Kaminsky der Branche, dass sich diese Schwäche für praktikable, schnelle Cache-Poisoning-Angriffe (das Einschleusen gefälschter Einträge in den Cache eines Resolvers) ausnutzen ließ – eine Entdeckung, die die gesamte DNS-Community erschütterte.
DNSSEC (DNS Security Extensions) ist die standardisierte Antwort auf dieses Problem. Es nutzt Public-Key-Kryptografie, um zu beweisen, dass eine Antwort vom rechtmäßigen Betreiber der Zone signiert wurde. Eine Domain signiert ihre Einträge mit ihrem DNSKEY, und ein in der übergeordneten Zone registrierter DS-Eintrag bezeugt den Digest dieses Schlüssels – so entsteht eine ununterbrochene Vertrauenskette von der DNS-Root bis zur einzelnen Domain.
Das AD-Flag (Authenticated Data) in einer DoH-Antwort (DNS over HTTPS) ist das Ergebnis dieser DNSSEC-Validierung, die der Resolver stellvertretend für Sie durchgeführt hat. Anwendungen müssen die Signaturprüfung nicht selbst implementieren – die Abfrage bei einem vertrauenswürdigen Resolver mit AD=true ist eine indirekte Zusicherung, dass die Antwort nicht manipuliert wurde, sofern die Übertragung zwischen Resolver und Anwendung (HTTPS) separat abgesichert ist.