Vetrauenskette bei DNSSEC im LAB: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 1: | Zeile 1: | ||
| + | ==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. | ||
| + | {{#Drawio:sig-test}} | ||
| + | |||
| + | ==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. | ||
| + | |||
| + | Die Vertrauenskette hat dadurch nur noch '''vier Schritte''': | ||
| + | |||
| + | {| class="wikitable" | ||
| + | ! 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== | ||
| + | * <span style="color:#008000;">Grün</span> – privater Schlüssel (muss nie vertraut werden, bleibt geheim) | ||
| + | * <span style="color:#FF0000;">Rot</span> – öffentlicher Schlüssel (noch nicht vertraut) | ||
| + | * <span style="color:#007BFF;">Blau</span> – öffentlicher Schlüssel (vertraut) | ||
| + | |||
==Grundlegendes== | ==Grundlegendes== | ||
* DNSSEC ergänzt DNS um kryptografische Signaturen. | * DNSSEC ergänzt DNS um kryptografische Signaturen. | ||
| Zeile 87: | Zeile 133: | ||
*# entschlüsselt die Signatur mit dem <span style="color:#007BFF;">ZSK von it213.int (öffentlich)</span> | *# entschlüsselt die Signatur mit dem <span style="color:#007BFF;">ZSK von it213.int (öffentlich)</span> | ||
*# vergleicht beide Werte – stimmen sie überein → A-Record authentisch und unmanipuliert | *# 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=== | ||
| + | <pre>dig int DNSKEY +dnssec</pre> | ||
| + | Zeigt den DNSKEY-Record der .int-Zone mit <span style="color:#007BFF;">KSK von .int (öffentlich)</span> (Flag 257) und <span style="color:#007BFF;">ZSK von .int (öffentlich)</span> (Flag 256). Das '''ad'''-Flag im Header zeigt an, dass der lokale Resolver DNSSEC validiert. | ||
| + | |||
| + | ===DS-Record für it213.int prüfen=== | ||
| + | <pre>dig it213.int DS +dnssec</pre> | ||
| + | Zeigt den DS-Record in der .int-Zone – enthält den Hash des KSK von it213.int (öffentlich). | ||
| + | |||
| + | ===DNSKEY von it213.int prüfen=== | ||
| + | <pre>dig it213.int DNSKEY +dnssec</pre> | ||
| + | Zwei Keys erwartet: KSK von it213.int (Flag 257) und ZSK von it213.int (Flag 256). | ||
| + | |||
| + | ===A-Record und Signatur prüfen=== | ||
| + | <pre>dig mail.it213.int A +dnssec</pre> | ||
| + | In der ANSWER SECTION erscheinen der A-Record und direkt darunter der RRSIG – signiert vom ZSK von it213.int (privat). | ||
| + | |||
| + | ===Komplette Kette verfolgen=== | ||
| + | <pre>dig mail.it213.int A +trace +dnssec</pre> | ||
| + | Zeigt die Delegation Schritt für Schritt von .int abwärts. | ||
==Begriffe== | ==Begriffe== | ||
Version vom 2. Juni 2026, 05:21 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](javascript:editDrawio("1102348071", "sig-test.drawio.png", "png", false, false, false, true, "https://embed.diagrams.net")){kind=link}
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.
Die Vertrauenskette hat dadurch nur noch vier Schritte:
| 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)
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](javascript:editDrawio("1921005707", "sig-test.drawio.png", "png", false, false, false, true, "https://embed.diagrams.net")){kind=link}
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.
Die Vertrauenskette hat dadurch nur noch vier Schritte:
| 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 KSK von .int (privat) hat diesen DNSKEY-Record signiert → RRSIG.
- Der Resolver:
- entschlüsselt die Signatur des DNSKEY-Records mit dem fest hinterlegten KSK von .int (öffentlich)
- berechnet selbst den Hash über den DNSKEY-Record
- 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:
- holt DS-Record und RRSIG aus der .int-Zone
- entschlüsselt die Signatur mit dem ZSK von .int (öffentlich)
- berechnet selbst den Hash über den DS-Record
- 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
- it213.int veröffentlicht einen DNSKEY-Record mit dem KSK von it213.int (öffentlich) und dem ZSK von it213.int (öffentlich).
- Der KSK von it213.int (privat) hat diesen DNSKEY-Record signiert → RRSIG.
- Der Resolver:
- holt DNSKEY-Record und RRSIG von it213.int
- entschlüsselt die Signatur mit dem KSK von it213.int (öffentlich) (bereits vertraut aus Schritt 3)
- berechnet selbst den Hash über den DNSKEY-Record
- 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:
- holt A-Record und RRSIG von it213.int
- berechnet selbst den Hash des A-Records
- entschlüsselt die Signatur mit dem ZSK von it213.int (öffentlich)
- 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 (öffentlich) (Flag 257) und ZSK von .int (öffentlich) (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.
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 (öffentlich) (Flag 257) und ZSK von .int (öffentlich) (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.