DNSSEC
Ziel von DNSSEC ist es, Authentizitä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 DNSSEC nicht vorgesehen. Da DNS-Informationen grundsätzlich der Öffentlichkeit zur Verfügung gestellt werden, würde eine Verschlüsselung keinen nennenswerten Sicherheitsgewinn bedeuten.
| Inhaltsverzeichnis |
Ü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 privaten Schlüssel (engl: private key). Beliebige Empfänger können diese Unterschrift mit dem öffentlichen Schlüssel (engl: public key) des Besitzers verifizieren und damit Authentizitä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 mehreren zu diesem Namen gehörenden IP-Adressen bzw. einem oder mehreren zu diesem Namen gehörenden Schlüsseln. 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 Schlüssel 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 Paar, bestehend aus öffentlichem und privatem Schlüssel) generiert. Mit dem privaten Schlüssel 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 ist dann sinnvoll, 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 immernoch 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 ist vor allem bei dynamischen Updates sinnvoll.