Was das DNSSEC-Modul an Ihrer Vertrauenskette validiert: Signierung, DS-Records, Algorithmus-Wahl, Signatur-Laufzeiten und Authenticated Denial – mit Bewertung und Behebung.
Jetzt Domain prüfen →
Stand: Juli 2026 · 8 Checks dokumentiert
DNSSEC aktiviert (Zone signiert) #
DNSSEC signiert DNS-Antworten kryptografisch und schützt so vor Manipulation/Cache-Poisoning. Ohne DNSSEC sind DNS-basierte Sicherheitsmechanismen (z. B. DANE) wirkungslos.
Bewertungpass, wenn DNSKEY-Records vorhanden sind; sonst fail. Gewicht 3. Wird ein Hostname (z. B. www.example.com) gescannt, wird die umschließende Zone bewertet – DNSKEY-Records existieren nur am Zonen-Apex.
BehebungDNSSEC beim DNS-Provider/Registrar aktivieren (Zone signieren + DS registrieren).
DS-Record in der Elternzone #
Der DS-Record verankert die Signatur der Zone in der globalen Vertrauenskette. Ohne ihn ist die Signatur zwar vorhanden, aber nicht überprüfbar verankert.
Bewertungpass, wenn ein DS-Record vorhanden ist; sonst fail (nur bei signierter Zone relevant). Gewicht 2.
BehebungDen DS-Record beim Domain-Registrar hinterlegen (oft automatisch über einen Schalter „DNSSEC aktivieren“).
Validierung durch Resolver (AD-Flag) #
Ein validierender Resolver setzt das AD-Flag nur, wenn die gesamte Signaturkette kryptografisch aufgeht. Fehlt es trotz Signatur, ist die Kette unvollständig oder fehlerhaft (bogus).
Bewertungpass bei AD=1; warn ohne AD; SERVFAIL → fail (Signaturen ungültig). Gewicht 3. Bei Hostnamen gilt: Validiert die Zone, löst der Host aber per CNAME in eine unsignierte Zone auf (typisch bei CDNs), ist das Finding ein warn – die finalen Adressen sind nicht Ende-zu-Ende authentifiziert.
BehebungEine vollständige, gültige Kette sicherstellen: DS in der Elternzone, gültige RRSIGs, konsistente Algorithmen. CNAME-Ziele in fremden, unsignierten Zonen (CDN) liegen meist außerhalb der eigenen Kontrolle und sind akzeptabel.
Schlüsselalgorithmen & -stärke #
Veraltete Algorithmen (RSA/SHA-1, DSA) gelten als schwach. RFC 9905 verbietet SHA-1-basiertes DNSSEC-Signieren vollständig; RFC 9904 (löst RFC 8624 ab) stuft RSA/SHA-512 (Alg. 10) als NOT RECOMMENDED ein. Empfohlen sind RSA/SHA-256 (8), ECDSA P-256 (13) oder Ed25519 (15). Bei RSA zählt zusätzlich die Schlüssellänge: Kurze Schlüssel lassen sich faktorisieren – historisch nutzten Zonen 1024-Bit-Zone-Signing-Keys mit häufigen Rollovers, heute werden mindestens 2048 Bit erwartet.
Bewertungpass bei modernen Algorithmen und ausreichenden Schlüssellängen; warn bei RSA/SHA-512 oder RSA unter 2048 Bit; fail bei veralteten/verbotenen Algorithmen (RSA/SHA-1, RSASHA1-NSEC3-SHA1, DSA, RSA/MD5) oder RSA unter 1024 Bit (praktisch brechbar). Gewicht 2. Die Schlüssellängen-Grenzen gelten nur für RSA – ECDSA-/Ed25519-Schlüssel haben feste, ausreichende Größen.
BehebungDie Zone auf einen modernen Algorithmus migrieren – ECDSA P-256 (13) oder Ed25519 (15), deren Schlüssel und Signaturen deutlich kleiner sind – oder RSA ≥ 2048 Bit verwenden (Key-Rollover).
DS-Digest-Algorithmus #
Der DS-Record referenziert den DNSKEY über einen Hash. SHA-1 als Digest-Typ ist veraltet; empfohlen ist SHA-256 (Typ 2).
Bewertungpass bei SHA-256+; warn bei SHA-1. Gewicht 1.
BehebungDS-Records mit Digest-Typ 2 (SHA-256) veröffentlichen.
RRSIG-Restlaufzeit #
DNSSEC-Signaturen (RRSIG) haben ein Ablaufdatum. Laufen sie ab, behandeln validierende Resolver die gesamte Zone als bogus – die Domain ist nicht mehr auflösbar. Provider, die online signieren, nutzen bewusst kurze Gültigkeitsfenster (1–7 Tage) und signieren laufend nach – dort ist eine kurze Restlaufzeit zu erwarten.
Bewertungpass bei > 7 Tagen. Bei kurzlebigen Signaturen (Gültigkeitsfenster ≤ 8 Tage, also automatisches Nachsignieren) pass, solange mehr als ein Tag verbleibt. warn darunter; abgelaufen → fail + Cap F. Gewicht 1.
BehebungAutomatisches Nachsignieren der Zone sicherstellen (die meisten DNS-Provider erledigen das automatisch).
Authenticated Denial (NSEC/NSEC3) #
NSEC/NSEC3 beweisen die Nichtexistenz von Einträgen. NSEC erlaubt „Zone-Walking“ (vollständige Enumeration der Zone); NSEC3 erschwert das, sollte aber gemäß RFC 9276 mit 0 Iterationen und ohne Opt-out laufen.
Bewertungpass bei NSEC3 ohne zusätzliche Iterationen und mit leerem Salt; warn bei zusätzlichen Iterationen oder nicht-leerem Salt (Opt-out ist aus dem NSEC3PARAM nicht erkennbar); NSEC ist info. Gewicht 0–1.
BehebungNSEC3 mit 0 Iterationen verwenden (RFC 9276); bei sensiblen Zonen NSEC durch NSEC3 ersetzen.
Automatisierte DS-Pflege (CDS/CDNSKEY) #
Mit CDS-/CDNSKEY-Records (RFC 7344/8078) teilt die Zone ihrer Elternzone mit, welche DS-Records sie wünscht – Registries/Registrare, die sie auswerten, aktualisieren den DS bei Key-Rollovers automatisch und beseitigen damit den fehleranfälligsten manuellen DNSSEC-Schritt. Der Spezial-Record CDS 0 0 0 0 fordert die ENTFERNUNG des DS an, also das Abschalten von DNSSEC.
Bewertunggood, wenn CDS-Records veröffentlicht sind (ob sie zum DS-Set passen, das initiale DS abwarten oder ein DS-Update aussteht); warn, wenn der Lösch-Record veröffentlicht ist (DNSSEC-Entfernung steht bevor – meist unbeabsichtigt); info, wenn keine CDS-Records veröffentlicht sind. Gewicht 0 – beeinflusst die Note nie.
BehebungOptional: CDS-/CDNSKEY-Veröffentlichung beim DNS-Provider aktivieren, wenn die Registry RFC-8078-Scanning unterstützt.