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: September 2026 · 8 Checks dokumentiert
DNSSEC aktiviert (Zone signiert) #
DNSSEC versieht die RRsets einer Zone mit kryptografischen Signaturen (RFC 4033 §3.1); ein validierender Resolver erkennt damit manipulierte oder vergiftete DNS-Daten. Signiert sind die Daten der Zone, nicht die Antwort darum herum – Header, RCODE, AD-Bit und Transport sind nicht gedeckt; der Schutz reicht deshalb genau so weit wie ein Resolver, der wirklich validiert, und ein Stub, der bloß dem AD-Bit seines Resolvers glaubt, vertraut diesem Resolver, nicht einer Signatur (RFC 4033 §5). Ohne DNSSEC sind DNS-basierte Sicherheitsmechanismen (z. B. DANE) wirkungslos.
Bewertungpass, wenn DNSKEY-Records vorhanden sind; fail, wenn die Zone keine veröffentlicht. Bleibt unsere eigene DNSKEY-Abfrage ohne schlüssige Antwort (DNS-/DoH-Fehler, SERVFAIL, REFUSED), wird der Check als „nicht bestimmbar“ übersprungen, statt die Zone für unsigniert zu erklären. Eine Zone ohne DNSKEY, bei deren Parent noch ein DS-Record steht – oder die validierende Resolver ablehnen –, wird als defekt (bogus) berichtet, nicht als unsigniert. 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 der Parent einen DS-Record veröffentlicht. fail, wenn die Zone signiert ist und der Parent keinen veröffentlicht, wenn DS-Records existieren, von denen keiner nach Key-Tag UND Algorithmus zu einem veröffentlichten DNSKEY passt (ein veralteter DS – es sei denn, ein validierender Resolver authentifiziert die Zone bereits, dann hinkt ein Cache einem Key-Rollover hinterher, statt dass der Record veraltet ist), oder wenn ein DS existiert, während die Zone gar keinen DNSKEY veröffentlicht. Die beiden letzten Fälle deckeln das Modul zusätzlich auf F, weil validierende Resolver dann jeden Record der Zone ablehnen. Ließ sich der DS selbst nicht abrufen, zählt eine AD=1-Antwort als pass: Sie belegt eine validierte Kette bis zu dieser Zone. Ein bestätigter SERVFAIL zählt ebenfalls als pass, aber auf schwächerer Grundlage – SERVFAIL ist ein einziges, undifferenziertes Signal (RFC 4033 §5) und sagt nicht, WELCHE Zone bogus ist; ein Bruch in der Elternzone würde also dieser hier zugeschrieben. Der Wert daneben sagt deshalb, dass der Anker erschlossen und nicht gelesen wurde. skip, wenn die Zone unsigniert ist oder die DNSKEY-/DS-Abfrage keine schlüssige Antwort lieferte. 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 er alle RRsets im Answer- und im Authority-Abschnitt selbst authentifiziert hat (RFC 4035 §3.2.3); zudem sollen Resolver es nur setzen, wenn die Anfrage das DO- oder AD-Bit trug (RFC 6840 §5.8 – unsere tut das). Ein fehlendes AD-Flag heißt deshalb NICHT „bogus“, sondern „nicht authentifiziert“ – ein unsignierter (insecure) Zweig, ein Resolver, der nicht validiert, oder eine auf unserer Seite fehlgeschlagene Abfrage, die dieser Check getrennt als „nicht bestimmbar“ ausweist. Eine wirklich defekte Kette sieht anders aus: Der Resolver antwortet mit SERVFAIL (RFC 4035 §5.5).
Bewertungpass bei AD=1; warn, solange weder ein AD-Flag noch ein per Zweitabfrage ohne Validierung bestätigter SERVFAIL vorliegt (nicht authentifiziert – und ein SERVFAIL ohne diese Gegenprobe gilt als vorübergehend, nicht als bogus); fail beim bestätigten SERVFAIL, samt Cap F: Für sich allein ist SERVFAIL der generische Server-Fehlercode und belegt nichts über Signaturen. skip, wenn die Zone unsigniert ist, wenn die DNSKEY-/DS-Abfrage keine schlüssige Antwort lieferte oder wenn unsere eigene validierende Abfrage fehlschlug – ein AD-Flag, das wir nie gesehen haben, ist keine Aussage über die Kette. Gewicht 3. Bei Hostnamen: Validiert die Zone, löst der Host aber über einen CNAME in einen nicht authentifizierten Zweig auf (typisch bei CDNs), ist der Befund ein warn mit Gewicht 1 – die finalen Adressen sind nicht Ende-zu-Ende authentifiziert. Validiert die Zone selbst, antwortet ein validierender Resolver für den Host aber mit SERVFAIL, ist es ein fail: Hinter validierenden Resolvern löst dieser Name gar nicht auf.
BehebungEine vollständige, gültige Kette sicherstellen: DS in der Elternzone, gültige RRSIGs, konsistente Algorithmen. Ein CNAME-Ziel, das von keiner validierten Signaturkette gedeckt ist (typischerweise ein CDN), liegt meist außerhalb der eigenen Kontrolle und ist akzeptabel – die signierte Zone schützt den CNAME selbst weiterhin. Nicht akzeptabel ist ein CNAME-Ziel, dessen eigene Kette signiert und KAPUTT ist: Validierende Resolver antworten dann mit SERVFAIL, der Host ist für deren Nutzer nicht erreichbar. In dem Fall die Kette des Ziels reparieren oder den Namen auf ein Ziel zeigen lassen, dessen Zone validiert.
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. NIST SP 800-131A Rev. 2 verbietet RSA unter 2048 Bit für die Signaturerzeugung und stuft 1024–2047 Bit nur noch als Legacy-Use für die Prüfung ein – dieselbe Zweiteilung, der unsere beiden Schwellen folgen (warn unter 2048, fail unter 1024).
Bewertungpass bei modernen Algorithmen und ausreichenden Schlüssellängen; warn bei RSA/SHA-512 oder RSA unter 2048 Bit; fail bei Algorithmen, die das IANA-Register zum Signieren als MUST NOT führt – RSA/MD5 (1), DSA (3), RSA/SHA-1 (5), DSA-NSEC3-SHA1 (6), RSASHA1-NSEC3-SHA1 (7) und ECC-GOST (12, über RFC 9906) – 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. Eine Algorithmusnummer, die unsere Tabelle nicht kennt, hindert das pass nicht: Der Befund benennt die Lücke im Erklärtext auf unserer Seite, statt sie der Zone anzulasten.
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 oder einem anderen Digest, den das Register für Delegationen zulässt (SHA-384, GOST R 34.11-2012, SM3); warn bei einem Digest, den das IANA-Register für Delegationen als MUST NOT führt, z. B. SHA-1 (Typ 1, RFC 9905) oder GOST R 34.11-94 (Typ 3, RFC 9906). Ausnahme: Ein SHA-1-DS, der neben einem SHA-256-DS veröffentlicht wird, bleibt ein pass – laut RFC 4509 §3 ignorieren Validatoren den SHA-1-Record, solange ein SHA-256-Record vorhanden ist; das ist der normale Zustand einer Digest-Umstellung. Ein Digest-Typ, den unsere Tabelle nicht kennt, hindert das pass nicht; die Lücke wird im Erklärtext benannt. Wird nur bewertet, wenn der Parent einen DS-Record veröffentlicht. Gewicht 1.
BehebungDS-Records mit Digest-Typ 2 (SHA-256) veröffentlichen.
RRSIG-Restlaufzeit #
DNSSEC-Signaturen (RRSIG) haben ein Ablaufdatum. Nach dem Ablauf kann ein validierender Resolver die betroffenen RRsets nicht mehr authentifizieren (RFC 4035 §5.3.1) und antwortet seinen Clients mit SERVFAIL (§5.5 — RCODE 2 an den anfragenden Client; nur eine Anfrage mit gesetztem CD-Bit bekommt noch die vollen Daten, und das CD-Bit ist gerade das Werkzeug des validierenden Clients) – bei einer per DS beim Parent verankerten Zone heißt das in aller Regel, dass die Domain für alle hinter einem validierenden Resolver nicht mehr auflöst. Eine signierte Zone OHNE DS beim Parent ist eine unsichere Delegation (RFC 4035 §5.2): Ihre Signaturen werden nicht geprüft, ein Ablauf berührt die Erreichbarkeit dort also nicht. Eine Signatur, deren Gültigkeit noch gar nicht begonnen hat – vorgehende Uhr des Signers –, wirkt wie eine abgelaufene. Provider, die online signieren, nutzen bewusst kurze Gültigkeitsfenster und signieren laufend nach, eine kurze Restlaufzeit ist dort also erwartbar.
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, solange ein DS beim Parent die Zone verankert; ohne DS prüfen validierende Resolver die Signaturen gar nicht, dann ist es nur ein warn – und blieb die DS-Abfrage selbst ohne Antwort, sagt der Befund das, statt zu raten. Eine Signatur, deren Inception deutlich in der Zukunft liegt (mehr als 24 h – Signierer datieren bewusst zurück, RFC 6781 §4.4.2), ist noch nicht gültig und fällt immer durch, mit oder ohne DS. Cap F gilt bei abgelaufener oder noch nicht gültiger Signatur nur, solange die Zone verankert ist UND kein validierender Resolver mit AD=1 widerspricht. Welche Signatur gemessen wird: Ein RRset kann mehrere RRSIGs tragen – RFC 4035 §2.2 verlangt mindestens eine je Algorithmus des DNSKEY-Satzes der Zone und erlaubt ausdrücklich weitere, und ein Double-Signature-ZSK-Rollover veröffentlicht zwei desselben Algorithmus (RFC 6781 §4.1.1.2) –, deshalb entscheidet die mit der spätesten Ablaufzeit; ein übrig gebliebener Signierpfad wird benannt, nicht als Ablauf gewertet. Gewicht 1.
BehebungAutomatisches Nachsignieren der Zone sicherstellen (die meisten DNS-Provider erledigen das automatisch). Ist die Signatur noch nicht gültig, die Uhr des Signiersystems synchronisieren (NTP) und die Zone neu signieren. Wird neben einer gültigen noch eine abgelaufene Zweitsignatur veröffentlicht, den übrig gebliebenen Signierpfad nach Abschluss des Rollovers entfernen.
Authenticated Denial (NSEC/NSEC3) #
NSEC/NSEC3 beweisen die Nichtexistenz von Einträgen. Bei klassischem, vorberechnetem NSEC lässt sich der Zoneninhalt per Zone-Walking aufzählen; Online-Signierer, die minimal abdeckende NSEC-Records liefern (RFC 4470, „White Lies“) oder Compact Denial of Existence fahren (RFC 9824), sind davon nicht betroffen. NSEC3 hasht die Namen, doch RFC 9276 §2.3 stuft diesen Schutz als bestenfalls mäßig ein – häufige Präfixe fallen einem Wörterbuch zum Opfer, und die einsammelbare Hash-Kette lässt sich offline knacken. §3.1 (BCP 236) stellt NSEC vor NSEC3, sofern die betrieblichen oder sicherheitsbezogenen Eigenschaften von NSEC3 nicht gebraucht werden. Wird NSEC3 eingesetzt, verlangt RFC 9276 §3.1 0 Iterationen und bittet Betreiber, keinen Salt zu verwenden; Opt-out ist für kleine Zonen NOT RECOMMENDED, für sehr große, dünn signierte Zonen aber zulässig (MAY).
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. Schlägt die NSEC3PARAM-Abfrage fehl – gar keine Antwort oder ein Fehler-Rcode des Servers –, sagt die Zeile „nicht ermittelt“ (skip) und zählt als nicht gemessen; das Gewicht, das sie getragen hätte, bleibt so im Bericht sichtbar, statt still aus dem Nenner zu verschwinden. Gewicht 0–1.
BehebungNutzt die Zone NSEC3, dieses mit 0 Iterationen und ohne Salt betreiben (RFC 9276 §3.1). Nicht aus Gewohnheit von NSEC auf NSEC3 wechseln: RFC 9276 §3.1 stellt NSEC voran, sofern die betrieblichen oder sicherheitsbezogenen Eigenschaften von NSEC3 nicht gebraucht werden, und §2.3 stuft dessen Enumerationsschutz als bestenfalls mäßig ein. Wo das Aufzählen des Zoneninhalts wirklich eine Rolle spielt, helfen minimal abdeckende NSEC-Records (RFC 4470) oder Compact Denial of Existence (RFC 9824) – beides kostet wie NSEC3 Rechenzeit, also vor dem Wechsel messen.
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. Geprüft werden BEIDE RRsets der Zone: RFC 7344 §4 erlaubt, nur einen der beiden Typen zu veröffentlichen, und wenn beide veröffentlicht sind, müssen sie inhaltlich übereinstimmen. Der Spezial-Record CDS 0 0 0 0 (bzw. CDNSKEY 0 3 0 0) fordert die ENTFERNUNG des DS an, also das Abschalten von DNSSEC. Die automatische DS-Pflege bei Key-Rollovern regelt RFC 7344; RFC 8078 ergänzt das initiale Enrollment und das Löschsignal, und für das ERSTE DS ist inzwischen das authentifizierte Bootstrapping nach RFC 9615 (das RFC 8078 aktualisiert) der bevorzugte Weg. Der Drilldown ergänzt, ob die Elternzone einen DSYNC-Notify-Endpunkt (RFC 9859) veröffentlicht – ob sie also über ein neues CDS-/CDNSKEY-RRset benachrichtigt werden kann, statt es abfragen zu müssen.
Bewertunggood, wenn CDS- oder CDNSKEY-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) oder wenn CDS und CDNSKEY beide veröffentlicht sind, aber nicht dieselben Schlüssel beschreiben (RFC 7344 §4); info, wenn keiner von beiden veröffentlicht ist; „nicht geprüft“ (skip), wenn das Zeitbudget des Moduls schon von den Pflichtabfragen vor diesem optionalen Paar aufgebraucht war – über die Zone wird dann nichts behauptet, und weil es die eigene Obergrenze ist, trägt der Skip weder Gewicht noch Vorbehalt. Gewicht 0 – beeinflusst die Note nie.
BehebungOptional: die CDS-/CDNSKEY-Veröffentlichung beim DNS-Provider aktivieren. RFC 7344 §4 empfiehlt, CDS und CDNSKEY beide zu veröffentlichen (SHOULD, inhaltsgleich); welchen von beiden Ihre Elternzone auswertet, entscheidet sie (§6) — sie darf nur einen akzeptieren. Wertet die Registry sie aus (RFC 8078), wird der DS anschließend automatisch gepflegt; für das erste DS ist das authentifizierte Bootstrapping nach RFC 9615 der bevorzugte Weg.