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.

Tipps

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

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.
ツールくん

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