Vetrauenskette bei DNSSEC im LAB

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]

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 drei Stufen:

Stufe	Vertrauens-Objekt	Validiert durch
Trust Anchor	KSK von .int (öffentlich)	Fest im Resolver hinterlegt
Delegation	DS-Record für it213.int	Signiert vom ZSK von .int (privat)
Domain-Schlüssel	DNSKEY von it213.int	KSK von it213.int durch DS bestätigt → ZSK von it213.int vertraut
Nutzdaten	RRSIG des A-Records mail.it213.int	Signiert vom ZSK von it213.int (privat)

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 – .int

• Der Resolver kennt den KSK von .int (öffentlich) als Trust Anchor.
• Dieser ist fest im Resolver hinterlegt (z. B. in BIND oder Unbound als trusted-keys bzw. trust-anchor).
• Er ist der Startpunkt der Vertrauenskette.
• Der Resolver vertraut damit dem KSK von .int (öffentlich).

Schritt 2: Delegation – DS-Record für it213.int

• Die .int-Zone veröffentlicht einen DNSKEY-Record mit dem KSK von .int (öffentlich) und dem ZSK von .int (öffentlich).
• Der KSK von .int (privat) signiert diesen DNSKEY-Record → RRSIG.
• Der Resolver prüft diesen DNSKEY-Record mit dem bereits vertrauten KSK von .int (öffentlich).
• Der Resolver vertraut nun dem ZSK von .int (öffentlich).
• 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) signiert diesen DS-Record → 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 3: Domain-Schlüssel – DNSKEY von it213.int

• it213.int veröffentlicht seinen DNSKEY-Record mit dem KSK von it213.int (öffentlich) und dem ZSK von it213.int (öffentlich).
• Der KSK von it213.int (privat) signiert den DNSKEY-Record → RRSIG.
• Der Resolver:
  1. holt DNSKEY-Record und RRSIG von it213.int
  2. entschlüsselt die Signatur mit dem KSK von it213.int (öffentlich) (bereits vertraut aus Schritt 2)
  3. berechnet selbst den Hash über den DNSKEY-Record
  4. vergleicht beide Werte – stimmen sie überein → DNSKEY-Record authentisch
• Der Resolver vertraut nun dem ZSK von it213.int (öffentlich).

Schritt 4: Nutzdaten – A-Record mail.it213.int

• Der autoritative Nameserver von it213.int signiert den A-Record mit dem ZSK von it213.int (privat) → 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 (die Schlüssel selbst).

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

Trust Anchor und DNSKEY von .int prüfen

dig int DNSKEY +dnssec

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.

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.