Dnssec Ablauf

Anfrage des Clients

• Beispiel: "Gib mir die A-Record-IP für www.dnssec.net."

Anfrage an den Root-Nameserver

• Der Resolver kennt die Antwort nicht und fragt einen Root-Nameserver:

• "Welche Nameserver sind für .net zuständig?"

Antwort des Root-Nameservers

• Enthält NS-Records für .net.
• Enthält DS-Record für .net (falls .net DNSSEC nutzt). (Fragt: Enthält den Hash des Public KSK von .net zur Validierung durch die übergeordnete Zone?)
• Enthält RRSIG für den DS-Record. (Fragt: Diese Signatur wurde mit dem privaten ZSK der Root-Zone erstellt und sichert den DS-Record ab?)

Validierung des DS-Records für .net

Frage des Resolvers

• Resolver fragt nach www.dnssec.net.

Der Root-Nameserver liefert den DS-Record für .net

• Der DS-Record (Delegation Signer) ist ein spezieller DNS-Eintrag, der in der übergeordneten Zone (der Root-Zone) gespeichert ist.
• Er enthält einen kryptografischen Hash (z. B. SHA-256) des öffentlichen Schlüssels (DNSKEY) der .net-Zone.
• Der DS-Record dient als "Vertrauensanker" zwischen der Root-Zone und der .net-Zone und stellt sicher, dass die .net-Zone autoritativ und unverfälscht ist.

Der DS-Record hat eine RRSIG-Signatur

• Der DS-Record ist mit einer RRSIG (Resource Record Signature) signiert.
• Diese Signatur wird mit dem privaten ZSK (Zone Signing Key) der Root-Zone erstellt.
• Die RRSIG enthält Metadaten wie:
  • Den verwendeten Signaturalgorithmus (z. B. RSA/SHA-256).
  • Das Gültigkeitsdatum der Signatur (Start- und Endzeitpunkt).
  • Den Namen des Signers (in diesem Fall die Root-Zone).

Der Resolver nutzt den öffentlichen ZSK der Root-Zone

• Der Resolver (der DNS-Server, der die Anfrage bearbeitet) verwendet den öffentlichen ZSK der Root-Zone, um die RRSIG-Signatur des DS-Records zu überprüfen.
• Der öffentliche ZSK ist im Vorhinein bekannt und wird verwendet, um die Authentizität der Signatur zu bestätigen.

Überprüfung der Signatur

• Der Resolver überprüft die RRSIG-Signatur, indem er:
  • Den Hashwert des DS-Records berechnet.
  • Die Signatur mit dem öffentlichen ZSK der Root-Zone entschlüsselt.
  • Die beiden Werte vergleicht.
• Wenn die Signatur gültig ist:
  • Der DS-Record ist authentisch und wurde nicht manipuliert.
  • Die DNSSEC-Vertrauenskette ist intakt.

Weiterführung der DNSSEC-Kette

• Nach erfolgreicher Validierung des DS-Records fragt der Resolver die .net-Nameserver an.
• Der Resolver fordert den DNSKEY der .net-Zone an, um die Authentizität weiterer DNS-Antworten zu überprüfen.
• Dieser Prozess wiederholt sich für jede Zone in der DNS-Hierarchie, bis die vollständige DNSSEC-Kette validiert ist.

Zusammenfassung

Die Validierung des DS-Records für .net ist ein zentraler Schritt in der DNSSEC-Vertrauenskette. Sie stellt sicher, dass die DNS-Antworten authentisch und nicht manipuliert sind, indem kryptografische Signaturen und öffentliche Schlüssel verwendet werden.

• Der Root-Nameserver hat den DS-Record für .net geliefert.
• Dieser DS-Record hat eine RRSIG-Signatur, die mit dem privaten ZSK der Root-Zone signiert wurde.
• Der Resolver nutzt jetzt den verifizierten Public ZSK der Root-Zone, um diese Signatur zu überprüfen.
• Dazu entschlüsselt er die RRSIG-Signatur mit dem Public ZSK der Root-Zone.
• Der Resolver berechnet anschließend den Hash des DS-Records für .net und vergleicht ihn mit dem entschlüsselten Wert.
• Falls beide übereinstimmen:

 * Die Signatur ist gültig.
 * Der DS-Record ist echt und wurde nicht manipuliert.
 * Die DNSSEC-Kette kann weitergehen, und der Resolver fragt jetzt die .net-Nameserver.

• Der Resolver hat den **DS-Record für .net** mit einer RRSIG-Signatur erhalten.
• Die **RRSIG-Signatur wurde mit dem privaten ZSK der Root-Zone signiert**.
• Der Resolver **nimmt den Public ZSK der Root-Zone**, den er zuvor validiert hat.
• Er **entschlüsselt die RRSIG-Signatur mit dem Public ZSK**.
• Danach berechnet er den **Hash des DS-Records für .net** und vergleicht ihn mit dem entschlüsselten Hash aus der RRSIG-Signatur.
• Falls beide übereinstimmen:

 * **Die Signatur ist gültig.**
 * **Der DS-Record für .net ist echt und wurde nicht manipuliert.**
 * **Die DNSSEC-Kette kann weitergehen, und der Resolver fragt jetzt die .net-Nameserver.**

• Der Root-Nameserver hat den DS-Record für .net geliefert.
• Dieser DS-Record hat eine RRSIG-Signatur, die mit dem privaten ZSK der Root-Zone signiert wurde.
• Der Resolver nutzt jetzt den verifizierten Public ZSK der Root-Zone, um diese Signatur zu überprüfen.
• Falls die Signatur gültig ist:

 * Der DS-Record ist echt.
 * Die DNSSEC-Kette kann weitergehen, und der Resolver fragt jetzt die .net-Nameserver.

• Dazu braucht er den Public ZSK der Root-Zone.
• Falls er den ZSK nicht gecached hat, fragt er die DNSKEYs der Root-Zone ab.

Abfrage der Root-DNSKEYs

• "Gib mir die DNSKEYs für . (Root)."

Antwort des Root-Nameservers

• Public KSK (Trust Anchor ist bereits gespeichert).
• Public ZSK.
• RRSIG über die DNSKEYs (signiert mit dem privaten KSK).

Validierung der DNSKEYs

• Der Resolver hat die DNSKEYs der Root-Zone erhalten (Public KSK und Public ZSK).
• Die DNSKEYs haben eine RRSIG-Signatur, die mit dem privaten KSK der Root-Zone signiert wurde.
• Der Resolver prüft diese Signatur mit dem Public KSK (Trust Anchor), den er bereits gespeichert hat.
• Falls die Signatur gültig ist:

 * Der Public ZSK der Root-Zone ist authentisch und kann jetzt verwendet werden.

• Er prüft die RRSIG der DNSKEYs mit dem Public KSK (Trust Anchor).
• Ist die Signatur gültig? → Public ZSK ist authentisch.

Validierung des DS-Records für .net

• Falls die Signatur gültig ist, geht die Namensauflösung weiter.

Anfrage an die .net-Nameserver

• "Welche Nameserver sind für dnssec.net autoritativ?"

Antwort der .net-Nameserver

• Enthält NS-Records für dnssec.net.
• Enthält DS-Record für dnssec.net. (Fragt: Enthält den Hash des Public KSK von dnssec.net zur Validierung durch die übergeordnete Zone?)
• Enthält RRSIG für den DS-Record von dnssec.net. (Fragt: Diese Signatur wurde mit dem privaten ZSK der .net-Zone erstellt und sichert den DS-Record ab?)

Validierung des DS-Records für dnssec.net

• Dazu braucht er den Public ZSK der .net-Zone.
• Falls er den ZSK nicht gecached hat, fragt er die DNSKEYs der .net-Zone ab.

Abfrage der .net-DNSKEYs

Der Resolver fragt den .net-Nameserver:

• "Gib mir die DNSKEYs für dnssec.net."

Antwort des .net-Nameservers

Der .net-Nameserver liefert die DNSKEYs:

• Public KSK von dnssec.net.
• Public ZSK von dnssec.net.
• RRSIG über die DNSKEYs (signiert mit dem privaten KSK von dnssec.net).

Validierung der DNSKEYs von dnssec.net

Der Resolver validiert die DNSKEYs:

• Er prüft die RRSIG der DNSKEYs mit dem Public KSK der .net-Zone.
• Ist die Signatur gültig? → Public ZSK von dnssec.net ist authentisch.

Validierung des DS-Records für dnssec.net

Der Resolver validiert den DS-Record von dnssec.net mit dem Public ZSK der .net-Zone:

• Falls die Signatur gültig ist, geht die Namensauflösung weiter.

Anfrage an die dnssec.net-Nameserver

Der Resolver fragt einen der dnssec.net-Nameserver:

• "Gib mir den A-Record für www.dnssec.net."

Antwort der dnssec.net-Nameserver

Der dnssec.net-Nameserver liefert:

• A-Record für www.dnssec.net.
• RRSIG für den A-Record (signiert mit dem privaten ZSK von dnssec.net).

Validierung des A-Records

Der Resolver validiert die Antwort:

• Er prüft die RRSIG des A-Records mit dem Public ZSK von dnssec.net.
• Falls die Signatur gültig ist, gibt er die IP-Adresse an den Client zurück.

Abschluss der DNSSEC-Validierung

Der Resolver hat alle Signaturen überprüft und gibt die verifizierte Antwort an den anfragenden Client zurück.