DNSSEC Checker

Warum DNSSEC prüfen?

DNSSEC (DNS Security Extensions) fügt den DNS-Antworten eine kryptografische Prüfung hinzu. Ohne diesen Schutz kann ein Angreifer Antworten fälschen und Ihren Traffic auf seine eigenen Server umleiten. Das ist das Prinzip des Cache Poisoning.

Die Gefahr ist lautlos. Ein verwaister DS oder ein unvollständiger key rollover lässt eine Domain verschwinden. Kein HTTP-Monitoring, kein Ping, kein Uptime-Check erkennt dieses Problem. Diese stillen Ausfälle dauern tagelang an. Validierende Resolver (Google, Cloudflare, Quad9) liefern SERVFAIL statt der erwarteten Antwort.

Vier Gründe, Ihr DNSSEC zu prüfen:

• Sicherheit: Bestätigen Sie, dass die Kette intakt ist. Ihre Besucher erreichen Ihre Server, nicht die eines Angreifers.
• Verfügbarkeit: Ein gebrochenes DNSSEC blockiert validierende Resolver, also etwa ein Drittel bis 40 % der weltweiten Anfragen laut APNIC-Messungen. Google, Cloudflare und Quad9 weisen die Antwort ab.
• Compliance: Banken, Behörden, Gesundheitswesen und E-Commerce verlangen DNSSEC für kritische Domains.
• Früherkennung: Erkennen Sie verwaiste DS, schwache Algorithmen und abgelaufene Signaturen, bevor ein Ausfall eintritt.

So verwenden Sie den DNSSEC Checker in 3 Schritten

Schritt 1: Domain eingeben

Geben Sie den zu prüfenden Domainnamen ein (z. B. cloudflare.com oder nic.fr). Das Tool akzeptiert jede Domain, ob DNSSEC-signiert oder nicht. Ist DNSSEC nicht aktiviert, zeigt das Ergebnis dies sofort an.

Schritt 2: Analysemodus wählen

• Modus Einfach (Standard): Prüft die vollständige Vertrauenskette über einen autoritativen Server pro Zone. Ergebnis in 1 bis 3 Sekunden.
• Modus Vollständig: Ergänzt die DNSKEY-Konsistenz über alle autoritativen Server. Validiert zudem die RRSIG-Signaturen auf SOA, NS, A und MX. Ergebnis in 5 bis 10 Sekunden.

Im Zweifel beginnen Sie mit dem Modus Einfach. Nutzen Sie den Modus Vollständig nach einem key rollover, einer DNS-Migration oder für ein Sicherheitsaudit.

Schritt 3: Bericht analysieren und korrigieren

Der Bericht klassifiziert jede Anomalie nach Schweregrad:

• Fehler blockieren die Auflösung. Gebrochene Kette, ungültige Signaturen, Inkonsistenz zwischen Servern.
• Warnungen erfordern eine Maßnahme. Verwaiste DS, schwache Algorithmen, bald ablaufende RRSIG.
• Informationen erfordern keine Maßnahme. CSK erkannt, NS außerhalb des Bailiwicks, Anzahl der DS beim Parent.

Was ist die DNSSEC-Vertrauenskette?

Die DNSSEC-Vertrauenskette (chain of trust) ist eine Kaskade kryptografischer Prüfungen, die wie ein Staffellauf weitergereicht werden. Jede Zone bürgt für die nächste, von der DNS-Root bis zu Ihrer Domain:

Root (.)
  |-- DS des TLD --> verifiziert die DNSKEY des TLD (KSK)
  |-- Die ZSK des TLD signiert den DS Ihrer Domain
        |-- DS Ihrer Domain --> verifiziert Ihre DNSKEY (KSK)
        |-- Ihre KSK signiert das DNSKEY RRSet
        |-- Ihre ZSK signiert die Daten (A, MX, SOA, NS)

Die wichtigsten Einträge:

Jedes Glied hängt vom vorherigen ab. Ein einziges gebrochenes Glied, und die gesamte Kette bricht zusammen. Validierende Resolver liefern dann SERVFAIL.

NSEC und NSEC3: der authentifizierte Nichtexistenz-Nachweis

DNSSEC signiert nicht nur vorhandene Einträge. Es weist auch authentifiziert nach, dass ein Name oder ein Eintragstyp nicht existiert. Ohne diesen Nachweis könnte ein Angreifer die Existenz eines tatsächlich signierten Eintrags leugnen. Zwei Mechanismen sichern diesen Nichtexistenz-Nachweis:

• NSEC (Next Secure) verkettet die Namen der Zone in alphabetischer Reihenfolge. Jeder NSEC-Eintrag verweist auf den nächsten vorhandenen Namen. Der Nachteil: Wer dieser Kette Schritt für Schritt folgt, kann alle Namen der Zone aufzählen. Das ist Zone Walking.
• NSEC3 (RFC 5155) behebt dieses Problem, indem es Hashes der Namen statt der Klartextnamen veröffentlicht. Zone Walking wird deutlich aufwendiger, da die Hashes erst gebrochen werden müssen. NSEC3 ergänzt einen Salt und eine Anzahl von Iterationen.

Das NSEC3-Opt-out ist eine Option für sehr große Zonen (TLD, Zonen mit zahlreichen unsignierten Delegationen). Es vermeidet die Erzeugung eines NSEC3-Nachweises für ungesicherte Delegationen, was die Zonengröße und den Signieraufwand reduziert. Im Gegenzug authentifiziert das Opt-out das Fehlen dieser Delegationen nicht.

Für die meisten Domains eignen sich NSEC oder NSEC3. NSEC3 ist vorzuziehen, wenn Sie die Aufzählung Ihrer Zone einschränken möchten.

Was prüft das Tool genau?

Modus Einfach

Modus Vollständig (zusätzlich)

Häufige Diagnosen und Lösungen

Verwaister DS (DNSSEC_DS_ORPHAN)

Symptom: Ein DS-Eintrag ist beim Parent veröffentlicht, aber keine passende DNSKEY existiert in Ihrer Zone.

Wahrscheinliche Ursache: Unvollständiger key rollover. Der alte Schlüssel wurde aus der Zone entfernt, bevor der DS beim Registrar aktualisiert wurde.

Maßnahme: Entfernen Sie den verwaisten DS über Ihren Registrar oder fügen Sie die passende DNSKEY hinzu. Starten Sie den Test erneut, um die Korrektur zu bestätigen.

Schwacher Algorithmus (DNSSEC_WEAK_ALGO)

Symptom: Ihre Zone verwendet einen Signaturalgorithmus, der laut RFC 8624 als unsicher gilt.

Betroffene Algorithmen: RSAMD5 (1), DSA (3) und DSA-NSEC3-SHA1 (6) sind für die Signatur verboten. RSASHA1 (5) und RSASHA1-NSEC3-SHA1 (7) werden nicht empfohlen.

Maßnahme: Migrieren Sie zu einem empfohlenen Algorithmus: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) oder Ed25519 (15). Starten Sie den Test erneut, um die Korrektur zu bestätigen.

SHA-1-Digest (DNSSEC_WEAK_DIGEST)

Symptom: Ihr DS verwendet SHA-1 (Typ 1) als Digest-Typ.

Maßnahme: Fügen Sie parallel einen DS mit SHA-256 (Typ 2) hinzu, oder SHA-384 (Typ 4), falls Ihr Registrar dies unterstützt. Warten Sie 48 Stunden auf die Propagation, dann entfernen Sie den SHA-1-DS. Starten Sie den Test erneut, um die Korrektur zu bestätigen.

SERVFAIL nach DNSSEC-Aktivierung

Symptom: Ihre Domain liefert nach der DNSSEC-Aktivierung SERVFAIL für validierende Resolver.

Häufige Ursachen:

• DS beim Registrar passt nicht zur DNSKEY Ihrer Zone
• RRSIG-Signaturen nicht erzeugt oder abgelaufen
• Autoritative Server liefern keine DNSKEY-Einträge

Maßnahme: Starten Sie den Test im Modus Vollständig, um das gebrochene Glied zu identifizieren. Prüfen Sie, ob der DS zur DNSKEY KSK passt. Starten Sie den Test erneut, um die Korrektur zu bestätigen.

DNSKEY-Inkonsistenz zwischen Servern (DNSSEC_SERVER_INCONSISTENT)

Symptom: Die autoritativen Server Ihrer Zone liefern nicht dieselben DNSKEY. Wird nur im Modus Vollständig erkannt.

Wahrscheinliche Ursache: Unvollständige Propagation zwischen primärem und sekundären Servern oder unterschiedliche Konfiguration auf einem Server.

Maßnahme: Prüfen Sie die Replikation zwischen den Servern. Erzwingen Sie bei Bedarf einen Zonentransfer (AXFR/IXFR). Starten Sie den Test erneut, um die Korrektur zu bestätigen.

DNSSEC in der Kommandozeile prüfen (delv und dig)

Für Systemadministratoren stehen zwei Werkzeuge zur manuellen DNSSEC-Prüfung bereit. delv (mit BIND 9.10 und neuer ausgeliefert) führt eine vollständige Validierung der Vertrauenskette durch und zeigt ein abschließendes Ergebnis an. dig fragt die rohen Einträge (DS, DNSKEY, RRSIG) ab, validiert die Kette selbst aber nicht.

Hinweis: Die alten Optionen dig +sigchase und +trusted-key wurden aus den modernen BIND-Versionen entfernt. Verwenden Sie stattdessen delv für die Validierung.

# Vollständige Vertrauenskette validieren (abschließendes Ergebnis)
delv captaindns.com A

# Jeden Schritt der Validierung nachverfolgen
delv @1.1.1.1 captaindns.com A +rtrace

# DNSKEY der Zone validieren und anzeigen
delv captaindns.com DNSKEY

# Beim Parent veröffentlichte DS-Einträge anzeigen
dig DS captaindns.com +short

# DNSKEY und ihre RRSIG-Signaturen anzeigen (ohne Validierung)
dig DNSKEY captaindns.com +dnssec

# RRSIG auf einem A-Eintrag anzeigen
dig A captaindns.com +dnssec

Eine validierte delv-Antwort zeigt ; fully validated; ein Validierungsfehler zeigt ; resolution failed. Diese Befehle erfordern Terminal-Zugang und DNS-Expertise. Der DNSSEC Checker oben automatisiert den gesamten Prozess und stellt die Ergebnisse visuell dar, ohne Kommandozeile.

DNSSEC nach DNS-Hoster

Die DNSSEC-Aktivierung hängt von Ihrem DNS-Hoster und Ihrem Registrar ab. Hier die wichtigsten Anbieter und ihr Support-Niveau:

Prüfen Sie nach der Aktivierung immer die Vertrauenskette mit dem DNSSEC Checker. Der häufigste Fehler: ein DS beim Registrar, der nicht zur vom Hoster generierten DNSKEY passt.

DNSSEC Best Practices

Signaturalgorithmus: Bevorzugen Sie einen Algorithmus mit elliptischen Kurven, ECDSAP256SHA256 (13) oder Ed25519 (15). RSASHA256 (8) und ECDSAP384SHA384 (14) sind weiterhin weit verbreitet und akzeptiert. ECDSA erzeugt Signaturen, die etwa 3,5 bis 4 mal kompakter sind als RSA-2048, was die Größe der Antworten reduziert.

DS-Digest: Veröffentlichen Sie einen DS mit SHA-256 (Typ 2); SHA-384 (Typ 4) wird ebenfalls akzeptiert. SHA-1 (Typ 1) ist veraltet: Veröffentlichen Sie keinen DS mehr mit SHA-1 allein.

Schlüsselrotation: Folgen Sie den Praktiken der RFC 6781 und 7583 (siehe den eigenen Abschnitt weiter unten). Entfernen Sie den alten DS niemals, bevor der neue propagiert ist.

Monitoring: Prüfen Sie die Kette nach jeder DNS-Änderung. Eine nicht rechtzeitig neu signierte Zone verursacht SERVFAIL.

Provider-Migration: Stellen Sie sicher, dass der neue Provider denselben Algorithmus unterstützt. Beide Schlüsselsätze müssen während der Propagation koexistieren.

Rotation der Signaturschlüssel (Rollover)

Ein DNSSEC-Schlüssel hält nicht ewig. Sie müssen ihn regelmäßig ersetzen (Rollover), ohne die Vertrauenskette zu brechen. Die RFC 6781 (operative Praktiken) und 7583 (Zeitplanung) beschreiben diese Verfahren. Die Vorgehensweise unterscheidet sich je nach Schlüsseltyp.

Rollover der KSK (Key Signing Key). Die KSK wird vom DS beim Parent referenziert. Die gängige Methode ist das Double-DS-Verfahren: Veröffentlichen Sie den DS der neuen KSK beim Parent, warten Sie, bis alle Caches beide DS übernommen haben, schalten Sie die Signatur des DNSKEY RRSet auf die neue KSK um und entfernen Sie dann den alten DS. Die Dauer hängt vom TTL des DS beim Parent ab.

Rollover der ZSK (Zone Signing Key). Die ZSK signiert die Daten und ist nicht an den Parent gebunden. Zwei Methoden:

• Pre-publish: Veröffentlichen Sie die neue ZSK im DNSKEY RRSet, bevor Sie sie verwenden, warten Sie auf die Propagation, signieren Sie die Daten mit dem neuen Schlüssel und entfernen Sie dann den alten. Das ist die empfohlene Methode für die ZSK.
• Double-Signature: Signieren Sie die Daten gleichzeitig mit der alten und der neuen ZSK. Einfacher nachzuvollziehen, verdoppelt aber die Anzahl der Signaturen und vergrößert die Antworten.

Risiken eines fehlgeschlagenen Rollovers. Einen Schlüssel oder einen DS zu entfernen, bevor die darauf verweisenden Caches abgelaufen sind, bricht die Kette: Validierende Resolver liefern SERVFAIL. Entfernen Sie den alten Schlüssel oder den alten DS niemals, bevor alle betroffenen TTL abgelaufen sind. Prüfen Sie nach jedem KSK-Rollover, dass kein verwaister DS zurückbleibt.

CDS und CDNSKEY: den DS beim Parent automatisieren

Die Schwachstelle eines KSK-Rollovers ist die manuelle Aktualisierung des DS beim Registrar. Ein fehlerhaftes Kopieren bricht die Kette. Die Einträge CDS und CDNSKEY (RFC 7344 und 8078) automatisieren diesen Schritt.

Die Child-Zone veröffentlicht einen CDS (Child DS) oder einen CDNSKEY (Child DNSKEY), der dem Parent den zu veröffentlichenden DS mitteilt. Der Registrar oder das Registry scannt diese Einträge regelmäßig und aktualisiert den DS automatisch, ohne manuellen Eingriff. Zwei Anwendungsfälle:

• Bootstrapping (RFC 8078): die erste DNSSEC-Aktivierung, wenn beim Parent noch kein DS existiert.
• Wartung: die Aktualisierung des DS bei den folgenden KSK-Rollovern.

Noch nicht alle Registries unterstützen CDS/CDNSKEY, aber die Verbreitung nimmt zu. Wo sie unterstützt werden, beseitigen sie die häufigste Fehlerquelle bei KSK-Rollovern. Prüfen Sie anschließend die Kette mit dem DNSSEC Checker, um zu bestätigen, dass der veröffentlichte DS tatsächlich zu Ihrer KSK passt.

Konkrete Anwendungsfälle

DNSSEC-Aktivierung bei einem neuen Registrar

Sie haben DNSSEC gerade aktiviert? Starten Sie eine Prüfung im Modus Einfach. Bestätigen Sie, dass der DS beim Parent zur DNSKEY Ihrer Zone passt. Die Kette muss von Ende zu Ende vollständig sein.

Schlüsselrotation (key rollover)

Sie führen einen key rollover durch? Prüfen Sie im Modus Einfach auf verwaiste DS. Ein nicht entfernter alter DS bricht die Auflösung nicht. Er verkompliziert jedoch die künftigen Rollover.

DNS-Provider-Migration

Sie migrieren zu Cloudflare? Route 53? Starten Sie den Test im Modus Vollständig. Prüfen Sie, dass die DS auf die neuen DNSKEY zeigen. Bestätigen Sie die Gültigkeit der Signaturen auf allen autoritativen Servern.

Sicherheitsaudit

Der Modus Vollständig deckt die drei Säulen eines DNSSEC-Audits ab. DNSKEY-Konsistenz zwischen den Servern. Gültige Signaturen auf SOA, NS, A und MX. Warnung bei RRSIG kurz vor dem Ablauf.

Domain liefert SERVFAIL

Ihre Website ist aus bestimmten Netzwerken nicht erreichbar? Diese Netzwerke nutzen wahrscheinlich validierende Resolver. Starten Sie den Test sofort, um festzustellen, ob DNSSEC die Ursache ist.

❓ FAQ - Häufig gestellte Fragen

F: Was ist DNSSEC und warum sollten Sie es aktivieren?

A: DNSSEC fügt den DNS-Antworten kryptografische Signaturen hinzu. Ohne DNSSEC kann ein Angreifer Antworten fälschen und den Datenverkehr umleiten. Die Aktivierung von DNSSEC stellt sicher, dass Besucher Ihre Server erreichen und nicht die eines Angreifers.

F: Wie prüfen Sie, ob DNSSEC für Ihre Domain aktiviert ist?

A: Geben Sie Ihre Domain in das obige Tool ein. Wenn es "DNSSEC ist nicht aktiviert" anzeigt, ist kein DS beim Parent veröffentlicht. Kontaktieren Sie Ihren Registrar, um DNSSEC zu aktivieren.

F: Was ist ein verwaister DS?

A: Ein DS beim Parent ohne passende DNSKEY in der Child-Zone. Das passiert bei einem unvollständigen key rollover. Nicht blockierend, solange ein anderer gültiger DS existiert, aber ein Zeichen für eine unvollständige Konfiguration.

F: Warum liefert Ihre Domain nach der DNSSEC-Aktivierung SERVFAIL?

A: Die Vertrauenskette ist gebrochen. Häufige Ursachen: DS passt nicht zur DNSKEY, RRSIG fehlen oder sind abgelaufen, DNSKEY werden nicht ausgeliefert. Starten Sie den Modus Vollständig, um das fehlerhafte Glied zu identifizieren.

F: Was ist der Unterschied zwischen den Modi Einfach und Vollständig?

A: Einfach prüft die Kette DS/DNSKEY/RRSIG auf einem Server pro Zone. Vollständig ergänzt die Multi-Server-DNSKEY-Konsistenz und validiert die RRSIG auf SOA, NS, A und MX.

F: Welche DNSSEC-Algorithmen werden empfohlen?

A: Die gängigen und empfohlenen Algorithmen sind RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) und Ed25519 (15). Gemäß RFC 8624 sind RSAMD5 (1), DSA (3) und DSA-NSEC3-SHA1 (6) verboten; RSASHA1 (5) und RSASHA1-NSEC3-SHA1 (7) werden nicht empfohlen.

F: NSEC oder NSEC3: Was ist Zone Walking?

A: NSEC und NSEC3 weisen authentifiziert nach, dass ein Name nicht existiert. NSEC listet die Namen im Klartext auf, wodurch sich die gesamte Zone aufzählen lässt (Zone Walking). NSEC3 (RFC 5155) veröffentlicht Hashes anstelle der Klartextnamen, um diese Aufzählung zu verhindern.

F: Wozu dienen die CDS- und CDNSKEY-Einträge?

A: CDS und CDNSKEY (RFC 7344 und 8078) ermöglichen es der Child-Zone, dem Parent den zu veröffentlichenden DS mitzuteilen. Der Registrar oder das Registry scannt diese Einträge, um den DS automatisch zu erstellen und zu pflegen, ohne manuelles Kopieren bei jedem KSK-Rollover.

F: Verlangsamt DNSSEC die DNS-Auflösung?

A: Der Einfluss bleibt gering, aber signierte Antworten sind größer. Sie können die Größe eines UDP-Pakets überschreiten und eine Fragmentierung oder einen Rückfall auf TCP auslösen. Resolver cachen die validierten Ergebnisse, was die Kosten nach der ersten Anfrage abfedert.

Ergänzende Tools

Nützliche Ressourcen

• RFC 4033 - DNS Security Introduction: Einführung und Anforderungen der DNSSEC-Erweiterungen
• RFC 4034 - Resource Records for DNSSEC: Spezifikation der Einträge DS, DNSKEY, RRSIG, NSEC
• RFC 4035 - Protocol Modifications for DNSSEC: Verhalten der validierenden Resolver und Server
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence: Spezifikation von NSEC3
• RFC 6781 - DNSSEC Operational Practices: Operative Best Practices und Rollover
• RFC 7583 - DNSSEC Key Rollover Timing: Zeitplan für die Schlüsselrotation
• RFC 8624 - Algorithm Implementation Requirements: Anforderungen an DNSSEC-Algorithmen
• Verisign DNSSEC Debugger: Referenz-Tool für DNSSEC-Debugging
• DNSViz: Erweiterte Visualisierung der DNSSEC-Kette