Wie DNSSEC funktioniert — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC erklärt

DNSSEC authentifiziert DNS-Daten über eine Hierarchie kryptografischer Signaturen, die von einem Datensatz in Ihrer Zone bis zu einem in jedem validierenden Resolver fest verdrahteten Vertrauensanker reicht. Dieser Leitfaden erläutert die beweglichen Teile — DNSKEY, DS, RRSIG, NSEC/NSEC3 und die KSK-/ZSK-Rollen — auf einem Niveau, das Ihnen erlaubt, über reale Deployments nachzudenken, ohne Kryptograf zu sein.

Für die operativen Rollover-Verfahren (Pre-Publish-ZSK, Double-Signature-KSK, Algorithmus-Rollover) lesen Sie weiter bei DNSSEC-Schlüsselverwaltung. Für die hochrangige Einführung ohne Mechanik ist die Seite Was ist DNSSEC? der bessere Einstiegspunkt.

Die beteiligten Datensätze

DNSSEC bringt vier neue Datensatztypen in eine signierte Zone, plus DS-Datensätze, die in der übergeordneten Zone veröffentlicht werden:

Signierschlüssel: KSK, ZSK, CSK

DNSSEC verwendet historisch eine Zwei-Schlüssel-Trennung: einen KSK für hochwertige Operationen mit niedriger Frequenz und einen ZSK für Operationen mit hoher Frequenz und geringerer Zeremonie. Die Motivation ist rein operativ — kryptografisch tun beide Schlüssel dasselbe (Daten mit einem privaten Schlüssel signieren, mit einem öffentlichen verifizieren).

Zone-Signing-Key (ZSK)

Der ZSK signiert alles in Ihrer Zone außer dem DNSKEY-Datensatz-Set. Wenn ein Resolver die A-Datensätze von example.com anfragt, kommt die Antwort mit einem entsprechenden RRSIG-Datensatz zurück, der vom ZSK signiert ist. Jedes signierte Datensatz-Set hat seinen eigenen RRSIG.

ZSKs sind typischerweise:

• Kleiner (1024-Bit-RSA war in frühen Deployments üblich; ECDSA P-256 / 256-Bit-Schlüssel sind die moderne Norm)
• Relativ häufig rotiert (alle 1–3 Monate historisch; einige Betreiber überspringen geplante Rotationen mit starker Schlüsselverwahrung)
• Einfacher zu rotieren, weil der DS-Datensatz der übergeordneten Zone nicht geändert werden muss

Key-Signing-Key (KSK)

Der KSK signiert ausschließlich das DNSKEY-Datensatz-Set. Dieses Set enthält den öffentlichen Teil jedes aktiven Signierschlüssels in der Zone. Indem der KSK das DNSKEY-Set signiert, bindet er jeden anderen Schlüssel in der Zone (insbesondere jeden aktiven ZSK) an einen Schlüssel, dessen Hash bei der übergeordneten Zone veröffentlicht ist.

KSKs sind typischerweise:

• Größer (2048-Bit-RSA, ECDSA P-256 oder Ed25519 sind alle üblich)
• Selten rotiert (alle 1–5 Jahre, oder nur bei vermuteter Kompromittierung)
• Aufwendiger zu rotieren, weil der DS-Datensatz beim Übergeordneten aktualisiert werden muss, was den Registrar und TLD-Timing einbezieht

Combined Signing Key (CSK)

Ein CSK übernimmt beide Rollen in einem einzigen Schlüssel. Derselbe Schlüssel signiert DNSKEY (KSK-Rolle) und andere Datensatz-Sets (ZSK-Rolle). Moderne Deployments verwenden zunehmend CSK mit ECDSA P-256 oder Ed25519, weil:

• Signaturen klein genug sind, dass die Pro-Anfrage-Kosten vernachlässigbar sind
• Die operative Komplexität geringer ist (ein Schlüssel zu verwalten, ein Rollover zu koordinieren)
• HSM-gestützte Schlüsselverwahrung das Sicherheitsargument für die Trennung von KSK und ZSK reduziert

DNScale verwendet für neue Zonen standardmäßig CSK mit ECDSA P-256 — das ist der Standard für die meisten modernen Managed-Anbieter.

DNSKEY: Öffentliche Schlüssel in der Zone veröffentlichen

Jeder aktive Signierschlüssel hat seinen öffentlichen Teil als DNSKEY-Datensatz an der Zonenwurzel veröffentlicht:

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

Die Felder dekodiert:

• Flags (257 oder 256): Bit 7 (SEP — Secure Entry Point) ist beim KSK gesetzt, ergibt 257. Der ZSK hat 256. Beide Formate teilen Bit 8 (Zone Key), das in DNSKEY immer gesetzt ist.
• Protokoll (3): in gültigem DNSSEC immer 3.
• Algorithmus (hier 13): 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. Die volle Liste unter IANA DNSSEC Algorithms.
• Öffentlicher Schlüssel (Base64-codiert): das eigentliche Schlüsselmaterial.

Ein validierender Resolver holt das DNSKEY-Set, wenn er einen Datensatz Ihrer Zone validiert, und nutzt den passenden Schlüssel (KSK für den DNSKEY-RRSIG selbst, ZSK für alles andere).

RRSIG: Die Signaturen

Jedes signierte Datensatz-Set in Ihrer Zone wird von einem oder mehreren RRSIG-Datensätzen begleitet — einer pro aktivem Signierschlüssel für diese Rolle. Ein RRSIG sieht so aus:

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

Die RRSIG-Felder:

• Type covered (A): Typ des signierten Datensatz-Sets.
• Algorithmus (13): muss mit dem DNSKEY-Algorithmus übereinstimmen.
• Labels (2): Anzahl der Labels im ursprünglich signierten Namen.
• Original-TTL (3600): TTL, die das Datensatz-Set bei der Signatur hatte.
• Signaturablauf (20260601000000) und Signaturbeginn (20260501000000): UTC-Zeitstempel. Die Signatur ist nur in diesem Fenster gültig.
• Key-Tag (12345): kurze Kennung, welcher DNSKEY in der Zone diese Signatur erzeugt hat. Stimmt mit dem Key-Tag des entsprechenden DNSKEY-Datensatzes überein.
• Signer-Name (example.com.): die Zone, deren Schlüssel dies signiert hat.
• Signatur (Base64-codiert): die eigentliche kryptografische Signatur.

Die Ablauffenster der Signaturen sind der Grund, warum DNSSEC operativ nicht trivial ist. Wenn Ihr autoritativer Server aufhört, die Zone neu zu signieren — selbst kurzzeitig —, beginnen Signaturen abzulaufen, validierende Resolver geben SERVFAIL zurück und Ihre Domain ist faktisch offline. Managed-Anbieter signieren automatisch nach; selbst gehostetes DNSSEC erfordert eine funktionierende Signer-Pipeline.

DS-Datensätze: Die Verbindung zur übergeordneten Zone

Der DS (Delegation Signer) ist das Scharnier, das Ihre Zone in die globale Vertrauenskette einbindet. Er liegt in der übergeordneten Zone (.com, .eu, .de usw.) und enthält einen Hash Ihres KSK. Sie fügen ihn nicht in Ihre eigene Zone ein — Sie veröffentlichen ihn beim Registrar, der ihn an die TLD-Registrierung weiterleitet.

Ein DS-Datensatz in der übergeordneten Zone sieht so aus:

example.com.   86400   IN   DS   12345 13 2 7c89...

Felder:

• Key-Tag (12345): Kennung, welchen KSK dieser DS hasht (passt zum DNSKEY-Key-Tag).
• Algorithmus (13): muss mit dem DNSKEY-Algorithmus übereinstimmen.
• Digest-Typ (2): SHA-256 (2) oder SHA-384 (4) — SHA-1 (1) ist veraltet.
• Digest (hex-codiert): der eigentliche Hash.

Wenn ein validierender Resolver Ihre Zone authentifizieren möchte, holt er den DS-Datensatz aus der übergeordneten Zone (z. B. von den .com-Nameservern), holt dann Ihr DNSKEY-Set, berechnet den Hash des passenden KSK und prüft, ob er dem Digest im DS entspricht. Wenn sie übereinstimmen, vertraut der Resolver dem DNSKEY-Set Ihrer Zone und damit den mit diesen Schlüsseln signierten RRSIGs.

Das ist die einzige automatisierte Verbindung von außerhalb Ihrer Zone in das Schlüsselmaterial Ihrer Zone hinein. Wenn der DS falsch ist, schlägt die DNSSEC-Validierung fehl — oder schlimmer: Ihre Domain wird für validierende Clients unauflösbar.

NSEC und NSEC3: Authentifizierte Negativantwort

Ein subtiles, aber wichtiges Problem: DNSSEC kann nicht nur die existierenden Datensätze signieren. Es muss auch beweisen, wenn ein Resolver nonexistent.example.com anfragt, dass der Name wirklich nicht existiert, statt dass die Antwort still verworfen oder gefälscht wird.

Der Mechanismus ist NSEC (RFC 4034) oder NSEC3 (RFC 5155).

NSEC

NSEC-Datensätze sind alphabetisch sortiert und ketten sich durch die in der Zone existierenden Namen. Beispiel:

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; wickelt zum Anfang

Ein Resolver, der beta.example.com anfragt, erhält den signierten NSEC für alpha.example.com zurück, der beweist, dass zwischen alpha und gamma nichts existiert — also existiert beta nicht. Die Signatur am NSEC authentifiziert die Negativantwort.

Der Nachteil: NSEC-Datensätze listen jeden Namen in der Zone öffentlich auf. Wer die NSEC-Kette abläuft, kann eine vollständige Liste aller Datensatznamen erstellen. Das nennt sich „Zone Walking" und gilt manchmal als Datenschutzleck.

NSEC3

NSEC3 verzeichnet dieselbe Kette, verwendet aber gehashte Namen statt Klartext-Namen, plus eine Iterationszahl und ein Salt:

< Hash von alpha >.example.com.    NSEC3 1 0 10 abcd123...    < Hash von gamma > A RRSIG NSEC3

Resolver können wie zuvor Negativantworten verifizieren (Hash des angefragten Namens berechnen, NSEC3 finden, der ihn überdeckt), aber ein Angreifer kann die Zone nicht trivial ablaufen — er müsste jeden Hash knacken. NSEC3 unterstützt auch Opt-out, wodurch Registrierungen unsignierte Delegationen überspringen können, um nicht jede nicht existierende Subzone NSEC3-signieren zu müssen.

Moderne Empfehlung: NSEC3 mit Iterationen=0 und festem Salt (oder ohne Salt). Hohe Iterationszahlen erzeugen CPU-Kosten ohne nennenswerten Datenschutznutzen, weil Angreifer mit GPUs jede nicht-Null-Anzahl knacken können. Der „White-Lies"-Ansatz (RFC 4470) ist eine weitere Möglichkeit, das Zone-Walking-Risiko zu reduzieren, ohne die Einfachheit von NSEC aufzugeben.

Der Validierungsablauf — Schritt für Schritt

Was passiert tatsächlich, wenn ein validierender Resolver eine DNSSEC-signierte Antwort erhält? Bei dig +dnssec example.com @1.1.1.1:

1. Der Resolver erhält A-Datensatz + RRSIG von Ihrem autoritativen Server.
2. Der Resolver holt das DNSKEY-Set Ihrer Zone + RRSIG. Jetzt hat er sowohl die Daten als auch die Schlüssel (in öffentlicher Form), die zur Verifikation benötigt werden.
3. Der Resolver prüft den Daten-RRSIG gegen den ZSK im DNSKEY-Set. Ungültige Signatur → Validierung schlägt sofort fehl.
4. Der Resolver prüft den DNSKEY-RRSIG gegen den KSK im DNSKEY-Set. Der KSK hat das DNSKEY-Datensatz-Set inklusive ZSK signiert. Dieser Schritt bindet den ZSK an den KSK.
5. Der Resolver holt den DS-Datensatz aus der übergeordneten Zone (z. B. von den .com-Nameservern). Der DS enthält einen Hash des KSK.
6. Der Resolver berechnet den Hash des KSK und vergleicht ihn mit dem DS. Übereinstimmung → die übergeordnete Zone bestätigt, welcher KSK für Ihre Zone autoritativ ist.
7. Der Resolver wiederholt die Kette beim Übergeordneten. Der DS-Datensatz selbst ist von der ZSK der übergeordneten Zone signiert; das DNSKEY-Set der übergeordneten Zone ist von deren KSK signiert; deren KSK wird im DS der Großeltern-Zone gehasht und so weiter, bis zur Wurzel.
8. An der Wurzel vergleicht der Resolver den Hash des Wurzel-KSK mit dem Vertrauensanker, den er fest verdrahtet (oder per RFC 5011 automatisch aktualisiert) hat. Der aktuelle Wurzel-KSK ist unter https://data.iana.org/root-anchors/ veröffentlicht.

Wenn jede Signatur verifiziert und sich die Wurzel auf den Vertrauensanker zurückführen lässt, gibt der Resolver die Antwort mit gesetztem AD-Flag (Authenticated Data) zurück. Bei jedem Fehler unterwegs gibt der Resolver SERVFAIL zurück — lieber brechen als eine möglicherweise manipulierte Antwort ausliefern.

Was schiefgehen kann

Die ersten beiden — veralteter DS und abgelaufene Signaturen — verursachen die große Mehrheit echter DNSSEC-Ausfälle in der Praxis. Managed-Anbieter erledigen die Neusignierung automatisch; der DS-Datensatz beim Registrar ist die menschlich berührbare Fehlerstelle.

Zusammengefasst — Ein mentales Modell

Die scheinbare Komplexität von DNSSEC ist meist Buchhaltung. Die eigentliche kryptografische Frage ist einfach: Kommt diese Antwort von jemandem, der den privaten Schlüssel der Zone kontrolliert? Die Vertrauenskette ist eine Folge von Public-Key-Bindungen, jede ein normaler „Schlüssel A signiert Schlüssel B"- oder „Schlüssel A signiert Daten D"-Schritt:

• Der Wurzel-KSK signiert das Wurzel-DNSKEY-Set (das den Wurzel-ZSK enthält).
• Der Wurzel-ZSK signiert die DS-Datensätze der TLDs.
• Der KSK eines TLDs signiert das DNSKEY-Set des TLDs (das den ZSK des TLDs enthält).
• Der ZSK des TLDs signiert die DS-Datensätze der registrierten Zonen.
• Der KSK Ihrer Zone signiert Ihr DNSKEY-Set (das Ihren ZSK enthält).
• Ihr ZSK signiert jedes Datensatz-Set in Ihrer Zone — einschließlich der NSEC/NSEC3-Datensätze, die Negativantworten behandeln.

Jedes Glied ist nur eine Signatur; die Magie liegt darin, dass der Resolver nur den Wurzelschlüssel braucht, um sie alle zu verifizieren.

Quellen

• RFC 4033 — Einführung und Anforderungen der DNS Security Extensions
• RFC 4034 — Resource Records für die DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Protokollanpassungen für die DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Multi-Signer-DNSSEC-Modelle
• IANA DNSSEC Algorithm Numbers
• IANA Root Trust Anchors

Weiterführende Lektüre

• Was ist DNSSEC? — Top-of-Funnel-Einführung
• DNSSEC-Schlüsselverwaltung — operative Rollover-Verfahren
• DNSSEC-Setup-Leitfaden für DNScale — Produkt-Walkthrough
• DNSSEC vs DNS over HTTPS — Integrität vs. Privatsphäre
• DNS-Cache-Poisoning — der Angriff, den DNSSEC schlägt
• NIS2 und DNS-Compliance — DNSSEC als regulatorische Kontrolle