Warum DNSSEC prüfen?
DNSSEC (DNS Security Extensions) fügt DNS-Antworten kryptografische Signaturen hinzu. Ohne diese Signaturen kann ein Angreifer Antworten fälschen und deinen Traffic kapern. Das nennt sich DNS Cache Poisoning. Für den Endnutzer ist dieser Angriff unsichtbar.
Ein einziger falsch konfigurierter DS-Eintrag reicht aus, um die gesamte Kette zu brechen. Validierende Resolver liefern dann SERVFAIL. Deine Website sieht aus deinem Netzwerk normal aus, aber Millionen Nutzer sehen nichts. Kein Uptime-Monitor, kein HTTP-Check, kein Ping erkennt dieses Problem. Nur ein DNSSEC-spezifischer Test deckt es auf.
Ein verwaister DS nach einem fehlgeschlagenen key rollover. Eine Signatur, die über Nacht abgelaufen ist. Diese stillen Ausfälle dauern tagelang an, bis jemand einen Check durchführt.
Vier Gründe, dein DNSSEC jetzt zu prüfen:
- Sicherheit: Nur eine intakte Vertrauenskette garantiert, dass Besucher deine Server erreichen, nicht die Kopie eines Angreifers
- Verfügbarkeit: Eine gebrochene Kette blockiert über 30 % aller DNS-Anfragen weltweit. Google, Cloudflare und Quad9 lehnen die Antwort ab.
- Compliance: Banken, Behörden und Gesundheitsorganisationen fordern DNSSEC zunehmend für alle Domains
- Früherkennung: Verwaiste DS, veraltete Algorithmen und ablaufende RRSIG-Signaturen erkennen, bevor sie einen Ausfall auslösen
So verwendest du den DNSSEC Checker in 3 Schritten
Schritt 1: Domain eingeben
Gib 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, erfährst du das sofort.
Schritt 2: Analysemodus wählen
- Modus Einfach (Standard): Prüft die vollständige Vertrauenskette mit Abfrage eines autoritativen Servers pro Zone. Ergebnis in 1 bis 3 Sekunden.
- Modus Vollständig: Prüft zusätzlich die DNSKEY-Konsistenz über alle autoritativen Server und validiert die RRSIG-Signaturen auf den Dateneinträgen (SOA, NS, A, MX). Ergebnis in 5 bis 10 Sekunden.
Der Modus Vollständig wird nach einem key rollover, einer DNS-Provider-Migration oder für ein umfassendes Sicherheitsaudit empfohlen. Im Zweifel: starte mit dem Modus Einfach.
Schritt 3: Bericht analysieren und korrigieren
Der Bericht klassifiziert jeden Fund nach Schweregrad, Zone für Zone:
- Fehler: Gebrochene Kette, ungültige Signaturen, Inkonsistenz zwischen Servern. Diese blockieren die Auflösung.
- Warnungen: Verwaiste DS, schwache Algorithmen, bald ablaufende RRSIG. Hier besteht Handlungsbedarf.
- Informationen: CSK erkannt, NS außerhalb des Bailiwicks, Anzahl der DS beim Parent. Gut zu wissen, kein Handlungsbedarf.
Was ist die DNSSEC-Vertrauenskette?
Die DNSSEC-Vertrauenskette (chain of trust) funktioniert wie ein Staffellauf kryptographischer Übergaben. Jede Zone bürgt für die nächste. Er beginnt an der DNS-Root und endet bei deiner Domain:
Root (.)
|-- DS des TLD --> verifiziert die DNSKEY des TLD (KSK)
|-- Die ZSK des TLD signiert den DS deiner Domain
|-- DS deiner Domain --> verifiziert deine DNSKEY (KSK)
|-- Deine KSK signiert das DNSKEY RRSet
|-- Deine ZSK signiert die Daten (A, MX, SOA, NS)
Die wichtigsten Einträge:
| Eintrag | Rolle | Wo veröffentlicht |
|---|---|---|
| DS (Delegation Signer) | Hash einer Child-DNSKEY, stellt die Verbindung zwischen Zonen her | Parent-Zone |
| DNSKEY | Öffentlicher Schlüssel der Zone (KSK = Flags 257, ZSK = Flags 256) | Child-Zone |
| RRSIG | Kryptografische Signatur eines Eintrags-Sets | Child-Zone |
| NSEC/NSEC3 | Authentifizierter Nachweis der Nichtexistenz eines Eintrags | Child-Zone |
Jedes Glied hängt vom vorherigen ab. Ein einziges gebrochenes Glied, und die gesamte Kette bricht zusammen. Resolver liefern SERVFAIL für die gesamte Domain, nicht nur für die fehlerhafte Zone.
Was prüft das Tool genau?
Modus Einfach
| Element | Beschreibung | Ergebnis |
|---|---|---|
| DS Records | Beim Parent veröffentlichte DS-Einträge | Match mit DNSKEY, verwaiste DS, schwacher Digest |
| DNSKEY Records | Öffentliche Schlüssel der Zone (KSK/ZSK) | Vorhandensein, Algorithmus, DS-Zuordnung |
| RRSIG auf DS | Signatur des DS RRSet durch die ZSK des Parent | Kryptografische Gültigkeit + Zeitfenster |
| RRSIG auf DNSKEY | Signatur des DNSKEY RRSet durch die KSK | Kryptografische Gültigkeit + Zeitfenster |
| Algorithmen | Typ des Signaturalgorithmus | Erkennung veralteter Algorithmen (RFC 8624) |
| DS-Digests | Hash-Typ des DS | Erkennung des veralteten SHA-1 |
Modus Vollständig (zusätzlich)
| Element | Beschreibung | Ergebnis |
|---|---|---|
| DNSKEY-Konsistenz | Vergleich der DNSKEY auf allen autoritativen Servern | Erkennung von Inkonsistenzen zwischen Servern |
| RRSIG auf SOA | Signatur des SOA-Eintrags | Gültigkeit + Zeit bis Ablauf |
| RRSIG auf NS | Signatur der NS-Einträge | Gültigkeit + Zeit bis Ablauf |
| RRSIG auf A/MX | Signaturen der A- und MX-Einträge | Gültigkeit + Zeit bis Ablauf |
| RRSIG-Ablauf | Zeit bis zum Ablauf jeder Signatur | Warnung bei Ablauf in weniger als 7 Tagen |
Häufige Diagnosen und Lösungen
Verwaister DS (DNSSEC_DS_ORPHAN)
Symptom: Ein DS-Eintrag ist beim Parent veröffentlicht, aber keine entsprechende DNSKEY existiert in deiner Zone.
Wahrscheinliche Ursache: Unvollständiger key rollover oder alter Schlüssel aus der Zone entfernt, bevor der DS beim Registrar aktualisiert wurde.
Maßnahme: Entferne den verwaisten DS über deinen Registrar. Oder füge die passende DNSKEY in deiner Zone hinzu. Prüfe danach erneut mit dem Tool.
Schwacher Algorithmus (DNSSEC_WEAK_ALGO)
Symptom: Deine Zone verwendet einen Signaturalgorithmus, der laut RFC 8624 als unsicher gilt.
Betroffene Algorithmen: RSAMD5 (1), DSA (3), DSA-NSEC3-SHA1 (6) sind verboten. RSASHA1-NSEC3-SHA1 (7) wird nicht empfohlen.
Maßnahme: Migriere zu ECDSAP256SHA256 (13) oder ED25519 (15). Beide sind sicherer und erzeugen 4x kleinere Signaturen als RSA-2048.
SHA-1-Digest (DNSSEC_WEAK_DIGEST)
Symptom: Dein DS verwendet SHA-1 (Typ 1) als Digest-Typ.
Maßnahme: Füge einen DS mit SHA-256 (Typ 2) parallel hinzu. Warte 48 Stunden auf die Propagation. Erst dann den SHA-1-DS entfernen. Vorher entfernen bricht die Kette.
SERVFAIL nach DNSSEC-Aktivierung
Symptom: Deine Domain liefert SERVFAIL für validierende Resolver nach der DNSSEC-Aktivierung.
Häufige Ursachen:
- DS beim Registrar passt nicht zur DNSKEY deiner Zone
- RRSIG-Signaturen nicht erzeugt oder abgelaufen
- Autoritative Server liefern keine DNSKEY-Einträge
Maßnahme: Starte den Test im Modus Vollständig. Das Tool zeigt das genaue fehlerhafte Glied. Prüfe zuerst: DS beim Registrar muss zur KSK passen (gleicher Key-Tag, gleicher Algorithmus).
DNSKEY-Inkonsistenz zwischen Servern (DNSSEC_SERVER_INCONSISTENT)
Symptom: Die autoritativen Server deiner Zone liefern unterschiedliche DNSKEY-Einträge. 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üfe die Replikation zwischen deinen DNS-Servern. Erzwinge bei Bedarf einen Zonentransfer (AXFR/IXFR). Warte einige Minuten, dann erneut testen.
DNSSEC mit dig prüfen (Kommandozeile)
Für Systemadministratoren bietet der Befehl dig die Möglichkeit, DNSSEC manuell zu prüfen:
# DS-Einträge beim Parent prüfen
dig DS captaindns.com +short
# DNSKEY der Zone prüfen
dig DNSKEY captaindns.com +dnssec +short
# RRSIG auf einem Eintrag prüfen
dig A captaindns.com +dnssec
# Vollständige Kette mit Validierung prüfen
dig captaindns.com +sigchase +trusted-key=./root.keys
Diese Befehle erfordern DNS-Expertise und Terminal-Zugang. Der DNSSEC Checker oben erledigt die gleiche Arbeit automatisch, mit visuellen Ergebnissen und ohne Kommandozeile.
DNSSEC nach DNS-Hoster
Die DNSSEC-Aktivierung hängt von deinem DNS-Hoster und Registrar ab. Hier die wichtigsten Anbieter im Überblick:
| Hoster | DNSSEC | Aktivierung | Standard-Algorithmus |
|---|---|---|---|
| Cloudflare | Automatisch | Ein Klick im Dashboard, dann DS beim Registrar hinzufügen | ECDSAP256SHA256 (13) |
| OVH | Unterstützt | Aktivierung über den Kundenbereich oder die API | Variiert je nach Konfiguration |
| AWS Route 53 | Unterstützt | Über die AWS-Konsole, KSK erstellen, dann DS beim Registrar | ECDSAP256SHA256 (13) |
| Gandi | Automatisch | Standardmäßig aktiviert, wenn Gandi Registrar + DNS-Hoster ist | ECDSAP256SHA256 (13) |
| Infomaniak | Unterstützt | Aktivierung über den Manager | ECDSAP256SHA256 (13) |
Prüfe nach der Aktivierung immer die Vertrauenskette mit dem obigen Tool. Der häufigste Fehler Nr. 1: Der DS beim Registrar passt nicht zur DNSKEY, die der Hoster generiert hat.
DNSSEC Best Practices
Signaturalgorithmus: Verwende ECDSAP256SHA256 (13) oder ED25519 (15). ECDSA erzeugt 4x kompaktere Signaturen als RSA-2048. Vermeide RSA, außer bei Kompatibilitätszwang.
DS-Digest: Veröffentliche einen DS mit SHA-256 (Typ 2). Ergänze SHA-384 (Typ 4) falls unterstützt. Niemals SHA-1 allein veröffentlichen.
Schlüsselrotation (key rollover): Folge dem Prozess nach RFC 7583. Entferne den alten DS niemals, bevor der neue propagiert ist. Starte nach jeder Rotation den DNSSEC Checker, um verwaiste DS auszuschließen.
Monitoring: Prüfe die Vertrauenskette nach jeder DNS-Änderung. RRSIG-Signaturen haben eine begrenzte Lebensdauer. Wird deine Zone nicht rechtzeitig neu signiert, liefern Resolver SERVFAIL ohne Vorwarnung.
Provider-Migration: Stelle vor dem Wechsel sicher, dass der neue Anbieter DNSSEC mit dem gleichen Algorithmus unterstützt. Beide Schlüsselsätze müssen während der Migration koexistieren.
Konkrete Anwendungsfälle
DNSSEC-Aktivierung bei einem neuen Registrar
Du hast DNSSEC gerade aktiviert? Starte sofort eine Prüfung im Modus Einfach. Prüfe, ob der DS beim Parent zur DNSKEY deiner Zone passt. Ein Mismatch bedeutet SERVFAIL für jeden validierenden Resolver.
Schlüsselrotation (key rollover)
Du hast gerade einen key rollover durchgeführt? Prüfe im Modus Einfach auf verwaiste DS. Ein alter DS blockiert die Auflösung nicht sofort. Aber er signalisiert unvollständige Wartung und verkompliziert den nächsten Rollover.
DNS-Provider-Migration
Du migrierst zu Cloudflare, Route 53 oder einem anderen Hoster? Nutze den Modus Vollständig. Prüfe drei Dinge: DS-Einträge zeigen auf die neuen DNSKEY, Signaturen sind auf allen Servern gültig, Schlüssel sind konsistent repliziert.
Sicherheitsaudit
Der Modus Vollständig ist dein DNSSEC-Compliance-Bericht. DNSKEY-Konsistenz über alle autoritativen Server, RRSIG-Gültigkeit auf SOA, NS, A und MX, plus verbleibende Tage bis zum Ablauf jeder Signatur.
Domain liefert SERVFAIL
Nutzer melden, deine Website ist aus bestimmten Netzwerken nicht erreichbar? Diese Netzwerke nutzen vermutlich validierende Resolver. Starte den Test sofort. Ist die Kette gebrochen, zeigt das Tool dir genau die Bruchstelle.
FAQ: Häufig gestellte Fragen
F: Was ist DNSSEC und warum aktivieren?
A: DNSSEC fügt DNS-Antworten kryptografische Signaturen hinzu. Ohne DNSSEC können Angreifer Antworten fälschen und deinen Traffic umleiten (Cache Poisoning). Mit DNSSEC können Resolver die Echtheit der Antworten verifizieren.
F: Wie prüfe ich, ob DNSSEC für meine Domain aktiviert ist?
A: Gib deine Domain in das obige Tool ein. Zeigt es "DNSSEC ist nicht aktiviert" an, existiert kein DS-Eintrag beim Parent-Registry. Kontaktiere deinen Registrar, um es zu aktivieren.
F: Was ist ein verwaister DS?
A: Ein DS-Eintrag beim Parent ohne passende DNSKEY in der Child-Zone. Entsteht typisch bei einem unvollständigen key rollover. Nicht blockierend, wenn ein anderer gültiger DS existiert, aber ein Zeichen für eine Konfigurationslücke.
F: Warum liefert meine Domain nach der DNSSEC-Aktivierung SERVFAIL?
A: Die Vertrauenskette ist gebrochen. Drei häufige Ursachen: DS/DNSKEY-Mismatch beim Registrar, fehlende oder abgelaufene RRSIG-Signaturen, oder Server liefern keine DNSKEY. Starte den Modus Vollständig, um die genaue Bruchstelle zu finden.
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 (1-3 Sekunden). Vollständig ergänzt Multi-Server-DNSKEY-Konsistenz und RRSIG-Validierung auf SOA, NS, A, MX (5-10 Sekunden).
F: Welche DNSSEC-Algorithmen werden empfohlen?
A: ECDSAP256SHA256 (13) und ED25519 (15). Vermeide RSAMD5, DSA und RSASHA1-NSEC3-SHA1. RFC 8624 stuft sie als schwach oder verboten ein.
F: Verlangsamt DNSSEC die DNS-Auflösung?
A: Vernachlässigbar bei modernen Resolvern. Antworten sind etwas größer durch Signaturen, aber Resolver cachen validierte Ergebnisse genauso wie unsignierte.
Ergänzende Tools
| Tool | Nutzen |
|---|---|
| DNS Domain Check | Vollständiges Audit der DNS-Konfiguration inkl. grundlegender DNSSEC-Prüfung |
| DNS Lookup | DS-, DNSKEY- oder RRSIG-Einträge manuell abfragen |
| DNS Propagation Test | Propagation von DNSSEC-Änderungen weltweit prüfen |
| RDAP Lookup | DNSSEC-Status der Domain beim Registrar prüfen |
Nützliche Ressourcen
- RFC 4033 - DNS Security Introduction: Einführung in die DNSSEC-Erweiterungen
- RFC 4034 - Resource Records for DNSSEC: Spezifikation der Einträge DS, DNSKEY, RRSIG, NSEC
- RFC 8624 - Algorithm Implementation Requirements: Anforderungen an DNSSEC-Algorithmen
- RFC 7583 - DNSSEC Key Rollover Timing: Leitfaden für die Schlüsselrotation
- Verisign DNSSEC Debugger: Referenz-Tool für DNSSEC-Debugging
- DNSViz: Erweiterte Visualisierung der DNSSEC-Kette