Dieser kostenlose Test prüft die DNSSEC-Konfiguration Ihrer Domain in acht Einzelprüfungen: Ist die Zone signiert? Ist der DS-Record beim Parent verankert? Akzeptieren validierende Resolver die Kette (AD-Flag)? Wie lange sind die Signaturen noch gültig, und entsprechen die Schlüssel-Algorithmen dem aktuellen Stand? Jetzt Domain prüfen →
DNSSEC signiert DNS-Antworten kryptografisch: Die Zone veröffentlicht ihre Schlüssel als
DNSKEY-Records und signiert jeden Record-Satz (RRSIG). Verankert wird das
Ganze über einen DS-Record in der übergeordneten Zone – so entsteht eine lückenlose
Vertrauenskette von der DNS-Root über die TLD bis zu Ihrer Domain. Ohne DNSSEC lassen sich
DNS-Antworten fälschen (Cache-Poisoning), und darauf aufbauende Mechanismen wie
DANE sind wirkungslos.
Viele Zonen sind signiert, aber der DS-Record fehlt beim Registrar. Dann existieren die Signaturen zwar, hängen aber in der Luft: Validierende Resolver behandeln die Zone wie eine unsignierte – der Schutz ist null, ohne dass es jemand merkt. Der umgekehrte Fall ist gefährlicher: Ist ein DS-Record gesetzt, aber die Signaturen sind abgelaufen oder passen nach einem Schlüsselwechsel nicht mehr, gilt die Zone als „bogus“ – validierende Resolver antworten mit SERVFAIL und die Domain ist für einen Großteil des Internets unerreichbar. Dieser Test unterscheidet beide Fälle sauber: Er prüft DNSKEY, DS und die Resolver-Validierung getrennt.
Der Test bewertet zusätzlich die RSA-Schlüssellänge (unter 2048 Bit: Warnung; unter 1024 Bit: praktisch brechbar, Fehler) und den Digest-Algorithmus des DS-Records.
Die DENIC signiert die .de-Zone seit 2011 – jeder .de-Inhaber kann DNSSEC nutzen, sofern Registrar und DNS-Provider mitspielen. Relevanz hat das vor allem für E-Mail: DANE setzt DNSSEC zwingend voraus, und die BSI-Richtlinie TR-03108 („Sicherer E-Mail-Transport“) verlangt von zertifizierten E-Mail-Diensteanbietern DNSSEC und DANE. Wer DNSSEC aktiviert, legt also das Fundament für erzwungen verschlüsselten Mailtransport.
Der häufigste Grund: Der DS-Record fehlt beim Parent (Registrar/Registry). Die Signaturen existieren dann zwar, sind aber nicht in der Vertrauenskette verankert – validierende Resolver behandeln die Zone wie eine unsignierte, der Schutz ist wirkungslos.
Empfohlen sind ECDSA P-256 (Algorithmus 13) oder Ed25519 (15) – beide erzeugen deutlich kleinere Schlüssel und Signaturen als RSA. RSA/SHA-256 (8) mit mindestens 2048 Bit ist weiterhin in Ordnung. SHA-1-basierte Algorithmen (5 und 7) sind nach RFC 9905 für das Signieren verboten.
Ja, bei Betriebsfehlern: Laufen die RRSIG-Signaturen ab oder passt der DS-Record nach einem Schlüsselwechsel nicht mehr, gilt die Zone als „bogus“ und validierende Resolver liefern SERVFAIL. Dagegen helfen automatisches Re-Signing beim DNS-Provider und CDS/CDNSKEY für die automatische DS-Pflege – dieser Test zeigt die Restlaufzeit der Signaturen an.
RFC 4033 (DNSSEC-Grundlagen) ↗ · RFC 9904 (Algorithmus-Empfehlungen) ↗ · RFC 9905 (SHA-1-Verbot beim Signieren) ↗ · RFC 9276 (NSEC3-Parameter) ↗