Vetrauenskette bei DNSSEC

Aufbau

• Dieses Beitrag enthält eine Rahmenhandlung.

Signierung und Prüfung

[Bearbeiten]

Ablauf in DNSSEC

Der Nameserver signiert den A-Record

• Der autoritative Nameserver erstellt einen Hash des A-Records (z. B. hund.example.com IN A 192.168.1.1).
• Dieser Hash wird mit dem ZSK von example.com (privat) signiert.
• Das Ergebnis dieser Signierung ist der RRSIG-Record (die Signatur), die den Hash enthält.
• Der Nameserver schickt dann den A-Record zusammen mit der RRSIG-Signatur an den Resolver.

Der Resolver überprüft die Signatur

• Der Resolver erhält den A-Record und die dazugehörige RRSIG-Signatur.
• Der Resolver berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der autoritative Nameserver).
• Der Resolver zieht den DNSKEY-Record, der den ZSK von example.com (öffentlich) enthält.
• Der Resolver entschlüsselt die RRSIG-Signatur mit dem ZSK von example.com (öffentlich).
• Der Resolver vergleicht den entschlüsselten Wert der Signatur mit dem von ihm selbst berechneten Hash des A-Records.
• Wenn beide Werte übereinstimmen, bedeutet dies, dass der A-Record authentisch ist und nicht manipuliert wurde.

Wie kann aber der Resolver dem autoritativen Nameserver vertrauen?

• Unser Ziel ist es, eine Vertrauenswürdigkeit zum ZSK von example.com (öffentlich) aufzubauen.
• Öffentliche Schlüssel sind bis wir ihnen vertrauen rot.
• Öffentliche Schlüssel, denen wir vertrauen, sind blau.
• Geheime Schlüssel, müssen wir nie vertrauen, darum sind diese grün.

Startpunkt der Vertrauenskette

• Der Resolver kennt den Root-KSK (öffentlich) als Trust Anchor.
• Dieser Root-KSK (öffentlich) ist fest in den Resolvern hinterlegt (z. B. in bind, unbound).
• Er ist der Startpunkt der Vertrauenskette (Chain of Trust).

Validierung der Root-Zone

Die Root-Zone veröffentlicht einen DNSKEY-Record mit zwei Schlüsseln und den RRSIG

• Der Root-ZSK (privat) (Zone Signing Key der Root-Zone) signiert alle anderen Records in der Root-Zone (z. B. den DS-Record für .com).
• Der Root-KSK (öffentlich) signiert den gesamten DNSKEY-Record, der sowohl den Root-KSK (öffentlich) als auch den Root-ZSK (öffentlich) enthält.
• Diese Signatur heißt RRSIG für den DNSKEY-Record der Root-Zone.
• Der RRSIG für den DNSKEY-Record der Root-Zone und der DNSKEY-Record der Root-Zone werden in der Root-Zone veröffentlicht.

Der Resolver zieht sich den RRSIG- und DNSKEY-Record

• Der Resolver zieht sich den DNSKEY-Record der Root-Zone, der den Root-ZSK (öffentlich) und den Root-KSK (öffentlich) enthält.
• Der Resolver zieht sich den RRSIG-Record für den DNSKEY-Record, der die Signatur über den gesamten DNSKEY-Record enthält.
• Der Resolver entschlüsselt die Signatur des DNSKEY-Records mit dem öffentlichen Root-KSK (öffentlich).
• Der Resolver berechnet einen Hash über den DNSKEY-Record der Root-Zone.
• Der Resolver vergleicht diesen berechneten Hash mit dem entschlüsselten Wert aus dem RRSIG-Record.
• Wenn beide übereinstimmen, ist der DNSKEY-Record der Root-Zone authentisch.
• Der Resolver vertraut nun dem Root-ZSK (öffentlich).

Validierung der TLD (.com)

Die Root-Zone veröffentlicht den DS-Record für .com

• Die Root-Zone enthält einen DS-Record für .com.
• Der DS-Record enthält den Hash des KSK von .com (öffentlich).
• Der Root-ZSK (privat) signiert diesen DS-Record und erzeugt den zugehörigen RRSIG-Record für den DS-Record.
• Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem Root-ZSK (öffentlich) erstellt wurde.
• DS-Record und der dazugehörige RRSIG-Record für den DS-Record von .com werden in der Root-Zone veröffentlicht.

Der Resolver zieht sich den RRSIG- und DS-Record

• Der Resolver zieht sich den DS-Record von .com, der den Hash des KSK von .com (öffentlich) enthält.
• Der Resolver zieht sich den RRSIG-Record für den DS-Record, der die Signatur über den DS-Record enthält.
• Der Resolver entschlüsselt die Signatur des DS-Records mit dem öffentlichen Root-ZSK (öffentlich).
• Der Resolver berechnet einen Hash über den DS-Record von .com.
• Der Resolver vergleicht diesen berechneten Hash mit dem entschlüsselten Wert aus dem RRSIG-Record.
• Wenn beide übereinstimmen, ist der DS-Record von .com authentisch.
• Der Resolver vertraut nun dem KSK von .com (öffentlich).

Vertrauen zur Second-Level-Domain

Die TLD (.com) veröffentlicht den DS-Record für example.com

• Die TLD (.com) enthält einen DS-Record für example.com.
• Der DS-Record enthält den Hash des KSK von example.com (öffentlich).
• Der KSK von .com (privat) signiert diesen DS-Record und erzeugt den zugehörigen RRSIG-Record für den DS-Record.
• Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem KSK von .com (öffentlich) erstellt wurde.
• DS-Record und der dazugehörige RRSIG-Record für den DS-Record von example.com werden in der .com-Zone veröffentlicht.

Der Resolver zieht sich den RRSIG- und DS-Record

• Der Resolver zieht sich den DS-Record von example.com, der den Hash des KSK von example.com (öffentlich) enthält.
• Der Resolver zieht sich den RRSIG-Record für den DS-Record, der die Signatur über den DS-Record enthält.
• Der Resolver entschlüsselt die Signatur des DS-Records von example.com mit dem öffentlichen KSK von .com (öffentlich).
• Der Resolver berechnet einen Hash des DS-Records.
• Der Resolver vergleicht diesen berechneten Hash mit dem entschlüsselten Wert aus dem RRSIG-Record.
• Wenn beide übereinstimmen, ist der DS-Record von example.com authentisch.
• Der Resolver vertraut nun dem KSK von example.com (öffentlich).

Abschluss der Vertrauenskette

Die Second-Level-Domain veröffentlicht ihren DNSKEY-Record

• Die Second-Level-Domain (example.com) veröffentlicht einen DNSKEY-Record.
• Dieser enthält den KSK von example.com (öffentlich) und den ZSK von example.com (öffentlich).
• Der KSK von example.com (privat) signiert den gesamten DNSKEY-Record der Second-Level-Domain und erzeugt den zugehörigen RRSIG-Record.
• Der RRSIG-Record für den DNSKEY-Record von example.com wird zusammen mit dem DNSKEY-Record veröffentlicht.

Der Resolver überprüft den ZSK von example.com

• Der Resolver zieht sich den DNSKEY-Record von example.com, der den KSK von example.com (öffentlich) und den ZSK von example.com (öffentlich) enthält.
• Der Resolver zieht sich den RRSIG-Record für den DNSKEY-Record, der die Signatur über den gesamten DNSKEY-Record enthält.
• Der Resolver entschlüsselt die Signatur des DNSKEY-Records mit dem öffentlichen KSK von example.com (öffentlich).
• Der Resolver berechnet einen Hash über den DNSKEY-Record der Second-Level-Domain.
• Der Resolver vergleicht diesen berechneten Hash mit dem entschlüsselten Wert aus dem RRSIG-Record.
• Wenn die Signatur gültig ist, ist der DNSKEY-Record der Second-Level-Domain authentisch.
• Der Resolver vertraut nun dem ZSK von example.com (öffentlich).

Der Resolver kann nun alle mit dem ZSK von example.com signierten Records validieren

• Der Resolver nutzt den ZSK von example.com (öffentlich), um die Signaturen aller weiteren DNS-Records der Domain zu überprüfen.
• Dazu gehören A-Records, MX-Records, TXT-Records usw.
• Wenn die Signaturprüfung erfolgreich ist, gelten diese Records als authentisch und nicht manipuliert.

Zusammenfassung: Die DNSSEC-Vertrauenskette

Die Validierung erfolgt immer von oben nach unten (Top-Down):

Ebene	Vertrauens-Objekt	Validiert durch
Root-Zone	Root-DNSKEY (KSK)	Trust Anchor (im Resolver fest hinterlegt)
TLD (z.B. .com)	DS-Record für .com	Signiert vom Root-ZSK
Domain (example.com)	DS-Record für example.com	Signiert vom TLD-KSK (.com)
Resource Record (A, MX)	RRSIG des Records	Signiert vom Domain-ZSK (example.com)

Wichtige Begriffe

• DS (Delegation Signer): Der Fingerabdruck des öffentlichen KSK der Kind-Zone, hinterlegt in der Eltern-Zone.
• KSK (Key Signing Key): Signiert nur den DNSKEY-RRset (die Schlüssel selbst).
• ZSK (Zone Signing Key): Signiert die eigentlichen Nutzdaten (A, AAAA, MX, etc.).
• RRSIG: Die digitale Signatur für ein Set von Records.

DNSSEC-Validierung manuell prüfen mit dig

Mit dem Werkzeug dig lassen sich die einzelnen Glieder der Vertrauenskette sichtbar machen.

1. Den Trust-Anchor (Root) prüfen

Der Resolver beginnt bei der Root-Zone. Wir können uns den DNSKEY der Root-Zone und die dazugehörige Signatur anzeigen lassen:

• dig . DNSKEY +dnssec

Hinweis: Achten Sie auf das ad (Authentic Data) Flag im Header der Antwort, wenn Ihr lokaler Resolver DNSSEC bereits validiert.

2. Den DS-Record der TLD prüfen

Wir prüfen, welcher Fingerabdruck für die TLD (z. B. .de oder .com) in der Root-Zone hinterlegt ist:

• dig de DS +dnssec

3. Die Delegation zur Domain prüfen

Nun prüfen wir den DS-Record für eine spezifische Domain bei der TLD:

• dig google.de DS +dnssec

Dieser Record muss vom KSK der TLD signiert sein.

4. Den ZSK der Domain prüfen

Wir holen uns die Schlüssel der Domain selbst:

• dig google.de DNSKEY +dnssec

Hier sehen wir meist zwei Keys: Den KSK (Flag 257) und den ZSK (Flag 256).

5. Den A-Record und seine Signatur prüfen

Zum Abschluss prüfen wir die eigentlichen Nutzdaten:

• dig www.google.de A +dnssec

In der ANSWER SECTION erscheint nun der A-Record und direkt darunter der RRSIG-Record.

Der "Magic"-Befehl für Faule

Wer die komplette Kette auf einmal sehen möchte (sehr ausführlich!), nutzt den Trace-Modus:

• dig google.de +sigchase +trusted-key=./root.key

(Hinweis: Je nach dig-Version müssen die Optionen ggf. angepasst werden, modernere Versionen nutzen oft +trace +dnssec)