Domain Name System Security Extensions
Ziel von DNSSEG ist es, Authentität von DNS-Servern sicherzustellen und die Datenintegrität bei Transaktionen zu gewährleisten. Ein DNS-Teilnehmer soll damit verifizieren können, dass der Server, mit dem er kommuniziert auch tatsächlich der ist, der er vorgibt zu sein und dass empfangene DNS-Nachrichten auf dem Transportweg nicht verfälscht wurden.
Eine Verschlüsselung von DNS-Daten ist in Rahmen von DNSSEG nicht vorgesehen. Da DNS-Informationen grundsätzlich der Öffentlichkeit zur Verfügung gestellt werden, würde eine Encryption keinen nennenswerten Sicherheitsgewinn bedeuten.
Überblick
DNSSEC verwendet ein Public Key Verfahren. Der Besitzer einer Information - in der Regel der Master-Server, auf dem der abzusichernde DNS-RR abliegt - unterzeichnet diesen mit seinem Private Key. Beliebige Empfänger können diese Unterschrift mit dem Publik Key des Besitzers verifizieren und damit Authentität und Integrität überprüfen.
DNSSEC besteht aus drei voneinander unabhängigen Funktionsblöcken:
- Public Key Propagierung
- Authentifizierung des Besitzers und Sicherung der Daten-Integrität
- Transaktionssicherung
Public Key Propagierung
Mit der DNS Public Key Propagierung können Öffentliche Schlüssel propagiert werden. Das ganze funktioniert analog zur Publizierung einer IP-Adresse. Ein Resolver sendet per DNS-Request einen Namen zu einem Server und der Server antwortet mit einer oder mehrereren zu diesem Namen gehörenden IP-Adressen bzw. einem oder mehreren zu diesem Namen gehörenden Public Keys. Anstelle eines A Resource Record, wird zur Speicherung eines Öffentlichen Schlüssels ein KEY Resource Record verwendet.
Die Public Key Propagierung beschränkt sich nicht auf Öffentliche Schlüssel von DNS-Teilnehmern. Es können auch Keys anderer Systeme verwaltet werden. Umgekehrt muss ein DNS-Teilnehmer, der einen Öffentlichen Schlüssel benötigt, diesen nicht unbedingt per DNS holen. Er kann manuell in einen Resolver eingebracht oder von einem LDAP-Server erfragt werden.
Authentifizierung des Besitzers und Sicherung der Datenintegrität
Besitzer einer DNS-Information ist der für die Zone, in der die Information abliegt, autoritative Master. Für jede abzusichernde Zone wird ein eigener Zonenschlüssel (ein Pärchen, bestehend aus Private Key und Public Key) generiert. Mit dem Private Key wird jeder einzelne RR dieser Zone digital unterschrieben. Dazu wird ein neuer RR-Typ bereitgestellt, der SIG Resource Record.
Bei jeder Transaktion wird neben dem eigentlichen Resource Record auch der zugehörige SIG-RR mitgeliefert. Beim Zonentransfer erhalten ihn die Slaves, bei rekursiver Auflösung wird er im Cache gespeichert. Zu guter letzt landet er beim anfragenden Resolver. Dieser kann ihn dann an Hand des Öffentlichen Schlüssels verifizieren.
Ein Resource Record (genauer: ein Resource Record Set - als ein Satz von RRs gleichen Typs und Namens) kann auch mehrfach (mit verschiedenen Schlüsseln) unterschrieben werden. Das macht dann Sinn, wenn die Gültigkeit eines Schlüssels bald ablaufen wird und man frühzeitig einen Nachfolger publizieren möchte. Die Schlüssel werden durch eine eindeutige Nummer, die Key ID, unterschieden. Eine DNSSEC Digitale Unterschrift enthält außerdem das Datum, ab dem sie gültig ist sowie ein Endedatum, ab dem sie ihre Gültigkeit verliert.
Transaktionssicherung
Mit dem im vorherigen Abschnitt beschriebenen Verfahren kann sichergestellt werden, dass eine von einem Server empfangene Antwort auf einen DNS-Request unverfälscht ist und vom zuständigen Zonen-Master stammt. Es ist aber immer noch möglich, dass die Header-Felder in der DNS-Antwort (DNS-Reply) auf dem Transportweg manipuliert werden.
Transaktionssicherheit wird dadurch erreicht, dass an die DNS-Antwort ein SIG-RR angehängt wird, der die ursprüngliche Anfrage und die Antwort gemeinsam unterschreibt. Durch SIG-RRs können auch DNS-Anfragen (Requests) unterschrieben werden. Das macht vor allem bei dynamischen Updates Sinn.