Vetrauenskette bei DNSSEC: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| (16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 6: | Zeile 6: | ||
=== Der Nameserver signiert den A-Record === | === 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). | * 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 | + | * 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. | * 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 schickt dann den A-Record zusammen mit der RRSIG-Signatur an den Resolver. | ||
| Zeile 13: | Zeile 13: | ||
* Der Resolver erhält den A-Record und die dazugehörige RRSIG-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 berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der autoritative Nameserver). | ||
| − | * Der Resolver zieht den DNSKEY-Record, der den <span style="color:#FF0000;">ZSK von example.com öffentlich</span> enthält. | + | * Der Resolver zieht den DNSKEY-Record, der den <span style="color:#FF0000;">ZSK von example.com (öffentlich)</span> enthält. |
| − | * Der Resolver entschlüsselt die RRSIG-Signatur mit dem | + | * 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. | * 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. | * 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? == | == 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</span> aufzubauen. | + | *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>. |
| − | *Schlüssel, denen wir vertrauen, sind <span style="color:#007BFF;">blau</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>. | ||
== Startpunkt der Vertrauenskette == | == Startpunkt der Vertrauenskette == | ||
| − | * Der Resolver kennt den <span style="color:#007BFF;">Root-KSK</span> als Trust Anchor. | + | * Der Resolver kennt den <span style="color:#007BFF;">Root-KSK (öffentlich)</span> als Trust Anchor. |
| − | * Dieser <span style="color:#007BFF;">Root-KSK</span> 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 <span style="color:# | + | * 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 <span style="color:#007BFF;">Root-KSK</span> signiert den gesamten DNSKEY-Record, der sowohl den <span style="color:#007BFF;">Root-KSK</span> als auch den <span style="color:#FF0000;">Root-ZSK</span> enthält. | + | * 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. |
* 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 zieht sich den DNSKEY-Record der Root-Zone, der den <span style="color:#FF0000;">Root-ZSK</span> und den <span style="color:#007BFF;">Root-KSK</span> enthält. | + | * 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 zieht sich den RRSIG-Record für den DNSKEY-Record, der die Signatur über den gesamten DNSKEY-Record 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;">Root-KSK</span>. | + | * Der Resolver entschlüsselt die Signatur des DNSKEY-Records mit dem öffentlichen <span style="color:#007BFF;">Root-KSK (öffentlich)</span>. |
* Der Resolver berechnet einen Hash über den DNSKEY-Record der Root-Zone. | * 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. | * 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. | * Wenn beide übereinstimmen, ist der DNSKEY-Record der Root-Zone authentisch. | ||
| − | * Der Resolver vertraut nun dem <span style="color:#007BFF;">Root-ZSK</span>. | + | * 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:#FF0000;">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:# | + | * 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 zieht sich den DS-Record von .com, der den Hash des <span style="color:#FF0000;">KSK von .com</span> enthält. | + | * 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 zieht sich den RRSIG-Record für den DS-Record, der die Signatur über den DS-Record 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 <span style="color:#007BFF;">Root-ZSK</span>. | + | * Der Resolver entschlüsselt die Signatur des DS-Records mit dem öffentlichen <span style="color:#007BFF;">Root-ZSK (öffentlich)</span>. |
* Der Resolver berechnet einen Hash über den DS-Record von .com. | * 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. | * 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. | * Wenn beide übereinstimmen, ist der DS-Record von .com authentisch. | ||
| − | * Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von .com</span>. | + | * Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von .com (öffentlich)</span>. |
== Vertrauen zur Second-Level-Domain == | == Vertrauen zur Second-Level-Domain == | ||
=== Die TLD (.com) veröffentlicht den DS-Record für example.com === | === Die TLD (.com) veröffentlicht den DS-Record für example.com === | ||
* Die TLD (.com) enthält einen 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 <span style="color:#FF0000;">KSK von example.com</span>. | + | * Der DS-Record enthält den Hash des <span style="color:#FF0000;">KSK von example.com (öffentlich)</span>. |
| − | * Der <span style="color:# | + | * 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. |
| − | * Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem <span style="color:#007BFF;">KSK von .com</span> erstellt wurde. | + | * Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem <span style="color:#007BFF;">KSK von .com (öffentlich)</span> 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. | * 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 RRSIG- und DS-Record === | ||
| − | * Der Resolver zieht sich den DS-Record von example.com, der den Hash des <span style="color:#FF0000;">KSK von example.com</span> enthält. | + | * 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 zieht sich den RRSIG-Record für den DS-Record, der die Signatur über den DS-Record enthält. | ||
| − | * Der Resolver entschlüsselt | + | * 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 berechnet einen Hash des DS-Records. |
| − | * Wenn beide übereinstimmen, ist der DS-Record von .com authentisch. | + | * Der Resolver vergleicht diesen berechneten Hash mit dem entschlüsselten Wert aus dem RRSIG-Record. |
| − | * Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von example.com</span>. | + | * 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 == | ||
=== Die Second-Level-Domain veröffentlicht ihren DNSKEY-Record === | === Die Second-Level-Domain veröffentlicht ihren DNSKEY-Record === | ||
* Die Second-Level-Domain (example.com) veröffentlicht einen 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</span> und den <span style="color:#FF0000;">ZSK von example.com</span>. | + | * 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:# | + | * 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 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 ü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</span> und den <span style="color:#FF0000;">ZSK von example.com</span> enthält. | + | * 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 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</span>. | + | * 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 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. | * 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. | * 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</span>. | + | * 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 kann nun alle mit dem ZSK von example.com signierten Records validieren === | ||
| − | * Der Resolver nutzt den <span style="color:#007BFF;">ZSK von example.com</span>, um die Signaturen aller weiteren DNS-Records der Domain zu überprüfen. | + | * 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
![Bearbeiten](javascript:editDrawio("517393352", "sig-test.drawio.png", "png", false, false, false, true, "https://embed.diagrams.net")){kind=link}
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)