Vetrauenskette bei DNSSEC im LAB: Unterschied zwischen den Versionen

Aktuelle Version vom 2. Juni 2026, 05:32 Uhr

Grundlegendes

DNSSEC ergänzt DNS um kryptografische Signaturen.
Diese Signaturen garantieren Authentizität (Antwort kommt vom richtigen Nameserver) und Integrität (Antwort wurde nicht manipuliert).
DNSSEC verschlüsselt nicht – DNS-Abfragen sind weiterhin im Klartext lesbar.
DNSSEC schützt nur die Strecke bis zum validierenden Resolver. Zwischen Resolver und Client findet keine Validierung statt.

Aufbau

Dieser Beitrag enthält eine Rahmenhandlung.

[Bearbeiten]

Kurz und knapp

Chain of Trust → bestätigt KSK → KSK bestätigt ZSK → ZSK bestätigt Nutzdaten

KSK - signiert nur die Schlüssel (DNSKEY-Record) der eigenen Zone
ZSK - signiert die Nutzdaten (A, AAAA, MX usw.) der eigenen Zone

Der KSK signiert also den ZSK – der ZSK macht die eigentliche Arbeit.

Szenario im Lab

Der Resolver von ns.it201.int löst mail.it213.int auf.
Der Resolver hat den Trust Anchor für .int fest hinterlegt.
Die Root-Zone und TLD-Validierung entfallen damit vollständig.

Schritt	Aktion	Signiert/Geprüft mit
1	Trust Anchor: KSK von .int (öffentlich) ist fest im Resolver hinterlegt	–
2	Resolver holt DNSKEY von .int → ZSK von .int (öffentlich) wird vertraut	Signiert vom KSK von .int (privat) → geprüft mit Trust Anchor
3	Resolver holt DS-Record für it213.int → KSK von it213.int (öffentlich) wird vertraut	Signiert vom ZSK von .int (privat) → geprüft mit ZSK von .int (öffentlich)
4	Resolver holt DNSKEY von it213.int → ZSK von it213.int (öffentlich) wird vertraut	Signiert vom KSK von it213.int (privat) → geprüft mit KSK von it213.int (öffentlich)
5	Resolver holt A-Record mail.it213.int → authentisch	Signiert vom ZSK von it213.int (privat) → geprüft mit ZSK von it213.int (öffentlich)

Farbkonvention

Grün – privater Schlüssel (muss nie vertraut werden, bleibt geheim)
Rot – öffentlicher Schlüssel (noch nicht vertraut)
Blau – öffentlicher Schlüssel (vertraut)

Ablauf der Validierung

Schritt 1: Trust Anchor – KSK von .int

Der Resolver hat den KSK von .int (öffentlich) fest hinterlegt (z. B. in BIND oder Unbound als trusted-keys bzw. trust-anchor).
Dieser ist der Startpunkt der Vertrauenskette – er wird nicht aus dem Netz geholt, sondern ist bereits bekannt und vertraut.

Schritt 2: DNSKEY von .int – ZSK von .int vertrauen

Der Resolver holt den DNSKEY-Record der .int-Zone – dieser enthält den KSK von .int (öffentlich) und den ZSK von .int (öffentlich).
Der Resolver benötigt den ZSK von .int (öffentlich) – dieser ist nicht fest hinterlegt und muss aus der Zone geholt werden.
Der KSK von .int (privat) hat diesen DNSKEY-Record signiert → RRSIG.
Der Resolver:
1. entschlüsselt die Signatur des DNSKEY-Records mit dem fest hinterlegten KSK von .int (öffentlich)
2. berechnet selbst den Hash über den DNSKEY-Record
3. vergleicht beide Werte – stimmen sie überein → DNSKEY-Record authentisch
Der Resolver vertraut nun dem ZSK von .int (öffentlich).

Schritt 3: DS-Record für it213.int – KSK von it213.int vertrauen

Die .int-Zone enthält einen DS-Record für it213.int – dieser enthält den Hash des KSK von it213.int (öffentlich).
Der ZSK von .int (privat) hat diesen DS-Record signiert → RRSIG.
Der Resolver:
1. holt DS-Record und RRSIG aus der .int-Zone
2. entschlüsselt die Signatur mit dem ZSK von .int (öffentlich)
3. berechnet selbst den Hash über den DS-Record
4. vergleicht beide Werte – stimmen sie überein → DS-Record authentisch
Der Resolver vertraut nun dem KSK von it213.int (öffentlich).

Schritt 4: DNSKEY von it213.int – ZSK von it213.int vertrauen

Der Resolver holt den DNSKEY-Record von it213.int – dieser enthält den KSK von it213.int (öffentlich) und den ZSK von it213.int (öffentlich).
Der Resolver benötigt den ZSK von it213.int (öffentlich) – dieser ist nicht bekannt und muss aus der Zone geholt werden.
Der KSK von it213.int (privat) hat diesen DNSKEY-Record signiert → RRSIG.
Der Resolver:
1. entschlüsselt die Signatur des DNSKEY-Records mit dem KSK von it213.int (öffentlich) (bereits vertraut aus Schritt 3)
2. berechnet selbst den Hash über den DNSKEY-Record
3. vergleicht beide Werte – stimmen sie überein → DNSKEY-Record authentisch
Der Resolver vertraut nun dem ZSK von it213.int (öffentlich).

Schritt 5: A-Record mail.it213.int – Nutzdaten prüfen

Der autoritative Nameserver von it213.int hat den A-Record von mail.it213.int mit dem ZSK von it213.int (privat) signiert → RRSIG.
Der Resolver:
1. holt A-Record und RRSIG von it213.int
2. berechnet selbst den Hash des A-Records
3. entschlüsselt die Signatur mit dem ZSK von it213.int (öffentlich)
4. vergleicht beide Werte – stimmen sie überein → A-Record authentisch und unmanipuliert

Begriffe

DS (Delegation Signer): Hash des öffentlichen KSK der Kind-Zone, hinterlegt in der Eltern-Zone.
KSK (Key Signing Key): Signiert nur den DNSKEY-RRset der eigenen Zone.
ZSK (Zone Signing Key): Signiert die eigentlichen Nutzdaten der eigenen Zone (A, AAAA, MX usw.).
RRSIG: Digitale Signatur für einen Resource Record Set.
Trust Anchor: Öffentlicher KSK von .int, dem der Resolver blind vertraut – Startpunkt der Kette.

DNSSEC manuell prüfen mit dig

DNSKEY von .int prüfen

dig int DNSKEY +dnssec

Zeigt den DNSKEY-Record der .int-Zone mit KSK von .int (Flag 257) und ZSK von .int (Flag 256). Das ad-Flag im Header zeigt an, dass der lokale Resolver DNSSEC validiert.

DS-Record für it213.int prüfen

dig it213.int DS +dnssec

Zeigt den DS-Record in der .int-Zone – enthält den Hash des KSK von it213.int (öffentlich).

DNSKEY von it213.int prüfen

dig it213.int DNSKEY +dnssec

Zwei Keys erwartet: KSK von it213.int (Flag 257) und ZSK von it213.int (Flag 256).

A-Record und Signatur prüfen

dig mail.it213.int A +dnssec

In der ANSWER SECTION erscheinen der A-Record und direkt darunter der RRSIG – signiert vom ZSK von it213.int (privat).

Komplette Kette verfolgen

dig mail.it213.int A +trace +dnssec

Zeigt die Delegation Schritt für Schritt von .int abwärts.

@@ Zeile 8: / Zeile 8: @@
 * Dieser Beitrag enthält eine Rahmenhandlung.
 {{#Drawio:sig-test}}
+==Kurz und knapp==
+;Chain of Trust → bestätigt KSK → KSK bestätigt ZSK → ZSK bestätigt Nutzdaten
+*KSK - signiert nur die Schlüssel (DNSKEY-Record) der eigenen Zone
+*ZSK - signiert die Nutzdaten (A, AAAA, MX usw.) der eigenen Zone
+;Der KSK signiert also den ZSK – der ZSK macht die eigentliche Arbeit.
 ==Szenario im Lab==
@@ Zeile 13: / Zeile 19: @@
 * Der Resolver hat den '''Trust Anchor für .int''' fest hinterlegt.
 * Die Root-Zone und TLD-Validierung entfallen damit vollständig.
-Die Vertrauenskette hat dadurch nur noch '''drei Stufen''':
 {| class="wikitable"
-! Stufe !! Vertrauens-Objekt !! Validiert durch
+! Schritt !! Aktion !! Signiert/Geprüft mit
+|-
+| '''1'''
+| Trust Anchor: KSK von .int (öffentlich) ist fest im Resolver hinterlegt
+| –
 |-
-| '''Trust Anchor'''
+| '''2'''
-| KSK von .int (öffentlich)
+| Resolver holt DNSKEY von .int → ZSK von .int (öffentlich) wird vertraut
-| Fest im Resolver hinterlegt
+| Signiert vom KSK von .int (privat) → geprüft mit Trust Anchor
 |-
-| '''Delegation'''
+| '''3'''
-| DS-Record für it213.int
+| Resolver holt DS-Record für it213.int → KSK von it213.int (öffentlich) wird vertraut
-| Signiert vom ZSK von .int (privat)
+| Signiert vom ZSK von .int (privat) → geprüft mit ZSK von .int (öffentlich)
 |-
-| '''Domain-Schlüssel'''
+| '''4'''
-| DNSKEY von it213.int
+| Resolver holt DNSKEY von it213.int → ZSK von it213.int (öffentlich) wird vertraut
-| KSK von it213.int durch DS bestätigt → ZSK von it213.int vertraut
+| Signiert vom KSK von it213.int (privat) → geprüft mit KSK von it213.int (öffentlich)
 |-
-| '''Nutzdaten'''
+| '''5'''
-| RRSIG des A-Records mail.it213.int
+| Resolver holt A-Record mail.it213.int → authentisch
-| Signiert vom ZSK von it213.int (privat)
+| Signiert vom ZSK von it213.int (privat) → geprüft mit ZSK von it213.int (öffentlich)
 |}
@@ Zeile 43: / Zeile 51: @@
 ==Ablauf der Validierung==
-===Schritt 1: Trust Anchor – .int===
+===Schritt 1: Trust Anchor – KSK von .int===
-* Der Resolver kennt den <span style="color:#007BFF;">KSK von .int (öffentlich)</span> als Trust Anchor.
+* Der Resolver hat den <span style="color:#007BFF;">KSK von .int (öffentlich)</span> fest hinterlegt (z. B. in BIND oder Unbound als '''trusted-keys''' bzw. '''trust-anchor''').
-* Dieser ist fest im Resolver hinterlegt (z. B. in BIND oder Unbound als '''trusted-keys''' bzw. '''trust-anchor''').
+* Dieser ist der Startpunkt der Vertrauenskette – er wird nicht aus dem Netz geholt, sondern ist bereits bekannt und vertraut.
-* Er ist der Startpunkt der Vertrauenskette.
-* Der Resolver vertraut damit dem <span style="color:#007BFF;">KSK von .int (öffentlich)</span>.
-===Schritt 2: Delegation – DS-Record für it213.int===
+===Schritt 2: DNSKEY von .int – ZSK von .int vertrauen===
-* Die .int-Zone veröffentlicht einen DNSKEY-Record mit dem <span style="color:#007BFF;">KSK von .int (öffentlich)</span> und dem <span style="color:#FF0000;">ZSK von .int (öffentlich)</span>.
+* Der Resolver holt den DNSKEY-Record der .int-Zone – dieser enthält den <span style="color:#007BFF;">KSK von .int (öffentlich)</span> und den <span style="color:#FF0000;">ZSK von .int (öffentlich)</span>.
-* Der <span style="color:#008000;">KSK von .int (privat)</span> signiert diesen DNSKEY-Record → RRSIG.
+* Der Resolver benötigt den <span style="color:#FF0000;">ZSK von .int (öffentlich)</span> – dieser ist nicht fest hinterlegt und muss aus der Zone geholt werden.
-* Der Resolver prüft diesen DNSKEY-Record mit dem bereits vertrauten <span style="color:#007BFF;">KSK von .int (öffentlich)</span>.
+* Der <span style="color:#008000;">KSK von .int (privat)</span> hat diesen DNSKEY-Record signiert → RRSIG.
+* Der Resolver:
+*# entschlüsselt die Signatur des DNSKEY-Records mit dem fest hinterlegten <span style="color:#007BFF;">KSK von .int (öffentlich)</span>
+*# berechnet selbst den Hash über den DNSKEY-Record
+*# vergleicht beide Werte – stimmen sie überein → DNSKEY-Record authentisch
 * Der Resolver vertraut nun dem <span style="color:#007BFF;">ZSK von .int (öffentlich)</span>.
+===Schritt 3: DS-Record für it213.int – KSK von it213.int vertrauen===
 * Die .int-Zone enthält einen DS-Record für it213.int – dieser enthält den Hash des <span style="color:#FF0000;">KSK von it213.int (öffentlich)</span>.
-* Der <span style="color:#008000;">ZSK von .int (privat)</span> signiert diesen DS-Record → RRSIG.
+* Der <span style="color:#008000;">ZSK von .int (privat)</span> hat diesen DS-Record signiert → RRSIG.
 * Der Resolver:
 *# holt DS-Record und RRSIG aus der .int-Zone
@@ Zeile 63: / Zeile 75: @@
 * Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von it213.int (öffentlich)</span>.
-===Schritt 3: Domain-Schlüssel – DNSKEY von it213.int===
+===Schritt 4: DNSKEY von it213.int – ZSK von it213.int vertrauen===
-* it213.int veröffentlicht seinen DNSKEY-Record mit dem <span style="color:#007BFF;">KSK von it213.int (öffentlich)</span> und dem <span style="color:#FF0000;">ZSK von it213.int (öffentlich)</span>.
+* Der Resolver holt den DNSKEY-Record von it213.int – dieser enthält den <span style="color:#007BFF;">KSK von it213.int (öffentlich)</span> und den <span style="color:#FF0000;">ZSK von it213.int (öffentlich)</span>.
-* Der <span style="color:#008000;">KSK von it213.int (privat)</span> signiert den DNSKEY-Record → RRSIG.
+* Der Resolver benötigt den <span style="color:#FF0000;">ZSK von it213.int (öffentlich)</span> – dieser ist nicht bekannt und muss aus der Zone geholt werden.
+* Der <span style="color:#008000;">KSK von it213.int (privat)</span> hat diesen DNSKEY-Record signiert → RRSIG.
 * Der Resolver:
-*# holt DNSKEY-Record und RRSIG von it213.int
+*# entschlüsselt die Signatur des DNSKEY-Records mit dem <span style="color:#007BFF;">KSK von it213.int (öffentlich)</span> (bereits vertraut aus Schritt 3)
-*# entschlüsselt die Signatur mit dem <span style="color:#007BFF;">KSK von it213.int (öffentlich)</span> (bereits vertraut aus Schritt 2)
 *# berechnet selbst den Hash über den DNSKEY-Record
 *# vergleicht beide Werte – stimmen sie überein → DNSKEY-Record authentisch
 * Der Resolver vertraut nun dem <span style="color:#007BFF;">ZSK von it213.int (öffentlich)</span>.
-===Schritt 4: Nutzdaten – A-Record mail.it213.int===
+===Schritt 5: A-Record mail.it213.int – Nutzdaten prüfen===
-* Der autoritative Nameserver von it213.int signiert den A-Record mit dem <span style="color:#008000;">ZSK von it213.int (privat)</span> → RRSIG.
+* Der autoritative Nameserver von it213.int hat den A-Record von mail.it213.int mit dem <span style="color:#008000;">ZSK von it213.int (privat)</span> signiert → RRSIG.
 * Der Resolver:
 *# holt A-Record und RRSIG von it213.int
@@ Zeile 83: / Zeile 95: @@
 ==Begriffe==
 ; DS (Delegation Signer): Hash des öffentlichen KSK der Kind-Zone, hinterlegt in der Eltern-Zone.
-; KSK (Key Signing Key): Signiert nur den DNSKEY-RRset der eigenen Zone (die Schlüssel selbst).
+; KSK (Key Signing Key): Signiert nur den DNSKEY-RRset der eigenen Zone.
 ; ZSK (Zone Signing Key): Signiert die eigentlichen Nutzdaten der eigenen Zone (A, AAAA, MX usw.).
 ; RRSIG: Digitale Signatur für einen Resource Record Set.
@@ Zeile 90: / Zeile 102: @@
 ==DNSSEC manuell prüfen mit dig==
-===Trust Anchor und DNSKEY von .int prüfen===
+===DNSKEY von .int prüfen===
 <pre>dig int DNSKEY +dnssec</pre>
-Zeigt den DNSKEY-Record der .int-Zone mit KSK von .int (öffentlich) und ZSK von .int (öffentlich). Das '''ad'''-Flag im Header zeigt an, dass der lokale Resolver DNSSEC validiert.
+Zeigt den DNSKEY-Record der .int-Zone mit KSK von .int (Flag 257) und ZSK von .int (Flag 256). Das '''ad'''-Flag im Header zeigt an, dass der lokale Resolver DNSSEC validiert.
 ===DS-Record für it213.int prüfen===