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]

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.