Vetrauenskette bei DNSSEC: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 1: Zeile 1:
=Ablauf in DNSSEC=
+
==Ablauf in DNSSEC==
 
+
===Der Nameserver signiert den A-Record===
* Der Nameserver signiert den A-Record:
+
* 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 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).
+
* Dieser Hash wird mit dem privaten ZSK signiert.
** Dieser Hash wird mit dem privaten ZSK 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.
+
=Der Resolver überprüft die Signatur=
 
+
* Der Resolver erhält den A-Record und die dazugehörige RRSIG-Signatur.
* Der Resolver überprüft die Signatur:
+
* Der Resolver berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der Nameserver).
** Der Resolver erhält den A-Record und die dazugehörige RRSIG-Signatur.
+
* 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 berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der Nameserver).
+
* Der Resolver vergleicht den entschlüsselten Wert der Signatur mit dem von ihm selbst berechneten Hash des A-Records.
** Der Resolver zieht den DNSKEY-Record (der den öffentlichen ZSK enthält) und verwendet den öffentlichen ZSK, um die RRSIG-Signatur zu entschlüsseln.
+
* Wenn beide Werte übereinstimmen, bedeutet dies, dass der A-Record authentisch ist und nicht manipuliert wurde.
** Der Resolver vergleicht den entschlüsselten Wert der Signatur mit dem von ihm selbst berechneten Hash des A-Records.
+
'''Wie kann der Resolver dem autoritativen Nameserver vertrauen?'''
** 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 <span style="color:#007BFF;">Root-KSK</span> als Trust Anchor.   
 
* Der Resolver kennt den <span style="color:#007BFF;">Root-KSK</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</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:#FF0000;">Root-ZSK</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:#FF0000;">Root-ZSK</span> (Zone Signing Key der Root-Zone) signiert alle anderen Records in der Root-Zone (z. B. den DS-Record für .com).   
Zeile 27: Zeile 22:
 
* 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</span> und den <span style="color:#007BFF;">Root-KSK</span> enthält.   
Zeile 36: Zeile 30:
 
* 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</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.   
Zeile 45: Zeile 37:
 
* 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</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 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</span> und den <span style="color:#007BFF;">Root-KSK</span> enthält.   
Zeile 54: Zeile 45:
 
* 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</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.   
Zeile 64: Zeile 52:
 
* 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</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</span> enthält.   
Zeile 73: Zeile 60:
 
* Wenn die Signatur gültig ist, ist der DS-Record authentisch.   
 
* Wenn die Signatur gültig ist, ist der DS-Record authentisch.   
 
* Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von example.com</span>.
 
* Der Resolver vertraut nun dem <span style="color:#007BFF;">KSK von example.com</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.   
Zeile 81: Zeile 66:
 
* Der <span style="color:#007BFF;">KSK von example.com</span> signiert den gesamten DNSKEY-Record der Second-Level-Domain und erzeugt den zugehörigen RRSIG-Record.   
 
* Der <span style="color:#007BFF;">KSK von example.com</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</span> und den <span style="color:#FF0000;">ZSK von example.com</span> enthält.   

Version vom 18. März 2025, 21:24 Uhr

Ablauf in DNSSEC

Der Nameserver signiert den A-Record

  • 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).
  • Dieser Hash wird mit dem privaten ZSK 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 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

  • Der Resolver kennt den Root-KSK als Trust Anchor.
  • Dieser Root-KSK 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 (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 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.
  • 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 und den Root-KSK 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.
  • 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.

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.
  • Der Root-ZSK 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 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 DNSKEY-Record

  • Der Resolver zieht sich den DNSKEY-Record der Root-Zone, der den Root-ZSK und den Root-KSK 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.
  • 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.

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.
  • Der KSK von .com 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 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 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 überprüft den DS-Record von example.com mit dem KSK von .com.
  • Der Resolver berechnet einen Hash des DS-Records und vergleicht ihn mit der Signatur aus dem RRSIG-Record.
  • Die Signatur des DS-Records wird mit dem öffentlichen KSK von .com überprüft.
  • Wenn die Signatur gültig ist, ist der DS-Record authentisch.
  • Der Resolver vertraut nun dem KSK von example.com.

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 und den ZSK von example.com.
  • Der KSK von example.com 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 und den ZSK von example.com 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.
  • 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.

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

  • Der Resolver nutzt den ZSK von example.com, 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.