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 Reihe von Internetstandards, die das Domain Name System (DNS) um Sicherheitsmechanismen zur Gewährleistung der Authentizität und Integrität der Daten erweitern. Ein DNS-Teilnehmer kann damit verifizieren, dass die erhaltenen DNS-Zonendaten auch tatsächlich identisch sind mit denen, die der Ersteller der Zone autorisiert hat. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt. Es sichert die Übertragung von Resource Records durch digitale Signaturen ab. Eine Authentifizierung von Servern oder Clients findet nicht statt.

Vertraulichkeit ist bei DNSSEC nicht vorgesehen, DNS-Daten werden daher nicht verschlüsselt.

Ü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. DNSSEC setzt die Erweiterung EDNS voraus, mit der in DNS-Nachrichten zusätzliche Parameter übertragen werden können. Des Weiteren hebt EDNS die Größenbeschränkung von DNS-Nachrichten über UDP von 512 Bytes auf. Zur Übertragung von Schlüsseln und Signaturen sind erheblich längere DNS-Nachrichten erforderlich.

Die ursprüngliche, März 1999 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. Die Verantwortlichen einiger anderer Top-Level-Domains, so auch von .de, warteten auf eine Lösung des Zone Walkings und offenen organisatorischen Fragen. Mit der Einführung des NSEC3 Resource Records im März 2008 galt Zone Walking als hinreichend erschwert.

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. Etwa 100 Top-Level-Domains sind mit DNSSEC signiert und die meisten von ihnen sind in der Rootzone als signiert gekennzeichnet. Einige wenige testen DNSSEC noch ohne Eintrag in der Rootzone.

Funktionsweise

Informationen werden bei DNS in Resource Records (RR) bereitgestellt. DNSSEC sichert die Authentizität dieser Informationen durch eine digitale Signatur ab. Besitzer einer DNS-Information ist derjenige Master-Server, der für die Zone, in der die Information liegt, autoritativ ist. 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 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 Nummer identifiziert, den Key Tag. Eine digitale Unterschrift enthält in DNSSEC außerdem das Datum, ab dem sie gültig ist sowie ein Enddatum, ab dem sie ihre Gültigkeit verliert. Außerdem wird der verwendete Algorithmus spezifiziert.

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

DNS-Resolver auf Endgeräten wie Arbeitsplatzrechnern oder Smartphones (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 Stubresolver sehr einfach aufgebaute Programme, die für die vollständige Namensauflösung auf einen rekursiven Nameserver angewiesen sind. Ein Stubresolver, der einen Namen auflösen möchte, sendet eine entsprechende Anfrage an einen Nameserver im lokalen Netz oder im Netz des Internet Service Providers. Durch Setzen des DO-Bits (DNSSEC OK) im DNS-Header kann der Resolver dem Nameserver mitteilen, dass die Validierung durchgeführt werden soll. Hierzu muss der Stubresolver die Erweiterung EDNS unterstützen, da dort das DO-Bit spezifiziert wurde. Der rekursive Nameserver kann jedoch auch konfiguriert werden die Validierung immer durchzuführen, unabhängig vom Vorhandensein oder Inhalt des DO-Bits. Bei erfolgreicher Authentifizierung setzt der Server in der Antwort das AD-Bit (Authenticated Data). Schlägt die Authentifizierung fehl, gibt der Server einen allgemeinen Fehler zurück. Für den Stubresolver ist es nicht erkennbar, ob der Fehler durch eine fehlgeschlagene Validierung ausgelöst wurde oder durch eine andere Ursache, zum Beispiel Netzausfall oder Nameserver-Ausfall des angefragten Domainnamens.

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 oder vertrauliche Informationen offenbart, etwa eine Liste aller Kundendomains. Im März 2008 wurde mit RFC5155 der NSEC3-Eintrag definiert, der anstelle von Klartext-Domainnamen die Hash-Werte von Domainnamen zurückliefert und so das Zone Walking erschwert. Ein Angreifer muss einen rechenaufwändigen Wörterbuchangriff durchführen, um aus den Hash-Werten die Domainnamen zu erhalten. Um dies weiter zu erschweren, ist eine wiederholte Anwendung der Hash-Funktion vorgesehen, sowie der Einsatz von Salt. BIND unterstützt NSEC3 seit Version 9.6 und NSD seit Version 3.1.

Chain of Trust

Um eine sichere Authentifizierung zu gewährleisten, muss der Public Key einer Zone (bzw. dessen Hash) 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 Hash 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. 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.

Sicherheitsrelevante Schwachstellen von DNSSEC

• Denial-of-Service-Angriffe auf Nameserver werden durch DNSSEC nicht verhindert, sondern auf Grund der höheren Last auf den Servern sogar erleichtert.
• DNS Amplification Attacks unter Ausnutzung der öffentlichen DNS-Infrastruktur werden effektiver, da DNS-Antworten mit DNSSEC deutlich länger sind.
• 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 (erschwert 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. Kritiker werfen der ICANN vor, durch die DNSSEC-Schlüsselverwaltung in den USA die Unabhängigkeit des Internets zu gefährden. Als Signierungspartner hatte die ICANN ausschließlich die amerikanische Firma Verisign vorgesehen. 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. 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. 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.

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

Weblinks

• dnssec.net – Bekanntes Portal zu DNSsec (englisch).
• Einführung in Secure DNS (PDF; 122 kB)
• DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing (PDF; 68 kB)
• DENIC: DNSSEC-Testbed für Deutschland
• Alan Clegg: DNSSEC in 6 Minutes. (PDF; 315 kB) Internet Systems Consortium