Domain Name System Security Extensions

DNSSEC im TCP/IP-Protokollstapel:
AnwendungDNSSEC
TransportUDPTCP
InternetIP (IPv4, IPv6)
NetzzugangEthernetToken
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 (englisch private key). DNS-Clients können diese Unterschrift mit dem öffentlichen Schlüssel (englisch public key) des Besitzers validieren und damit Authentizität und Integrität überprüfen. DNSSEC setzt die Erweiterung Extended DNS 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 DNSSEC-Version – im März 1999 im RFC 2535[1] – definiert 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. Seit Mai 2011 ist DNSSEC auch für .de-Domains prinzipiell verfügbar,[2] nachdem das Zone Walking durch die Einführung des NSEC3 Resource Records im März 2008 hinreichend erschwert wurde.

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.[3] Mittlerweile sind 90 % der Top-Level-Domains mit DNSSEC signiert und in der Rootzone als signiert gekennzeichnet. Einige wenige testen DNSSEC noch ohne Eintrag in der Rootzone.[4] Die Verbreitung von DNSSEC auf Domainebene beträgt bei einigen TLDs mittlerweile 50 % oder mehr. Im Mittel validieren etwa 10 % der Domains.[5][6][7][8]

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.[9]

Schlüsselverwaltung

Um das Keymanagement zu erleichtern, wurde zusätzlich zum Schlüssel für die Signatur der Zone (Zone signing key, ZSK) ein syntaktisch identischer Schlüsselunterzeichnungs-Schlüssel (engl.: key signing key, KSK) definiert. Im Flags-Feld des DNSKEY-Records wird Bit 7 gesetzt, wenn der enthaltene Schlüssel für die Signatur von Resource Record Sets der Zone verwendet wird. Dies gilt für KSKs und ZSKs: Mit den KSKs werden DNSKEY-Records signiert und mit den ZSKs alle anderen Records. Bit 15 (Secure Entry Point) wird gesetzt, wenn der Schlüssel der Startpunkt für die Validierung der Zone ist – dies gilt für KSKs. Da andere Bits bislang nicht verwendet werden, hat das Flags-Feld den Wert 256 für ZSKs und 257 für KSKs.

Mit diesem KSK werden ausschließlich DNSKEY-Records unterzeichnet, die die eigentlichen Zonenschlüssel enthalten. Ein derartiger Schlüsselunterzeichnungs-Schlüssel wird für die Bildung von Vertrauens-Ketten (engl.: chains of trust) verwendet. Ein Hashwert des KSK wird in der übergeordneten Zone in einem DNS-Record abgelegt, wodurch die Echtheit der Zonenschlüssel im signierten DNSKEY-Record sichergestellt werden kann. Im Gegensatz zum häufig erneuerten Zonenschlüssel besitzt ein KSK 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 Extended DNS 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

Man kann mit DNSSEC auch 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 ab Version 9.6 und NSD ab 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 übergeordnete 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 übergeordneten Zone example.org. als Trusted Key manuell eingetragen:

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

Konkretes Beispiel an der .de-TLD

Die Root-Nameserver unterstützen DNSSEC seit 2010. Um eine .de-Domain mit einer Vertrauenskette zu sichern, existieren folgende Maßnahmen:

  • Die Root-Server liefern einen DS-Record für die de.-Zone aus. Dieser enthält einen Hash des deutschen Schlüsselunterzeichnungsschlüssels (Key signing key):

de. IN DS 24220 8 2 FFE926ACA67ED94089390250F1F294AC84A6D84F9121DF73A79E439F 42E820C2. Der DS-Record ist mit dem Zonenschlüssel der Root-Zone signiert.

  • Der Schlüsselunterzeichnungsschlüssel (erkennbar an der Zahl 257) der deutschen Zone (dessen Hash im DS-Record auf den Root-Servern liegt) lautet

de. IN DNSKEY 257 3 8 AwEAAYbcKo2IA8l6arSIiSC+l97v2vgNXrxjBJ... (gekürzt)

  • Mit diesem key signing key wird wiederum der DNSKEY-Record der deutschen Zone signiert (per RRSIG), der den Zonenschlüssel enthält (erkennbar an der Zahl 256). Ein Resolver weiß nun, dass der deutsche Zonenschlüssel echt ist, da er mit einem Schlüssel gesichert ist, der von den Root-Servern als echt bestätigt wird.

de. IN DNSKEY 256 3 8 AwEAAZ4e4Nf1SpBWMhSK6ha+YeJyq... (gekürzt)

  • Um eine deutsche Domain per DNSSEC abzusichern, wird in der de.-Zone neben dem üblichen Delegations-Record (NS) wiederum ein DS-Record mit dem hash des key signing key der Domain erstellt. Ein Resolver kann nun wiederum die Echtheit des Zonenschlüssels der Domain erkennen, da der DNSKEY-Record, der den Zonenschlüssel enthält, von einem Schlüssel signiert wurde (RRSIG!), dessen Hash bei der DENIC liegt.

Grenzen von DNSSEC

Durch DNSSEC werden lediglich die Nameserverabfragen gesichert. Dies ist hauptsächlich in Verbindung mit verschlüsselnden Übertragungsprotokollen wie TLS sinnvoll. Die Kombination aus DNSSEC mit TLS hat aber noch Schwachstellen. Korruptes Routing könnte beispielsweise Pakete, die an eine mit DNSSEC korrekt ermittelte Ziel-IP-Adresse gesendet werden, an einen falschen Rechner zustellen. Kann sich dieser Rechner durch ein kompromittiertes oder versehentlich ausgestelltes Zertifikat ausweisen, fällt dies nicht auf. An dieser Stelle setzt zum Beispiel DANE an, um das Zusammenspiel zwischen DNSSEC und TLS zu sichern.

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 (englisch Trust Anchor) auf anderem Wege als der DNS-Infrastruktur (zum Beispiel mit dem Betriebssystem oder der Server- bzw. Clientsoftware) verteilt wird.
  • Mittels Zone 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.

Verwaltung des Rootzonenschlüssels

Momentan findet die Verwaltung des DNSSEC-Schlüssels für die Root-Zone ausschließlich an zwei US-Standorten statt. Nach Ansicht vieler RIPE-Experten ist ein Standort außerhalb der USA unabdingbar.[10] Kritiker werfen der ICANN vor, durch die DNSSEC-Schlüsselverwaltung in den USA die Unabhängigkeit des Internets zu gefährden.[11] Als Signierungspartner hatte die ICANN ausschließlich die amerikanische Firma Verisign vorgesehen.[12] Das US-amerikanische Department of Homeland Security forderte im Jahr 2007, die Schlüsselverwaltung vollständig in die Hände der US-Regierung zu legen.[13] 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.[14] Die ICANN ist formal unabhängig, die US-Regierung behielt sich jedoch bis September 2016[15] die Aufsicht vor.

Siehe auch

Literatur

  • Christoph Sorge, Nils Gruschka, Luigi Lo Iacono: Sicherheit in Kommunikationsnetzen. Oldenbourg Wissenschaftsverlag, München 2013, ISBN 978-3-486-72016-7.

Normen und Standards

  • RFC4033 – DNS Security Introduction and Requirements. (englisch).
  • RFC4034 – Resource Records for the DNS Security Extensions. (englisch).
  • RFC4035 – Protocol Modifications for the DNS Security Extensions. (englisch).
  • RFC5011 – Automated Updates of DNS Security (DNSSEC) Trust Anchors. (englisch).
  • RFC5155 – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. (spezifiziert NSEC3, englisch).

Weblinks

Einzelnachweise

  1. ↑ RFC2535 – Domain Name System Security Extensions. März 1999 (englisch).
  2. ↑ DNSSEC. DENIC, 12. Mai 2014, abgerufen am 12. Mai 2014 (englisch).
  3. ↑ DNSSEC in der Rootzone gestartet. Heise News
  4. ↑ Graphic DNSSEC in the TLDs Report. In: jpmens.net. 25. Juni 2018, abgerufen am 27. August 2023 (englisch).
  5. ↑ .nl stats and data - Insight into the use of .nl. In: SIDN. 21. November 2017, abgerufen am 21. November 2017 (englisch).
  6. ↑ Dashboard - CZ. Statistics. In: CZ.NIC. 21. November 2017, abgerufen am 21. November 2017 (englisch).
  7. ↑ Eurid in 2016 - Annual report 2016. (PDF) In: EURid. 3. April 2017, abgerufen am 21. November 2017 (englisch).
  8. ↑ DNSSEC Validation Capability Metrics - Use of DNSSEC Validation for World (XA). In: APNIC. 21. November 2017, abgerufen am 21. November 2017 (englisch).
  9. ↑ DNS Security Algorithm Numbers
  10. ↑ DNSSEC auf allen Rootservern. Heise News, 6. Mai 2010
  11. ↑ Machtfrage – Wer kontrolliert das Internet? In: c’t, 5/2010.
  12. ↑ IGF: Politische und technische Probleme bei DNSSEC. Heise News, 14. November 2007
  13. ↑ Department of Homeland Security will den Masterschlüssel fürs DNS. Heise News, 29. März 2007
  14. ↑ VeriSign will DNSSEC-Schlüssel (ein bisschen) teilen. Heise News, 3. Oktober 2008
  15. ↑ Monika Ermert: Last Formal Tie To Historic US Internet Control Is Cut. In: Intellectual Property Watch. 1. Oktober 2016, abgerufen am 28. November 2016.