Dnssec Grundprintzip

Schaubild

[Bearbeiten]

Root Nameserver

• Die Root Nameserver haben ein privaten und einen öffentlichen KSK
• Diese KSKs werden turnusmässig erneuert

Toplevel Domainnameserver

• Die Toplevel Domainnameserver haben ein privaten und einen öffentlichen KSK
• Diese KSKs werden vom Root Nameserver signiert
• Dies bedeutet er verschlüsselt den öffentlichen KSK des Toplevel Domainservers mit seinem privaten KSK.
• Der Rootnameserver führt nun den öffentlichen Schlüssel Toplevel Domainservers und diese Signature als Records,

Secondlevel Domainnameserver

• Die Secondlevel Domainnameserver haben ein privaten und einen öffentlichen KSK
• Diese KSKs werden vom Toplevel Nameserver signiert.
• Dies bedeutet er verschlüsselt den öffentlichen KSK des Secondlevel Domainservers mit seinem privaten KSK.
• Der Toplevel Nameserver führt nun den öffentlichen Schlüssel des Secondlevel Domainservers und diese Signature als Records,

Chain of Trust

• Um eine sichere Authentifizierung zu gewährleisten, muss der Public Key einer Zone in den zentralen Server, der den Namen auflösen soll, manuell eingebracht werden.
• Da normalerweise jede Zone einen anderen Schlüssel besitzt, der sich zudem regelmäßig ändert, kann die Schlüsselverwaltung sehr aufwändig werden.
• Die Bildung von Vertrauensketten (engl.: Chains of Trust) erleichtert das Keymanagement dramatisch.
• Eine möglichst hoch im DNS-Baum angesiedelte Zone enthält die Public Keys ihrer delegierten Subzonen und unterschreibt diese digital.
• Die Subzonen können wiederum die signierten Public Keys ihrer untergeordneten Zonen enthalten usw.
• Für eine derartige Chain of Trust muss im Resolver eines zentralen Nameservers lediglich der Public Key der obersten Zone bekannt sein.
• Die Gesamtmenge der durch einen einzigen Schlüssel gesicherten Menge von Zonen wird auch als Sicherheitsinsel.

Wir wird nun das Vertrauen gebildet?

Signierung

• Jede Zone in DNSSEC verfügt über ein Zone-Signing Key-Paar (ZSK)
• Der private Teil des Schlüssels führt eine digitale Signatur für jedes RRset in der Zone durch.
• Der öffentliche Teil verifiziert die Signatur.
• Gleichartige Records werden gemeinsam signiert.

[Bearbeiten]

Übertragung

• Der Zonenbetreiber muss auch seinen öffentlichen ZSK verfügbar machen, indem er ihn in einem DNSKEY-Eintrag zu seinem Nameserver hinzufügt.
• Wenn nun ein Resolver einen Record-Typen angfragt, übergibt der Nameserver auch den öffentlichen Schlüssel des ZSK.

[Bearbeiten]

Verifizierung

• Wenn nun die Prüfsumme gleich dem RRSet ist, ist der RRSet authentisch.

[Bearbeiten]

[Bearbeiten]

Woher wissen wir das der Public-Key der ZSK nicht gefälscht ist?

[Bearbeiten]