Domain Name System Security Extensions

DNSSEC im TCP/IP‑Protokollstapel:

Anwendung	DNSSEC
Transport	UDP		TCP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Die Domain Name System Security Extensions (DNSSEC) sind eine Erweiterung des DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden. Ein DNS-Teilnehmer kann damit verifizieren, dass die durch den Server, mit dem er kommuniziert, gelieferten Zonendaten auch tatsächlich identisch mit denen sind, die der für die Zone autorisierte und die Zone signierende Server ausliefert. DNSSEC wurde als Mittel gegen Cache-Poisoning entwickelt, Serverauthentifizierung findet nicht statt.

Eine Verschlüsselung von DNS-Daten ist im Rahmen von DNSSEC nicht vorgesehen.

Überblick

DNSSEC verwendet ein asymmetrisches Kryptosystem. Der „Besitzer“ einer Information – in der Regel der Master-Server, auf dem die abzusichernde Zone liegt – 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 2005 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 einiger Top Level Domains verzichteten bisher auf die Einführung von DNSSEC, da das Problem des Zone Walking noch nicht endgültig gelöst ist und teilweise wegen organisatorischer Probleme.

Am 5. Mai 2010 wurde DNSSEC auf allen 13 Rootservern eingeführt; am 15. Juli wurde der Rootzonenschlüssel veröffentlicht und das DNS damit von der Rootzone aus validierbar.^[1] Die Top Level Domains .arpa, .asia, .biz, .cat, .com, .edu, .gov, .info, .museum, .net, .org, .ag, .be, .bg, .br, .bz, .ch, .co, .cz, .de, .dk, .eu, .fi, .fr, .gi, .gr, .hn, .jp, .la, .lc, .li, .lk, .lu, .me, .mn, .my, .na, .nl, .nu, .pm, .pr, .pt, .re, .sc, .se, .tf, .th, .tm, .uk, .us, .wf, .xn--0zwm56d (.测试), .xn--11b5bs3a9aj6g (.परीक्षा), .xn--80akhbyknj4f (.испытание), .xn--9t4b11yi5a (.테스트), .xn--deba0ad (.טעסט), .xn--g6w251d (.測試), .xn--hgbk6aj7f53bba (.آزمایشی), .xn--hlcj6aya9esc7a (.பரிட்சை), .xn--jxalpdlp (.δοκιμή), .xn--kgbechtv (.إختبار), .xn--zckzah (.テスト) und .yt wurden bisher von der Rootzone signiert,^[2] während die DNSKEYs der TLDs .vc, .xn--fzc2c9e2c (.ලංකා), .xn--xkc2al3hye2a (.இலங்கை) und .cl noch nicht von der Rootzone signiert und somit nicht ohne DNSSEC Lookaside Validation validierbar sind.

Siehe auch: Punycode

Funktionsweise

Besitzer einer DNS-Information ist der für die Zone, in der die Information liegt, autoritative Master-Server. Für jede abzusichernde Zone wird ein eigener Zonenschlüssel (engl.: zone signing key) (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 (Resource Record) 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.example.org.   A       172.27.182.17
                     RRSIG   A 1 3 1000 20060616062444 (
                                        20060517062444 9927 example.org.
                                        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). Das Setzen des DO-Bits ist nur im Rahmen der DNS-Erweiterung EDNS möglich, welche folglich von Resolvern und rekursiven Nameservern unterstützt werden muss. Ebenso ist EDNS für die erheblich umfangreicheren Paketgrößen erforderlich, die bei der Übertragung von Schlüsseln und Signaturen notwendig werden.

Mit einer aktuellen Version des DNS-Werkzeugs dig kann die Authentifizierung von Recource Records vollständig durchgeführt werden ohne einem rekursiven Nameserver zu vertrauen. Zunächst kann der sog. Trust Anchor, also der öffentliche Schlüssel der Rootzone, wie folgt in einer Datei gespeichert werden, er sollte jedoch besser über sichere, vom DNS unabhängige Wege erhalten werden:

dig +nocomments +nostats +nocmd +noquestion -t DNSKEY . > trusted-key.key

Darauf kann unter Verwendung dieses Trust Anchors die Vertrauenskette durchlaufen werden. Die Ausgabe ist sehr lang und instruktiv, hier ist nur der entscheidende letzte Teil dargestellt:

dig +topdown +sigchase +multiline +trusted-key=./trusted-key.key -t A www.ripe.net.

...

;; VERIFYING A RRset for www.ripe.net. with DNSKEY:46566: success

;; The Answer:
www.ripe.net.           166804 IN A 193.0.6.139
 
;; FINISH : we have validate the DNSSEC chain of trust: SUCCESS

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 example.org.
                                mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs
                                g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB
                                uv9aFcPaMyILJg== )
               NSEC    name5  A RRSIG NSEC
               RRSIG   NSEC 1 3 10000 20060616062444 (
                                20060517062444 9927 example.org.
                                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 unterstützt NSEC3 seit Version 9.6, der NSD unterstützt NSEC3 seit Version 3.1.

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 Vertrauensketten (engl.: Chains of Trust) 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 example.org. und die delegierte Subzone filiale1.example.org.. 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 example.org. als Trusted Key bekannt sein muss.

Die höchste Zone example.org. hat den Schlüsselunterzeichnungs-Schlüssel:

  example.org. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk+3Xe...           (gekürzt)

und den Zonen-Schlüssel

  example.org. IN DNSKEY 256 3 1 AQO+/cFBgAR4HbTlBSoP...           (gekürzt)

In example.org existiert ein Delegationspunkt auf die Subzone filiale1.example.org., der mit dem Zonenschlüssel von example.org. signiert ist:

 filiale1   DS      52037 1 1 ( 378929E92D7DA04267EE87E802D75C5CA1B5D280 )
            RRSIG   DS 1 3 1000 20060615115919 (
                                20060516115919 9927 example.org.
                                AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw
                                AeKpbd0uijPe8Q== )                     (gekürzt)

Im DS Record befindet sich ein Hash des Schlüsselunterzeichnungs-Schlüssel der untergeordneten Zone filiale1.example.org..

Die untergeordnete Zone filiale1.example.org. hat den Schlüsselunterzeichnungs-Schlüssel:

 filiale1.example.org. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd...   (gekürzt)

In den Resolvern wird der Schlüsselunterzeichnungs-Schlüssel der höchsten Zone example.org. als Trusted Key manuell eingetragen:

 trusted-keys { "example.org."   257 3 1 "AQOW4333ZLdOH+..."; );  (gekürzt)

Ausblick

Die Sicherung der Nameserverabfragen mittels DNSSEC bietet keine Gewähr, dass die Kommunikation mit der so ermittelten IP-Adresse unverfälscht oder gar verschlüsselt stattfindet. Korruptes Routing könnte beispielsweise Pakete, die an eine mit DNSSEC korrekt ermittelte Ziel-IP-Adresse gesendet werden, an einen falschen Rechner zustellen. Es gibt jedoch Überlegungen nicht nur Zieladressen, sondern auch öffentliche Schlüssel oder Zertifikate für die Kommunikation mit IPsec oder TLS durch DNSSEC gesichert zu verbreiten (siehe Recource Record Typen CERT und IPSECKEY). Damit könnten so verteilte, selbstsignierte Zertifikate in Konkurrenz zu durch Zertifizierungsstellen ausgestellte treten, welche oft nur den Domainnamen des Servers verifizieren.^[3] Da die Resolver-Infrastruktur auf absehbare Zeit DNSSEC nicht verlässlich verfügbar machen wird, gibt es des weiteren Überlegungen die gesamte Vertrauenskette in einem geeigneten Zertifikat abzulegen und von den Anwendungen ähnlich wie Zertifikate von Zertifizierungsstellen verwenden zu lassen. Das Sicherheitsniveau würde dem Vertrauensmodell von DNSSEC entsprechen.^[4]

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.
• Die öffentlichen Schlüssel zur Verifizierung werden ebenfalls über das DNS-System verteilt. Damit ergeben sich Angriffsmöglichkeiten auf die Vertrauensketten. Dies kann verhindert werden, wenn der öffentliche Schlüssel des Vertrauensursprungs (engl.: Trust Anchor) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.
• Mittels DNSSEC Walking kann der Inhalt von Zonen vollständig ausgelesen werden (Gelöst durch NSEC3).
• Da Stubresolver oft 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.

Praktische Probleme

Momentan findet die Schlüsselgenerierung und -verwaltung ausschließlich an zwei US-Standorten statt. Nach Ansicht vieler RIPE-Experten ist ein Standort außerhalb der USA unabdingbar.^[5] Kritiker werfen der ICANN vor, durch die DNSSEC-Schlüsselverwaltung in den USA die Unabhängigkeit des Internets zu gefährden.^[6] Als Signierungspartner hatte die ICANN ausschließlich die amerikanische Firma Verisign vorgesehen.^[7] Das US-amerikanische Department of Homeland Security forderte im selben Jahr, die Schlüsselverwaltung vollständig in die Hände der US-Regierung zu legen.^[8] Diskutiert wurde auch, alternativ die ICANN-Untergruppe Internet Assigned Numbers Authority (IANA) mit der Verwaltung des Root-Schlüssels zu beauftragen. Die US-Regierung untersagte zunächst die Veröffentlichung eines entsprechenden ICANN-Vorschlags.^[9] Die ICANN ist formal unabhängig, die US-Regierung behält sich jedoch nach wie vor die Aufsicht vor.

Politische Entscheidungen musste die ICANN bislang im Rahmen kriegerischer Auseinandersetzungen fällen. So wurde im Rahmen des Afghanistankriegs die Verwaltung der afghanischen Zone ausgesetzt, bis eine neue Regierung an der Macht war. Nord-Koreas Delegation wurde - unter Verweis auf Formfehler - drei Jahre an der Verwaltung ihrer Zone gehindert. Die Betreiber der irakischen Adresszone (.iq) wurden 2006 in den USA wegen Verstößen gegen das Außenhandelsgesetz und der Unterstützung eines Mitglieds der Hamas zu Haftstrafen zwischen fünfeinhalb und sieben Jahren verurteilt, die .iq-Zone blieb lange ohne Verwalter.^[6]

Siehe auch

• DNSCurve
• EDNS

Normen und Standards

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

Einzelnachweise

1. ↑ Heise News: DNSSEC in der Rootzone gestartet
2. ↑ TLD DNSSEC Report der ICANN
3. ↑ DNSSEC + Certs As a Replacement For SSL’s Transport Security
4. ↑ DNSSEC and TLS
5. ↑ Heise News: DNSSEC auf allen Rootservern (6. Mai 2010)]
6. ↑ ^{a b} c't Magazin für Computertechnik 5/2010: Machtfrage - Wer kontrolliert das Internet?
7. ↑ Heise News: IGF: Politische und technische Probleme bei DNSSEC (14. November 2007)
8. ↑ Heise News: Department of Homeland Security will den Masterschlüssel fürs DNS (29. März 2007)
9. ↑ Heise News: VeriSign will DNSSEC-Schlüssel (ein bisschen) teilen (3. Oktober 2008)

Weblinks

• dnssec.net - Bekanntes Portal zu DNSsec (englisch).
• Einführung in Secure DNS (PDF-Datei; 122 kB)
• DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing (PDF-Datei; 68 kB)
• DENIC-Projektplanung zur Bereitstellung einer DNSSEC-Testumgebung (PDF-Datei; 217 kB)
• DNSSEC in 6 Minutes by Alan Clegg, Internet Systems Consortium (PDF-Datei; 315 kB)