DNS-Zonen werden auf einem primären (Master) und einem oder mehreren sekundären (Slave) Servern gehostet. Die folgenden Prozeduren (siehe Abbildung 1 ) sind nur auf dem primären DNS-Server notwendig, da der sekundäre Server alle DNSSEC-signierten Zonen lediglich als Read-Only-Kopie erhält. Der primäre Server erstellt für jede Zone einen asymmetrischen Zone Signing Key (ZSK). Der ZSK Private Key signiert alle RRs der Zone und stellt das Ergebnis über RRSIG-Ressource-Records bereit. Der ZSK Public-Key wird in der Zone als DNSKEY-Record bereitgestellt und steht dem DNS-Client somit für die Validierung der Antworten zur Verfügung.
Hier stößt man auf ein Problem: Woher weiß der Client, dass er dem ZSK-Public Key aus der Zone vertrauen kann? Dies stellt ein Key Signing Key (KSK) sicher, den der primäre Server zusätzlich erstellt. Der KSK Private Key wird als "Generalschlüssel" des Servers für die Signatur der einzelnen Zonenschlüssel einer Zone verwendet, die sich aus Sicherheitsgründen regelmäßig ändern können und sollten. Mit dem KSK Public Key können die DNS-Clients diese Signatur überprüfen. Letztlich müssen die Clients also nur dem KSK Public Key vertrauen, um die Signaturen der jeweiligen ZSKs zu validieren. Der KSK Public Key ist also derjenige, der als Trusted Key in der Konfiguration des DNS-Clients eingetragen werden muss.
Bei dem Konzept von KSK und ZSK wird bereits das Prinzip einer Chain-of-Trust (Vertrauenskette) deutlich: Anton vertraut Berta, Berta vertraut Conrad und Conrad vertraut Doris. Damit vertraut Anton ebenfalls Conrad und Doris. Das Vertrauen setzt sich kettenartig fort, Anton muss aber nur einen Vertrauensstatus pflegen, nämlich den zu Berta.
Übertragen auf DNSSEC sieht das folgendermaßen aus: Angenommen, es existiert eine Zone
»avc.local
«
. Diese Zone ist mittels KSK und ZSK signiert. Wird der KSK Public Key auf dem DNS-Client als vertrauenswürdig eingestuft, beginnt nun die Chain-of-Trust. Zonen, die mit ZSKs signiert wurden, die wiederum mit dem vertrauenswürdigen KSK signiert wurden, sind ebenfalls vertrauenswürdig. Doch wie verhält es sich mit delegierten Zonen?
Auch primäre DNS-Server von untergeordneten Zonen, zum Beispiel der Server der Zone
»training.avc.local
«
, verwenden einen langlebigen KSK und entsprechende ZSKs. Um eine Vertrauensverbindung zum jeweiligen KSK des primären Servers der untergeordneten Zone herzustellen, werden in der übergeordneten Zone sogenannte Delegation Signer-Ressource Records (DS-RRs) erstellt. Sie signieren den KSK des untergeordneten Servers mit dem ZSK der übergeordneten Zone – voilà, die Kette hält. Dies kann durch beliebige weitere Unterebenen der DNS-Hierarchie geführt werden (
Abbildung 2
).
Unter dem Strich muss der DNS-Client also nur einem einzigen KSK Public Key vertrauen, dem der obersten Ebene. Im Internet ist das die Root-Zone. In der Vergangenheit waren jedoch auch Insellösungen, sogenannte "Islands of Trust", populär und sind nach wie vor möglich, da der SEP, der Secure Entry Point, beliebig gewählt werden kann ( Abbildung 3 ). Nachteil hierbei ist natürlich, dass jeder einzelnen Insel durch Einfügen des jeweiligen KSKs des SEPs separat vertraut werden muss. Dies erfordert im Zweifel einen hohen administrativen Aufwand zur Schlüsselpflege.