Die DNSSEC-Vertrauenskette in 5 Minuten verstehen

⚡TL;DR

• Die DNSSEC-Vertrauenskette verbindet den DNS-Root mit deiner Domain über verschachtelte kryptografische Signaturen
• Drei Eintragstypen sichern die Validierung: DNSKEY (öffentliche Schlüssel), RRSIG (Signaturen) und DS (Verknüpfung zur übergeordneten Zone)
• Jedes Glied verifiziert das nächste: der Root signiert das TLD, das TLD signiert deine Domain
• Prüfe, ob deine Kette intakt ist, mit unserem DNSSEC Checker (siehe Aktionsplan am Ende)

DNSSEC funktioniert nicht wie ein TLS-Zertifikat, das du auf einem Server installierst. Es ist ein verteiltes System. Das Vertrauen wird vom DNS-Root bis zu deiner Domain weitergegeben, Glied für Glied. Wenn ein einziges Glied bricht, bricht die gesamte Kette zusammen und deine Besucher erhalten einen SERVFAIL-Fehler.

Das Verständnis dieser Kette ist essenziell, um DNSSEC korrekt zu aktivieren, Fehler zu diagnostizieren und Dienstunterbrechungen zu vermeiden. Dieser Leitfaden erklärt dir jede Komponente in 5 Minuten, mit Schaubildern und konkreten Beispielen.

Warum braucht das DNS eine Vertrauenskette?

Das DNS wurde 1983 (RFC 1034) als verteiltes Verzeichnis entworfen. Es gab keinen Mechanismus, um zu überprüfen, ob eine Antwort tatsächlich vom legitimen Server stammte. Ein Angreifer konnte eine gefälschte Antwort einschleusen (DNS-Spoofing) und den Datenverkehr auf einen bösartigen Server umleiten.

DNSSEC (RFC 4033) löst dieses Problem durch kryptografische Signaturen. Aber eine Signatur allein reicht nicht aus: Es braucht eine Möglichkeit zu überprüfen, ob der Signaturschlüssel legitim ist. Das ist die Aufgabe der Vertrauenskette.

Das Prinzip ist einfach: Jede Ebene der DNS-Hierarchie garantiert die Authentizität der nächsten Ebene.

Die drei Ebenen der DNS-Hierarchie

Die DNS-Auflösung folgt einer Baumstruktur mit drei Ebenen. DNSSEC nutzt diese Hierarchie, um die Vertrauenskette aufzubauen.

Ebene 1: der DNS-Root

Der DNS-Root ist der Ausgangspunkt jeder Auflösung. Er wird von der IANA (Internet Assigned Numbers Authority) verwaltet und über 13 Root-Server-Cluster verteilt. Der Root signiert die DS-Einträge jedes TLD.

Der Vertrauensanker (Trust Anchor) des Root ist der Root-KSK. Er ist in allen validierenden Resolvern integriert (1.1.1.1, 8.8.8.8, 9.9.9.9). Er ist das Fundament der gesamten Kette.

Ebene 2: das TLD (.com, .fr, .org)

Das TLD erhält seine Legitimität vom Root über einen DS-Eintrag. Die Registrierungsstelle des TLD (Verisign für .com, AFNIC für .fr) verwaltet die Signatur seiner Zone. Das TLD signiert wiederum die DS-Einträge jeder registrierten Domain.

Ebene 3: deine Domain (captaindns.com)

Deine Domain ist das letzte Glied. Dein DNS-Anbieter signiert die Einträge deiner Zone (A, MX, TXT usw.) und veröffentlicht die öffentlichen Schlüssel. Der DS-Eintrag im TLD verknüpft deine Zone mit der übergeordneten Zone.

Die kryptografischen Schlüssel: ZSK und KSK

Jede DNSSEC-Zone verwendet zwei Schlüsselpaare. Ihre Trennung ermöglicht eine unabhängige Rotation und begrenzt die Auswirkungen einer Kompromittierung.

ZSK (Zone Signing Key)

Die ZSK signiert die DNS-Einträge deiner Zone. Jeder Eintragstyp (A, MX, TXT, AAAA) erhält eine eigene RRSIG-Signatur.

• Typische Größe: 1024-2048 Bit (RSA) oder 256 Bit (ECDSA P-256)
• Rotation: alle 1 bis 3 Monate
• Veröffentlicht in: dem DNSKEY-Eintrag deiner Zone (Flag 256)

Die häufige Rotation der ZSK begrenzt die Risiken. Wenn der Schlüssel kompromittiert wird, ist die Exposition zeitlich begrenzt. Die ZSK-Rotation erfordert keine Aktualisierung des DS-Eintrags beim TLD.

KSK (Key Signing Key)

Die KSK signiert ausschließlich den DNSKEY-Satz (einschließlich der ZSK). Ihr Hash wird im DS-Eintrag auf TLD-Ebene veröffentlicht. Sie ist die Brücke zwischen deiner Zone und der übergeordneten Zone.

• Typische Größe: 2048-4096 Bit (RSA) oder 384 Bit (ECDSA P-384)
• Rotation: alle 1 bis 2 Jahre
• Veröffentlicht in: dem DNSKEY-Eintrag deiner Zone (Flag 257)

Die Rotation der KSK ist heikler: Sie erfordert eine Aktualisierung des DS-Eintrags beim Registrar. Eine schlechte Koordination unterbricht die Vertrauenskette.

Die DNSSEC-Einträge erklärt

Vier DNS-Eintragstypen sichern die Funktion der Kette.

DNSKEY: die öffentlichen Schlüssel

Der DNSKEY-Eintrag enthält den öffentlichen Schlüssel zur Verifizierung der Signaturen. Deine Zone veröffentlicht mindestens zwei DNSKEY: einen für die ZSK (Flag 256) und einen für die KSK (Flag 257).

dig DNSKEY captaindns.com +short

Der Resolver verwendet diese Schlüssel, um die RRSIG-Signaturen der Einträge in deiner Zone zu verifizieren.

RRSIG: die Signaturen

Jeder signierte DNS-Eintrag hat einen zugehörigen RRSIG. Der RRSIG enthält die kryptografische Signatur, den verwendeten Algorithmus, den Gültigkeitszeitraum und den Key Tag des signierenden Schlüssels.

dig A captaindns.com +dnssec

Der Resolver prüft, ob die RRSIG-Signatur zum zurückgegebenen Eintrag passt und ob der Schlüssel (DNSKEY) gültig ist.

DS: die Verknüpfung mit der übergeordneten Zone

Der DS-Eintrag (Delegation Signer) wird in der übergeordneten Zone (dem TLD) veröffentlicht. Er enthält einen Hash der KSK deiner Zone. Der Resolver vergleicht diesen Hash mit der KSK, die in deinem DNSKEY veröffentlicht ist, um die Legitimität deiner Schlüssel zu bestätigen.

dig DS captaindns.com +short

Der DS-Eintrag ist das kritische Glied zwischen zwei Ebenen der Hierarchie. Ohne DS-Eintrag ist die Kette unterbrochen und DNSSEC erscheint als INSECURE.

NSEC/NSEC3: der Nachweis der Nichtexistenz

NSEC und NSEC3 beweisen authentifiziert, dass ein angefragter Eintrag nicht existiert. Ohne diese Einträge könnte ein Angreifer gefälschte Antworten mit "Domain existiert nicht" (NXDOMAIN) erzeugen, um den Datenverkehr umzuleiten.

NSEC3 (RFC 5155) fügt ein Hashing der Namen hinzu, um Zone Walking (Zonenauflistung) zu verhindern.

Wie validiert der Resolver eine Antwort?

Hier ist der vollständige Validierungsprozess, wenn ein Resolver eine Anfrage für captaindns.com erhält.

Schritt 1: Vertrauensanker abrufen

Der Resolver besitzt bereits den KSK des DNS-Root (Trust Anchor). Dieser Schlüssel ist in seiner Konfiguration integriert. Das ist das einzige Element, das der Resolver ohne Verifizierung akzeptiert.

Schritt 2: Root zum TLD validieren

1. Der Resolver fragt den DS-Eintrag von .com beim Root an
2. Der Root liefert den DS-Eintrag und seine RRSIG-Signatur
3. Der Resolver verifiziert die Signatur mit dem Root-KSK
4. Der DS-Eintrag von .com ist nun validiert

Schritt 3: TLD zu deiner Domain validieren

1. Der Resolver fragt den DS-Eintrag von captaindns.com beim TLD .com an
2. Das TLD liefert den DS-Eintrag und seine RRSIG-Signatur
3. Der Resolver verifiziert die Signatur mit dem DNSKEY des TLD (validiert in Schritt 2)
4. Der DS-Eintrag von captaindns.com ist nun validiert

Schritt 4: deine Zone validieren

1. Der Resolver fragt den DNSKEY von captaindns.com an
2. Er vergleicht den Hash der KSK mit dem in Schritt 3 validierten DS-Eintrag
3. Wenn der Hash übereinstimmt, sind die DNSKEY legitim
4. Der Resolver fragt den A-Eintrag an und verifiziert seinen RRSIG mit der ZSK

Wenn alle Schritte erfolgreich sind, wird die Antwort als SECURE markiert (Flag ad in der DNS-Antwort). Wenn ein Schritt fehlschlägt, ist die Antwort BOGUS und der Resolver gibt SERVFAIL zurück.

Wann bricht die Kette?

Drei Szenarien verursachen einen Bruch der Vertrauenskette.

DS-Eintrag fehlt oder ist fehlerhaft

Der DS-Eintrag beim TLD stimmt nicht mit der KSK überein, die in deiner Zone veröffentlicht ist. Ursachen:

• Der DS-Eintrag wurde nie beim Registrar hinzugefügt (die Zone ist signiert, aber die Kette ist nicht aufgebaut)
• Die KSK wurde erneuert, ohne den DS-Eintrag zu aktualisieren
• Ein Fehler in den Werten des DS-Eintrags (Key Tag, Algorithm, Digest)

Ergebnis: INSECURE wenn kein DS-Eintrag vorhanden. BOGUS wenn der DS-Eintrag existiert, aber nicht übereinstimmt.

Abgelaufene RRSIG-Signaturen

Jede RRSIG-Signatur hat eine Gültigkeitsdauer. Wenn die Signaturen nicht vor Ablauf erneuert werden, lehnt der Resolver sie ab.

Ergebnis: BOGUS für alle Einträge, deren Signatur abgelaufen ist.

Vorbeugung: Managed DNS-Anbieter (Cloudflare, Route 53, OVHcloud) erneuern die Signaturen automatisch. Das Risiko besteht vor allem bei selbst verwalteten BIND- oder PowerDNS-Installationen.

Inkompatible Algorithmen

Wenn der DS-Eintrag einen anderen Algorithmus angibt als den, der vom DNSKEY verwendet wird, schlägt die Validierung fehl.

Ergebnis: BOGUS.

Deine Vertrauenskette prüfen

Um zu bestätigen, dass deine Kette intakt ist, verwende folgenden Befehl:

dig captaindns.com +dnssec +short

Das Flag ad (Authenticated Data) in der Antwort bestätigt, dass die vollständige Kette validiert ist:

dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

Für eine detaillierte Analyse jedes Glieds verwende unser Tool DNS Lookup, das die DNSKEY-, DS- und RRSIG-Einträge im Detail aufschlüsselt.

Empfohlener Aktionsplan

1. Konfiguration verstehen: Finde heraus, wer die Zonensignatur verwaltet (DNS-Anbieter) und wer den DS-Eintrag verwaltet (Registrar)
2. Kette prüfen: Bestätige, dass der DS-Eintrag beim TLD mit deiner KSK übereinstimmt, mit dig DS captaindns.com +short
3. Ablauf überwachen: Überwache die Gültigkeit der RRSIG-Signaturen und plane die Schlüsselrotationen
4. Prozedur dokumentieren: Halte die Schritte der KSK-Rotation für deinen spezifischen Registrar fest
5. Nach jeder Änderung testen: Prüfe die DNS-Propagation nach jeder DNSSEC-Änderung

Starte eine vollständige DNSSEC-Diagnose deiner Domain, um zu prüfen, ob jedes Glied der Kette korrekt ist.

Verwandte DNSSEC-Leitfäden

• DNSSEC aktivieren: Schritt-für-Schritt-Anleitung pro Registrar
• DANE/TLSA: die Komplettanleitung zur DNS-basierten Zertifikatauthentifizierung für E-Mail
• SERVFAIL nach DNSSEC-Aktivierung: Diagnose und Behebung (demnächst)

FAQ

Was ist die DNSSEC-Vertrauenskette?

Die DNSSEC-Vertrauenskette ist der Mechanismus, durch den jede Ebene der DNS-Hierarchie (Root, TLD, Domain) die Authentizität der nächsten Ebene über kryptografische Signaturen garantiert. Der Resolver verfolgt diese Kette vom Vertrauensanker (Root-KSK) bis zu deiner Domain.

Was ist ein Trust Anchor?

Ein Trust Anchor (Vertrauensanker) ist ein öffentlicher Schlüssel, den der Resolver ohne zusätzliche Verifizierung als vertrauenswürdig einstuft. Bei DNSSEC ist der Trust Anchor der KSK des DNS-Root. Er ist in der Konfiguration aller validierenden Resolver integriert.

Was ist der Unterschied zwischen ZSK und KSK?

Die ZSK (Zone Signing Key) signiert die DNS-Einträge deiner Zone (A, MX, TXT). Die KSK (Key Signing Key) signiert ausschließlich die DNSKEY. Ihre Trennung ermöglicht es, die ZSK häufig zu erneuern, ohne den DS-Eintrag beim Registrar ändern zu müssen.

Was passiert, wenn die Vertrauenskette unterbrochen ist?

Wenn ein Glied der Kette ungültig ist (falscher DS, abgelaufene Signatur, inkompatibler Schlüssel), markiert der Resolver die Antwort als BOGUS und gibt SERVFAIL an den Client zurück. Deine Besucher können deine Website nicht mehr erreichen, bis das Problem behoben ist.

Wie funktioniert DNSSEC?

DNSSEC fügt jedem DNS-Eintrag kryptografische Signaturen hinzu. Dein DNS-Anbieter signiert die Einträge mit einem privaten Schlüssel (ZSK). Der Resolver verifiziert die Signaturen mit dem öffentlichen Schlüssel (DNSKEY). Die Legitimität der Schlüssel wird durch einen DS-Eintrag beim TLD garantiert, der eine Vertrauenskette bis zum Root bildet.

Wie prüfe ich, ob DNSSEC für meine Domain funktioniert?

Führe dig captaindns.com +dnssec | grep flags aus. Wenn das Flag ad (Authenticated Data) vorhanden ist, ist die Vertrauenskette validiert. Du kannst auch ein Online-Tool verwenden, das den DS-Eintrag, die DNSKEY und die RRSIG-Signaturen überprüft.

Warum ist die KSK-Rotation riskant?

Die KSK-Rotation erfordert eine Aktualisierung des DS-Eintrags beim Registrar. Während des Übergangs müssen beide DS-Einträge (alter und neuer) koexistieren. Eine schlechte Koordination (alter DS wird gelöscht, bevor der neue propagiert ist) unterbricht die Kette und verursacht SERVFAIL-Fehler.

Funktioniert DNSSEC mit allen Resolvern?

Nein. Nur validierende Resolver überprüfen DNSSEC-Signaturen. Die wichtigsten öffentlichen Resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) validieren DNSSEC. Einige ISP-Resolver tun dies nicht. Laut APNIC werden im Jahr 2026 etwa 38 % der weltweiten DNS-Anfragen per DNSSEC validiert.

Glossar

• Trust Anchor (Vertrauensanker): Öffentlicher Schlüssel, den der Resolver ohne Verifizierung als vertrauenswürdig einstuft. Bei DNSSEC der KSK des DNS-Root.
• DS-Eintrag (Delegation Signer): Eintrag in der übergeordneten Zone, der einen Hash der KSK enthält. Verknüpfung zwischen zwei Hierarchieebenen.
• DNSKEY: Eintrag mit dem öffentlichen Signaturschlüssel. Flag 256 für die ZSK, Flag 257 für die KSK.
• RRSIG: Kryptografische Signatur eines DNS-Eintrags. Enthält den Algorithmus, den Gültigkeitszeitraum und den Key Tag.
• NSEC/NSEC3: Einträge zum authentifizierten Nachweis der Nichtexistenz. NSEC3 fügt Hashing hinzu, um Zonenauflistung zu verhindern.
• BOGUS: Status einer DNS-Antwort, deren DNSSEC-Validierung fehlgeschlagen ist. Der Resolver gibt SERVFAIL zurück.

Quellen

• RFC 4033 - DNS Security Introduction and Requirements
• RFC 4034 - Resource Records for the DNS Security Extensions
• RFC 4035 - Protocol Modifications for the DNS Security Extensions
• IANA - DNSSEC Trust Anchor