Vetrauenskette bei DNSSEC: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied
 
(48 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Ablauf in DNSSEC=
==Aufbau==
*Dieses Beitrag enthält eine Rahmenhandlung.
==Signierung und Prüfung==
{{#Drawio:sig-test}}
== 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 <span style="color:#008000;">ZSK von example.com (privat)</span> 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 Nameserver signiert den A-Record:
=== Der Resolver überprüft die Signatur === 
** Der ZSK (Zone Signing Key) des authoritativen Nameservers für die Domain erstellt einen Hash des A-Records (z. B. hund.example.com IN A 192.168.1.1).
* Der Resolver erhält den A-Record und die dazugehörige RRSIG-Signatur. 
** Dieser Hash wird mit dem privaten ZSK signiert.
* Der Resolver berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der autoritative Nameserver).
** Das Ergebnis dieser Signierung ist der RRSIG-Record (die Signatur), die den Hash enthält.
* Der Resolver zieht den DNSKEY-Record, der den <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span> enthält.
** Der Nameserver schickt dann den A-Record zusammen mit der RRSIG-Signatur an den Resolver.
* Der Resolver entschlüsselt die RRSIG-Signatur mit dem <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span>.
* 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 <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span> aufzubauen. 
*Öffentliche Schlüssel sind bis wir ihnen vertrauen <span style="color:#FF0000;">rot</span>. 
*Öffentliche  Schlüssel, denen wir vertrauen, sind <span style="color:#007BFF;">blau</span>.
*Geheime Schlüssel, müssen wir nie vertrauen, darum sind diese <span style="color:#008000;">grün</span>.


* 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 Nameserver).
** Der Resolver zieht den DNSKEY-Record (der den öffentlichen ZSK enthält) und verwendet den öffentlichen ZSK, um die RRSIG-Signatur zu entschlüsseln.
** 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 der Resolver dem autoritativen Nameserver vertrauen?=
== Startpunkt der Vertrauenskette ==   
== Startpunkt der Vertrauenskette ==   
* Der Resolver kennt den KSK der Root-Zone als Trust Anchor.   
* Der Resolver kennt den <span style="color:#007BFF;">Root-KSK (öffentlich)</span> als Trust Anchor.   
* Dieser KSK ist fest in den Resolvern hinterlegt (z. B. in bind, unbound).   
* Dieser <span style="color:#007BFF;">Root-KSK (öffentlich)</span> ist fest in den Resolvern hinterlegt (z. B. in bind, unbound).   
* Er ist der Startpunkt der Vertrauenskette (Chain of Trust).
* Er ist der Startpunkt der Vertrauenskette (Chain of Trust).


== Validierung der Root-Zone ==   
== Validierung der Root-Zone ==   
=== Die Root-Zone veröffentlicht einen DNSKEY-Record mit zwei Schlüsseln und den RRSIG ===   
=== Die Root-Zone veröffentlicht einen DNSKEY-Record mit zwei Schlüsseln und den RRSIG ===   
* Der Root-KSK (Key Signing Key der Root-Zone) signiert nur den DNSKEY-Record der Root-Zone. 
* Der <span style="color:#008000;">Root-ZSK (privat)</span> (Zone Signing Key der Root-Zone) signiert alle anderen Records in der Root-Zone (z. B. den DS-Record für .com).   
* Der Root-ZSK (Zone Signing Key der Root-Zone) signiert alle anderen Records in der Root-Zone (z. B. den DS-Record für .com).   
* Der <span style="color:#007BFF;">Root-KSK (öffentlich)</span> signiert den gesamten DNSKEY-Record, der sowohl den <span style="color:#007BFF;">Root-KSK (öffentlich)</span> als auch den <span style="color:#FF0000;">Root-ZSK (öffentlich)</span> enthält.   
* Der Root-KSK signiert den gesamten DNSKEY-Record, der sowohl den Root-KSK als auch den Root-ZSK enthält.   
* Diese Signatur heißt RRSIG für den DNSKEY-Record der Root-Zone.   
* 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 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 RRSIG- und DNSKEY-Record ===   
* Der Resolver überprüft den Root-ZSK mit dem Root-KSK.   
* Der Resolver zieht sich den DNSKEY-Record der Root-Zone, der den <span style="color:#FF0000;">Root-ZSK (öffentlich)</span> und den <span style="color:#007BFF;">Root-KSK (öffentlich)</span> enthält.   
* Der Resolver berechnet einen Hash des DNSKEY-Records der Root-Zone und vergleicht ihn mit der Signatur aus dem RRSIG für den DNSKEY-Record der Root-Zone.   
* Der Resolver zieht sich den RRSIG-Record für den DNSKEY-Record, der die Signatur über den gesamten DNSKEY-Record enthält.   
* Die Signatur des DNSKEY-Records der Root-Zone wird mit dem öffentlichen Root-KSK überprüft.   
* Der Resolver entschlüsselt die Signatur des DNSKEY-Records mit dem öffentlichen <span style="color:#007BFF;">Root-KSK (öffentlich)</span>. 
* Wenn die Signatur gültig ist, ist der DNSKEY-Record der Root-Zone authentisch.   
* Der Resolver berechnet einen Hash über den DNSKEY-Record der Root-Zone. 
* Der Resolver vertraut nun dem <span style="color:#007BFF;">Root-ZSK</span>.
* 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 <span style="color:#007BFF;">Root-ZSK (öffentlich)</span>.


== Validierung der TLD (.com) ==   
== Validierung der TLD (.com) ==   
=== Die Root-Zone veröffentlicht den DS-Record für .com ===   
=== Die Root-Zone veröffentlicht den DS-Record für .com ===   
* Die Root-Zone enthält einen DS-Record für .com.   
* Die Root-Zone enthält einen DS-Record für .com.   
* Der DS-Record enthält den Hash des <span style="color:#007BFF;">KSK von .com</span>.   
* Der DS-Record enthält den Hash des <span style="color:#FF0000;">KSK von .com (öffentlich)</span>.   
* Der <span style="color:#007BFF;">Root-ZSK</span> signiert diesen DS-Record und erzeugt den zugehörigen RRSIG-Record für den DS-Record.   
* Der <span style="color:#008000;">Root-ZSK (privat)</span> 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 <span style="color:#007BFF;">Root-ZSK</span> erstellt wurde.   
* Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem <span style="color:#007BFF;">Root-ZSK (öffentlich)</span> erstellt wurde.   
* DS-Record und der dazugehörige RRSIG-Record für den DS-Record von .com werden in der Root-Zone veröffentlicht.   
* 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 RRSIG- und DS-Record ===   
* Der Resolver überprüft den DS-Record von .com mit dem <span style="color:#007BFF;">Root-ZSK</span>.   
* Der Resolver zieht sich den DS-Record von .com, der den Hash des <span style="color:#FF0000;">KSK von .com (öffentlich)</span> enthält.   
* Der Resolver berechnet einen Hash des DS-Records und vergleicht ihn mit der Signatur aus dem RRSIG-Record.   
* Der Resolver zieht sich den RRSIG-Record für den DS-Record, der die Signatur über den DS-Record enthält.   
* Die Signatur des DS-Records wird mit dem öffentlichen <span style="color:#007BFF;">Root-ZSK</span> überprüft. 
* Der Resolver entschlüsselt die Signatur des DS-Records mit dem öffentlichen <span style="color:#007BFF;">Root-ZSK (öffentlich)</span>.   
* Wenn die Signatur gültig ist, ist der DS-Record authentisch.   
* Der Resolver berechnet einen Hash über den DS-Record von .com.   
* Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von .com</span>.
* 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.   
== Validierung der TLD (.com) == 
* Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von .com (öffentlich)</span>.
* Die Root-Zone enthält einen DS-Record für .com. 
* Der DS-Record enthält den Hash des KSK von .com.   
* Der ZSK der Root-Zone signiert diesen DS-Record. 
* Da der Resolver dem ZSK der Root-Zone vertraut, kann er nun auch prüfen, ob der DS-Record für .com korrekt signiert wurde.   
* Falls ja, gilt der DS-Record als authentisch und nicht manipuliert.
 
== Validierung der Second-Level-Domain (example.com) == 
* Der Resolver nutzt nun den DS-Record, um den KSK von .com zu validieren. 
* Er ruft den DNSKEY-Record von .com ab und berechnet den Hash des KSK. 
* Wenn dieser Hash mit dem DS-Record aus der Root-Zone übereinstimmt, ist der KSK von .com authentisch.   
* Der Resolver prüft nun den ZSK von .com, der im DNSKEY-Record von .com enthalten ist. 
* Der KSK von .com signiert den DNSKEY-Record, um den ZSK abzusichern. 
* Wenn die Signatur korrekt ist, vertraut der Resolver nun auch dem ZSK von .com.


== Vertrauen zur Second-Level-Domain ==   
== Vertrauen zur Second-Level-Domain ==   
* Der Resolver kann jetzt alle mit dem ZSK von .com signierten Records validieren.   
=== Die TLD (.com) veröffentlicht den DS-Record für example.com ===  
* Dazu gehört auch der DS-Record für example.com, der in .com gespeichert ist.   
* Die TLD (.com) enthält einen DS-Record für example.com.   
* Dieser DS-Record verweist auf den KSK von example.com.   
* Der DS-Record enthält den Hash des <span style="color:#FF0000;">KSK von example.com (öffentlich)</span>.   
* Der Resolver ruft den DNSKEY-Record von example.com ab und vergleicht den KSK-Hash mit dem DS-Record aus .com.   
* Der <span style="color:#008000;">KSK von .com (privat)</span> signiert diesen DS-Record und erzeugt den zugehörigen RRSIG-Record für den DS-Record. 
* Wenn sie übereinstimmen, ist der KSK von example.com vertrauenswürdig.   
* Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem <span style="color:#007BFF;">KSK von .com (öffentlich)</span> erstellt wurde.   
* Der KSK von example.com signiert den DNSKEY-Record, um den ZSK abzusichern.   
* 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 prüft, ob diese Signatur gültig ist.   
=== Der Resolver zieht sich den RRSIG- und DS-Record ===  
* Wenn ja, kann er nun dem ZSK von example.com vertrauen.
* Der Resolver zieht sich den DS-Record von example.com, der den Hash des <span style="color:#FF0000;">KSK von example.com (öffentlich)</span> 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 <span style="color:#007BFF;">KSK von .com (öffentlich)</span>. 
* 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 <span style="color:#007BFF;">KSK von example.com (öffentlich)</span>.


== Abschluss der Vertrauenskette ==   
== Abschluss der Vertrauenskette ==   
* Der Resolver kann jetzt alle mit dem ZSK von example.com signierten Records validieren.   
=== Die Second-Level-Domain veröffentlicht ihren DNSKEY-Record === 
* Die Second-Level-Domain (example.com) veröffentlicht einen DNSKEY-Record. 
* Dieser enthält den <span style="color:#007BFF;">KSK von example.com (öffentlich)</span> und den <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span>. 
* Der <span style="color:#008000;">KSK von example.com (privat)</span> 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 <span style="color:#007BFF;">KSK von example.com (öffentlich)</span> und den <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span> 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 <span style="color:#007BFF;">KSK von example.com (öffentlich)</span>. 
* 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 <span style="color:#007BFF;">ZSK von example.com (öffentlich)</span>. 
=== Der Resolver kann nun alle mit dem ZSK von example.com signierten Records validieren === 
* Der Resolver nutzt den <span style="color:#007BFF;">ZSK von example.com (öffentlich)</span>, um die Signaturen aller weiteren DNS-Records der Domain zu überprüfen.   
* Dazu gehören A-Records, MX-Records, TXT-Records usw.   
* Dazu gehören A-Records, MX-Records, TXT-Records usw.   
* Wenn die Signaturprüfung erfolgreich ist, gelten diese Records als authentisch und nicht manipuliert.
* 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):
{| class="wikitable"
! 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:
* <pre>dig . DNSKEY +dnssec</pre>
''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:
* <pre>dig de DS +dnssec</pre>
=== 3. Die Delegation zur Domain prüfen ===
Nun prüfen wir den DS-Record für eine spezifische Domain bei der TLD:
* <pre>dig google.de DS +dnssec</pre>
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:
* <pre>dig google.de DNSKEY +dnssec</pre>
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:
* <pre>dig www.google.de A +dnssec</pre>
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:
* <pre>dig google.de +sigchase +trusted-key=./root.key</pre>
''(Hinweis: Je nach dig-Version müssen die Optionen ggf. angepasst werden, modernere Versionen nutzen oft +trace +dnssec)''

Aktuelle Version vom 15. März 2026, 10:12 Uhr

Aufbau

  • Dieses Beitrag enthält eine Rahmenhandlung.

Signierung und Prüfung

sig-test

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)

Abgerufen von „https://wiki.ixheim.de/index.php?title=Vetrauenskette_bei_DNSSEC&oldid=67341“