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

  1. Geben Sie die Domäne ein Nennen Sie allein die Domäne, in der Form `example.com`.
  2. Lesen Sie das Ergebnis der Prüfung **Es beurteilt, ob die Kette der Signaturen bis zur übergeordneten Zone reicht.**
  3. Bestätigen Sie, ob ein DS-Eintrag besteht **Fehlt er, so wird nichts bestätigt, wie viele Schlüssel Sie auch hinterlegt haben.**
  4. 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

„DNSSEC nicht aktiviert“ ist für sich genommen nicht gefährlich – die große Mehrheit der Domains läuft nach wie vor ohne DNSSEC. Dennoch lohnt es sich, die Aktivierung als Schutz vor DNS-Cache-Poisoning in Betracht zu ziehen, sofern möglich.

Nutzer, die Resolver mit erzwungener DNSSEC-Validierung verwenden (viele Unternehmensnetzwerke und einige Internetanbieter), können die Domain unter Umständen gar nicht mehr auflösen, da sie als SERVFAIL behandelt wird. Sofern es sich nicht um einen vorübergehenden Zustand direkt nach der Aktivierung von DNSSEC handelt, während der DS-Eintrag propagiert, ist eine schnelle Korrektur erforderlich.

Direkt nach einem DNSKEY-Rollover (Schlüsselwechsel) können alte und neue Schlüssel kurzzeitig in den Caches der Resolver koexistieren, was zu vorübergehend abweichenden Validierungsergebnissen führt. Warten Sie etwas und prüfen Sie erneut.

Nein. DNSSEC garantiert, dass eine Namensauflösungsantwort nicht manipuliert wurde, während SSL/TLS garantiert, dass die Verbindung selbst verschlüsselt ist und der Server das vorgelegte Zertifikat tatsächlich besitzt. Beide sind unabhängig voneinander – eine Domain kann das eine ohne das andere haben.

Dieses Tool prüft nur den oberflächlichen Status: ob ein DNSKEY veröffentlicht ist und ob Resolver das AD-Flag melden. Für eine rigorose Analyse der gesamten Signaturkette (Konsistenz von RRSIG/NSEC/NSEC3 usw.) kombinieren Sie dies mit einem spezialisierten Tool wie dnsviz.net.
Tool-kun

Ü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.