← Frankys Web GitHub Kontakt
Frankys Web Mailtools

E-Mail-Konfigurationen prüfen und verstehen

DNSSEC Check

DNSSEC-Vertrauenskette einer Domain prüfen: DS, DNSKEY, RRSIG, Algorithmen.

DNSSEC signiert DNS-Antworten kryptografisch und verhindert so, dass sie unterwegs unbemerkt gefälscht werden, etwa bei Cache-Poisoning oder einem Man-in-the-Middle im Netzwerkpfad. Die Vertrauenskette beginnt bei der Root-Zone und läuft über jede Delegation: der Parent veröffentlicht einen DS-Record, der auf den DNSKEY der Kindzone zeigt, und jede signierte RRset trägt eine begleitende RRSIG. Für E-Mail ist DNSSEC die Grundlage für DANE (siehe DANE Check): ohne eine intakte Kette ist ein TLSA-Record wirkungslos, weil er sich sonst unbemerkt entfernen oder ersetzen ließe.

Was dieses Werkzeug prüft

Es holt den DS-Record der Domain (wird an der Delegation beim Parent beantwortet), die DNSKEY-RRset der Zone selbst und die begleitende RRSIG. Je Schlüssel werden Algorithmus (RSASHA256, ECDSAP256SHA256, ED25519 und weitere), die tatsächliche Schlüssellänge und die Rolle Key-Signing-Key oder Zone-Signing-Key gezeigt (über das SEP-Flag). Je DS-Record wird der Digest-Typ bewertet (SHA-256 gut, SHA-1 veraltet). Unabhängig vom Resolver wird außerdem der DS-Digest tatsächlich neu aus dem vorhandenen DNSKEY berechnet und verglichen (RFC 4034 §5.1.4): das ist eine reine Prüfsumme, keine Signaturprüfung, aber eine von jedem Resolver unabhängige Tatsachenfeststellung, ob DS und DNSKEY überhaupt zusammenpassen. Zusätzlich wird das AD-Flag der Antwort ausgewertet, also ob der genutzte Resolver die Kette selbst als validiert markiert. Liefert der Upstream kein AD (alte Resolver, DNS-Interception im lokalen Netz), meldet das Werkzeug das offen, statt fälschlich Sicherheit zu behaupten. Hat die eingegebene Domain selbst keine eigenen DNSSEC-Records, prüft das Werkzeug zusätzlich die registrierbare Domain, weil DNSSEC so gut wie immer dort eingerichtet wird, nicht auf jeder Subdomain einzeln.

Das Ergebnis lesen

Grün heißt: DS und DNSKEY sind vorhanden, der berechnete Digest passt zum DS-Record, die RRSIG ist gültig, und, falls der genutzte Resolver das bestätigen kann, ist das AD-Flag gesetzt. Kein DS und kein DNSKEY ist kein Fehler, sondern der Hinweis, dass DNSSEC für diese Domain nicht eingerichtet ist. Ein Fehler ist es dagegen, wenn nur eine Seite der Kette existiert (DS ohne DNSKEY oder umgekehrt) oder wenn der nachgerechnete Digest nicht zum DS passt: in beiden Fällen lehnen validierende Resolver die Zone komplett ab (bogus), die Domain wird für sie unerreichbar. Eine echte Signaturprüfung (ob die RRSIG tatsächlich zum privaten Schlüssel passt) macht dieses Werkzeug nicht selbst, das bleibt Aufgabe des validierenden Resolvers.

Grundlagen

DNSSEC ist in RFC 4033 bis 4035 definiert, die DS-Digest-Berechnung in RFC 4034 §5.1.4, moderne elliptische-Kurven-Algorithmen in RFC 6605 (ECDSA) und RFC 8080 (EdDSA). Das AD-Flag (Authenticated Data) einer DNS-Antwort ist in RFC 4035 §3.2.3 und RFC 6840 §5.7 beschrieben: es zeigt an, dass der befragte, rekursive Resolver die Antwort selbst per DNSSEC validiert hat. Ein Endnutzer-Resolver ohne DNSSEC-Unterstützung liefert dieses Flag nie, unabhängig davon, ob die Domain tatsächlich signiert ist.

Typische Fehlerbilder und wie man sie behebt

  • DS beim Parent, aber keine DNSKEY in der Zone. Meist eine abgebrochene Migration oder ein zu früh gesetzter DS-Record. Die Zone muss erst signiert werden (DNSKEY + RRSIG veröffentlichen), bevor der DS-Record beim Registrar hinterlegt wird, sonst ist die Domain für validierende Resolver komplett unerreichbar.
  • DNSKEY vorhanden, aber kein DS beim Parent. Die Zone signiert sich selbst, aber niemand vertraut ihr, weil die Kette vom Parent aus nicht weiterführt. Den passenden DS-Record beim Registrar oder DNS-Provider hinterlegen.
  • DS-Digest passt nicht zum DNSKEY. Meist nach einem Schlüsselwechsel (Key-Rollover), bei dem der alte DS-Record nicht rechtzeitig durch den neuen ersetzt wurde. Den aktuellen DS-Record für den neuen KSK veröffentlichen.
  • RRSIG abgelaufen oder läuft bald ab. Meist ein Problem der automatischen Neusignierung beim DNS-Provider. Ohne Eingriff wird die Zone nach Ablauf für validierende Resolver ungültig.
  • SHA-1 als DS-Digest-Typ. Gilt als veraltet. Beim nächsten Schlüsselwechsel auf SHA-256 (Digest-Typ 2) umstellen.

Häufige Fragen

Was ist der Unterschied zwischen DS und DNSKEY?
Der DNSKEY-Record enthält den öffentlichen Schlüssel der Zone und liegt in der Zone selbst. Der DS-Record ist ein Fingerabdruck dieses Schlüssels und liegt beim Parent (z. B. bei der Top-Level-Domain), er stellt die Verbindung zur Vertrauenskette her.
Was bedeutet KSK und ZSK?
Key-Signing-Key (KSK) signiert die DNSKEY-RRset und wird über den DS-Record beim Parent verankert. Zone-Signing-Key (ZSK) signiert die übrigen Records der Zone und wechselt üblicherweise häufiger. Erkennbar am SEP-Flag im DNSKEY-Record (gesetzt = KSK).
Warum zeigt das Werkzeug 'nicht bestätigt' statt Grün, obwohl DS und DNSKEY zusammenpassen?
Der genutzte DNS-Resolver liefert kein AD-Flag, validiert die Kette also nicht selbst (oder wird auf dem Weg dorthin manipuliert). Der nachgerechnete DS-Digest ist trotzdem eine verlässliche, resolverunabhängige Aussage, dass die Records strukturell zusammenpassen, eine echte Signaturprüfung ersetzt das aber nicht.
Warum steht bei meiner Subdomain 'nicht eingerichtet', obwohl die Domain DNSSEC nutzt?
DS-Records existieren nur an tatsächlichen Delegationspunkten, praktisch immer die registrierbare Domain, nicht jede Subdomain einzeln. Das Werkzeug prüft automatisch zusätzlich die registrierbare Domain, wenn die eingegebene Subdomain selbst keine eigenen DNSSEC-Records hat.
Wie richte ich DNSSEC für meine Domain ein?
Das übernimmt normalerweise der DNS-Provider auf Knopfdruck (Zone signieren, DNSKEY und RRSIG veröffentlichen). Danach den angezeigten DS-Record beim Registrar der Domain hinterlegen, damit der Parent die Delegation als sicher markiert. Die genauen Schritte unterscheiden sich je Anbieter.
Was hat DNSSEC mit E-Mail zu tun?
Direkt genutzt wird es von DANE (TLSA-Records für SMTP, siehe DANE Check): ein TLSA-Record ohne DNSSEC ließe sich unterwegs unbemerkt entfernen oder ersetzen. SPF, DKIM und DMARC selbst setzen kein DNSSEC voraus, profitieren aber allgemein vom Schutz vor gefälschten DNS-Antworten.