东海通港西街3层空中飞架立体绿廊 串起桃花观音山

DNSSEC im TCP/IP-Protokollstapel:

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

百度 原标题：12岁男孩闹市遭遇抢劫？原来是贪玩游戏自导假戏光天化日之下，闹市街头，12岁男孩被人抢劫？劫匪索要钱数正好与男孩父亲钱包里钱数相当，这是巧合？听起来就漏洞百出的作案过程，到底是碰上了傻劫匪，还是从头到尾就是一个谎言？原来，这个惊心动魄的抢劫故事，其实是男孩为了打游戏偷拿父亲钱的自导自演。

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 DNS-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 (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 DNSSEC-Version – im M?rz 1999 im RFC 2535 – 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, 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. 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. Die Verbreitung von DNSSEC auf Domainebene betr?gt bei einigen TLDs mittlerweile 50 % oder mehr. Im Mittel validieren etwa 10 % der Domains.

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 (englisch: 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.

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 (englisch: 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 (englisch: 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 (englisch: 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 (englisch: 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 und verwandte Protokolle

Durch DNSSEC wird lediglich die Namensaufl?sung gesichert, nicht jedoch die darauf meist folgende Datenübertragung mit einem Anwendungsprotokoll wie beispielsweise dem Hypertext Transfer Protocol (HTTP) oder Simple Mail Transfer Protocol (SMTP). Zur Absicherung der eigentlichen Datenübertragung ist der Einsatz von verschlüsselnden übertragungsprotokollen wie Transport Layer Security (TLS) oder Secure Shell (SSH) notwendig.

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 digitales Zertifikat ausweisen, f?llt dies nicht auf. Eine andere Angriffsform w?re beispielsweise durch einen Downgrade-Angriff die Verwendung von TLS komplett zu umgehen. An dieser Stelle setzt DNS-based Authentication of Named Entities (DANE) an, um das Zusammenspiel zwischen DNSSEC und TLS zu sichern. Mit einem TLSA Resource Record kann eine Domain signalisieren, dass für eine bestimmte Anwendung TLS verwendet werden muss. Zus?tzlich ist eine Bindung an ein bestimmtes Zertifikat oder eine bestimmte Zertifizierungsstelle m?glich.

DNSSEC schützt die Integrit?t der Namensaufl?sung Ende-zu-Ende zwischen Domain und validierendem Resolver. Eine Transportverschlüsselung findet bei DNSSEC nicht statt. Die Protokolle DNS over TLS und DNS over HTTPS bieten eine Transportverschlüsselung, die zus?tzlich zu DNSSEC verwendet werden kann. Der prim?re Einsatzzweck ist die sichere Kommunikation von (Stub-)Resolver bzw. Anwendung zu einem rekursiven Nameserver. Beide bieten Vertraulichkeit vor einem lauschenden Angreifer im Netz, was DNSSEC alleine nicht bietet. DNS over HTTPS hat den Vorteil, dass sich die Kommunikation wie eine gew?hnliche HTTPS-Verbindung bei Webverkehr darstellt und somit auch in Netzen mit eingeschr?nkter Kommunikationsf?higkeit funktioniert.

DNSCurve ist eine Alternative zu DNSSEC, die sich allerdings nicht durchgesetzt hat. DNSCurve verwendet ein eigenes Verschlüsselungsprotokoll, welches sich sowohl von DNSSEC als auch TLS unterscheidet.

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. Dies wird erschwert durch NSEC3, was den Inhalt der Zone durch Hashing verschleiert. Zone Walking kann durch Online-Signierung vollst?ndig verhindert werden, was jedoch das Vorhalten des privaten Schlüssels auf dem Server und h?here Rechenlast erfordert.
• 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. 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 Jahr 2007, 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 behielt sich jedoch bis September 2016 die Aufsicht vor.

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

• RFC: 4033 – DNS Security Introduction and Requirements. (englisch).
• RFC: 4034 – Resource Records for the DNS Security Extensions. (englisch).
• RFC: 4035 – Protocol Modifications for the DNS Security Extensions. (englisch).
• RFC: 5011 – Automated Updates of DNS Security (DNSSEC) Trust Anchors. (englisch).
• RFC: 5155 – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. (spezifiziert NSEC3, englisch).

Weblinks

• dnssec.net – Portal zu DNSSEC (englisch).
• Die 14 Schlüssel zum Internet – Die Web-Verwaltung ?ICANN“. (Memento vom 4. M?rz 2016 im Internet Archive) (MP3; 22 MB) Podcast zur Sendung IQ – Wissenschaft und Forschung, 24. Juli 2014.
• Einführung in Secure DNS. (PDF; 122 kB) hznet.de
• DNSsec in der Praxis: Werkzeuge für Keymanagement und Zone Signing. (PDF; 68 kB) hznet.de
• Alan Clegg: DNSSEC in 6 Minutes. (PDF; 315 kB) Internet Systems Consortium.
• DNSSEC – Domain Name System Security Extensions. Heise Online.