Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Gezeichnet, DNS

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.

Abbildung 1: Prinzipieller Ablauf der Signaturen von privaten und öffentlichen Schlüsseln.

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?

Die Kette setzt sich fort

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 ).

Abbildung 2: Die hierarchische Struktur erfordert nur das Vertrauen in den KSK Public Key, das dann über Delegation Signer Ressource Records weitergereicht wird.

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.

Abbildung 3: Sichere Inseln innerhalb der prinzipiell unsicheren DNS-Hierarchie.
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023