- DNS Security Extensions
-
DNSSEC im TCP/IP‑Protokollstapel: Anwendung DNSSEC Transport UDP TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token
BusToken
RingFDDI … Domain Name System Security Extensions (kurz DNSSEC) ist eine Erweiterung von DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden. Ein DNS-Teilnehmer kann damit verifizieren, 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 asymmetrisches Kryptosystem. Der "Besitzer" einer Information – in der Regel der Master-Server, auf dem die abzusichernde Zone abliegt – unterzeichnet jeden einzelnen Record mittels seines geheimen Schlüssels (engl. private key). DNS-Clients können diese Unterschrift mit dem öffentlichen Schlüssel (engl. public key) des Besitzers validieren und damit Authentizität und Integrität überprüfen.
Die ursprüngliche, im RFC 2535 definierte DNSSEC-Version, erwies sich in der Praxis aufgrund einer zu aufwändigen Schlüsselverwaltung als untauglich. Die Verbreitung von DNSSEC verzögerte sich dadurch um mehrere Jahre, bis 2004 eine komplette Neufassung veröffentlicht wurde. Um Inkompatibilitäten mit bestehender Software auszuschließen, wurden neue Resource Record Typen eingeführt (RRSIG ersetzt SIG, DNSKEY ersetzt KEY, NSEC ersetzt NXT). Im Oktober 2005 wurde mit der schwedischen SE-Domain erstmals eine Top Level Domain digital unterschrieben. Ab diesem Zeitpunkt gilt DNSSEC als eingeführter Standard. Die Verantwortlichen anderer Top Level Domains verzichteten bisher auf die Einführung von DNSSEC, da das Problem des Zone Walking noch nicht endgültig gelöst ist, weil die root-Zone nicht signiert ist und teilweise wegen organisatorischer Probleme.
Bisher wurde DNSSEC in den ccTLDs .bg, .br, .cz, .pr, .se und .gov eingeführt.
Funktionsweise
Besitzer einer DNS-Information ist der für die Zone, in der die Information abliegt, autoritative Master-Server. Für jede abzusichernde Zone wird ein eigener Zonenschlüssel (ein Paar, bestehend aus öffentlichem und privatem Schlüssel) generiert. Der öffentliche Teil des Zonenschlüssels wird als DNSKEY Resource Record in die Zonendatei aufgenommen. Mit dem privaten Schlüssel wird jeder einzelne RR dieser Zone digital unterschrieben. Dazu wird ein neuer RR-Typ bereitgestellt, der RRSIG Resource Record, der die Signatur zum zugehörenden DNS-Eintrag enthält. Beispiel eines signierten A-Records:
nsf.f-beispiel.de. A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 ( 20060517062444 9927 f-beispiel.de. mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB uv9aFcPaMyILJg== )
Bei jeder Transaktion wird neben dem eigentlichen Resource Record auch der zugehörige RRSIG-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 dann anhand des öffentlichen Zonen-Schlüssels die Signatur validieren.Ein Resource Record (genauer: ein Resource Record Set – also 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 (auch "Key Tag" genannt), unterschieden. Eine DNSSEC Digitale Unterschrift enthält außerdem das Datum, ab dem sie gültig ist sowie ein Enddatum, ab dem sie ihre Gültigkeit verliert.
Um das Keymanagement zu erleichtern, wurde zusätzlich zum Zonenschlüssel ein syntaktisch identischer Schlüsselunterzeichnungs-Schlüssel (engl.: key signing key) definiert, mit dem ausschließlich Zonenschlüssel unterschrieben werden. Ein derartiger Schlüsselunterzeichnungs-Schlüssel wird für die Bildung von Vertrauens-Ketten (engl.: chains of trust) verwendet und zusätzlich in der übergeordneten Zone abgelegt. Im Gegensatz zum häufig erneuerten Zonenschlüssel besitzt er eine lange Lebensdauer.
Auswertung durch Resolver
Herkömmliche DNS-Resolver (in der DNS-Terminologie Stubresolver genannt) sind gewöhnlich nicht in der Lage, digital unterschriebene DNS-Records zu validieren. Nach der zurzeit dominierenden DNS-Philosophie sind Resolver sehr einfach aufgebaute Programme, die mit komplexen DNSSEC-Operationen überfordert wären. Stattdessen werden die DNSSEC-Funktionen in einem zentralen – meist lokalen – rekursiven Nameserver gehalten, der über einen leistungsfähigen Resolver verfügt. Ein Client, der einen Namen auflösen möchte, sendet eine entsprechende Anfrage an diesen zentralen Server. Durch Setzen des DO-Bits (DNSSEC OK) im DNS-Header teilt er mit, dass authentifiziert werden soll. Bei erfolgreicher Authentifizierung setzt der zentrale Server in der Antwort das AD-Bit (Authenticated Data).
Nicht-existierende Namen
Mit DNSSEC ist es auch möglich zu beweisen, dass ein bestimmter Name nicht existiert. Zu diesem Zweck werden beim Signieren einer Zonendatei alle Einträge alphabetisch geordnet und über einen NSEC Resource Record verkettet. Der letzte Name zeigt dabei auf den ersten, so dass eine ringförmige Kette entsteht. Beispiel: name1->name2, name2->name5, name5->name1. Zu jedem Namen existiert damit genau ein NSEC-Record, der ebenfalls signiert wird. Wird jetzt von einem Resolver beispielsweise der nicht existierende name3 angefragt, so liefert der Nameserver eine negative Antwort und zusätzlich den NSEC Record name2->name5. Da dieser NSEC signiert ist, kann der Resolver sicher sein, dass sich zwischen name2 und name5 kein weiterer Eintrag befindet und damit name3 nicht existiert. Beispiel:
name2 A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 ( 20060517062444 9927 f-beispiel.de. mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB uv9aFcPaMyILJg== ) NSEC name5 A RRSIG NSEC RRSIG NSEC 1 3 10000 20060616062444 ( 20060517062444 9927 f-beispiel.de. vlDpyqQF8b6VEtRRt5dZd+R2IVonLaJvpr6n 5flYJ90JYtaiwhPIQGsp44BH0pvcBCt9e/eD QoBh4eGjbW49Yw== )
Die Verkettung aller Records einer Zone ermöglicht es, den gesamten Inhalt per Zone Walking iterativ auszulesen. Damit werden einem Angreifer unter Umständen sicherheitsrelevante Informationen offenbart. Im März 2008 wurde mit RFC5155 der NSEC3-Eintrag definiert, der anstelle von Hostnamen im Klartext nur gehashte Namen zurückliefert und so das Zone Walking-Problem löst. Erste Implementierungen sind schon verfügbar, BIND wird noch folgen.Chain of Trust
Um eine sichere Authentifizierung zu gewährleisten, muss der Public Key einer Zone (bzw. dessen Fingerprint) 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 Chains of Trust (engl.: Vertrauensketten) 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 (engl.: Island of Security) bezeichnet. Im Idealfall existiert nur eine einzige derartige Island of Security für den gesamten Namensraum und damit nur ein einziger Trusted Key. Für die Bildung von Vertrauensketten werden DS Resource Records verwendet. Ein im DS Resource Record definierter Schlüssel (genauer: Ein Hash oder Fingerprint eines Schlüssels) entspricht dem Schlüsselunterzeichner-Schlüssel der untergeordneten Zone.
Durch die Bildung von Chains of Trust vereinfacht sich zwar die Schlüsselverwaltung beträchtlich, die Resolver müssen aber im ungünstigsten Fall die Kette von unten bis zur obersten Zone durchlaufen und eine Vielzahl von kryptographischen Operationen ausführen. Beispiel:
Es existieren zwei Zonen: die übergeordnete Zone f-beispiel.de und die delegierte Subzone filiale1.f-beispiel.de. Beide Zonen sind über einen DS-Record zu einer Chain of Trust verbunden, so dass im Resolver des zentralen Nameservers nur der Schlüssel der obersten Zone f-beispiel.de als Trusted Key bekannt sein muss. Die höchste Zone f-beispiel.de hat den Schlüsselunterzeichnungs-Schlüssel: f-beispiel.de. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk+3Xe... (gekürzt) und den Zonen-Schlüssel f-beispiel.de. IN DNSKEY 256 3 1 AQO+/cFBgAR4HbTlBSoP... (gekürzt)In f-beispiel.de existiert ein Delegationspunkt auf die Subzone filiale1.f-beispiel.de, der mit dem Zonenschlüssel von f-beispiel.de signiert ist: filiale1 DS 52037 1 1 ( 378929E92D7DA04267EE87E802D75C5CA1B5D280 ) RRSIG DS 1 3 1000 20060615115919 ( 20060516115919 9927 f-beispiel.de. AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw AeKpbd0uijPe8Q== ) (gekürzt) Im DS Record befindet sich ein Hash des Schlüsselunterzeichnungs-Schlüssel der untergeordneten Zone filiale1.f-beispiel.de.Die untergeordnete Zone filiale1.f-beispiel.de hat den Schlüsselunterzeichnungs- Schlüssel: filiale1.f-beispiel.de. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd... (gekürzt)In den Resolvern wird der Schlüsselunterzeichnungs-Schlüssel der höchsten Zone f-beispiel.de als Trusted Key manuell eingetragen: trusted-keys { "f-beispiel.de." 257 3 1 "AQOW4333ZLdOH+..."; ); (gekürzt)Sicherheitsrelevante Schwachstellen von DNSSEC
- Denial-of-Service-Attacken werden durch DNSSEC nicht verhindert sondern auf Grund des höheren Rechenaufwands auf den Servern sogar erleichtert.
- Das Verteilen der Schlüssel zur Bildung von Chains of Trust muss manuell erfolgen und bietet damit Angriffspunkte.
- Mittels DNSSEC Walking kann der Inhalt von Zonen vollständig ausgelesen werden.
- Da Stubresolver nicht selbst die DNS-Antworten validieren, kann ein Angriff auf der Kommunikationsstrecke zu ihrem rekursiven Nameserver erfolgen. Auch kann der rekursive Nameserver selbst kompromittiert sein.
Siehe auch
Quellen
- DNSSEC Delegation Signer (RFC 3658 (obsolete))
- DNSSEC Intro RFC (RFC 4033)
- DNSSEC Records RFC (RFC 4034)
- DNSSEC Protocol RFC (RFC 4035)
- DNSSEC Deployment Initiative (Dot-GOV is first signed gTLD)
Weblinks
Wikimedia Foundation.
