DNSSEC Grundlagen

Das Domain Name System (DNS) nimmt im Internet eine Vielzahl von Aufgaben wahr. Primär löst es Alphanumerische Host- und Domainnamen nach ihren zugehörigen IPs auf. Aber auch andere Infomationen werden darüber verteilt, z.B. Serverkonfigurationen für VoIP-Telefone.

Wie auf der Wiki-Seite "DNS-Grundlagen" beschrieben, arbeitet es nach dem Prinzip einer riesigen verteilten Datenbank, in der Nameserver jeweils nur für ihre eigene Zone autoritativ verantwortlich sind, und ansonsten die Verantwortung gemäß der Zonenhierarchie weiter delegieren.

Dieses System ist ein enormer Fortschritt im Vergleich zu dem bis dahin per Hand gepflegten und verteilten Hosts-Dateien, beruht aber im Wesentlichen auf gegenseitigem Vertrauen. Weder authentifizieren sich Clients gegenüber den Servern, noch authentifizieren diese ihre Autorität für eine bestimmte Zone. Auch sind die Anfragen oder Antworten nicht verschlüsselt, und die Integrität einer Antwort ist nicht sicher gestellt.

Daraus ergibt sich eine Vielzahl an Angriffsmöglichkeiten, die wir ebenfalls auf unserer Wiki-Seite angeschnitten haben. Deshalb wurde unter Berücksichtigung der Rückwärtskompatiblität mit dem bestehenden System die DNS Security Extensions, kurz DNSSEC, entwickelt und als EDSN0 in RFC 6891 spezifiert.

DNSSEC Funktionsweise

DNSSEC beruht darauf, dass Antworten der autoritativen Nameserver kryptographisch signiert werden. Alle anfragenden Resolver oder über die die Anfrage durch Delegation weiter gereicht wird, können die Authentizität der Antwort durch Generierung eines Hashes aus einem öffentlichen Schlüssel verifizieren.

Dies ist eine Anwendung des bekannten Prinzips des "Public-Key-Verschlüsselungsverfahren" (asymmetrisches Kryptosystem), bei dem ein privater, nur dem Eigentümer bekannter, Schlüssel zum Signieren von Daten benutzt wird, während ein öffentlicher Schlüssel bekannt gemacht wird, mit dem anderere die signierten Daten als dem Eigentümer zugehörig verifiziert können.

Ein mathematisches Verfahren (wie bei RSA auf Faktorisierung basierend) zur Schlüsselerzeugung, bei dem gleichzeitig ein Schlüsselpaar erzeugt wird, stellt sicher, dass nur jeweils ein privater und öffentlicher Schlüssel zusammen gehören, während die Errechnung des privaten Schlüssels aus dem öffentlichen Schlüssel so schwer ist, dass das mit heutigen Computersystemen als unmöglich angesehen werden muss.

Aus dem privaten Schlüssel ("private key") kann der Zoneninhaber über eine Hash-Funktion eine Signatur ("signature") erzeugen. Diese wird zusammen aus den  zu authentizierenden Daten errechnet und der Antwort des Nameservers, d.h. Zoneneinträgen, hinzugefügt und mit der Antwort an einen Anfrager übertragen.

Der anfragende Resolver lädt zuerst den öffentlichen Schlüssel ("public key") vom für diese Zone autoritativen Nameserver, und kann dann mit derselben Hash-Funktion einen Hash aus dem öffentlichen Schlüssel und den empfangenen Daten errechnen. Wenn die Signatur aus der Antwort mit dem errechneten Hash übereinstimmen, dann ist die Antwort authentisch und unverfälscht.

Signaturen

Die Signaturen werden immer über RRsets gebildet, d.h. alle Resource Records, die demselben Namen ("owner") in einer Zone zugehörig sind, nicht einzelne RRs.  Über die Signatur wird auch die Unverfälschtheit der Daten sicher gestellt. Würden auf dem Weg die Daten durch einen Angreifer (oder Übertragungsfehler) verändert, schlägt sich das in einer verfälschten Signatur nieder.

Der aus den empfangenen Daten und öffentlichen Schlüssel errechnete Hash würde nicht mehr mit der Signatur übereinstimmen, die den Daten hinzugefügt wurde. Die Gleichheit garantiert also sowohl Authentizität (nur der Besitzer des privaten Schlüssels konnte die Daten signieren), als auch Integrität (die Daten sind nicht durch Dritte verfälscht worden).

Dabei werden die Signaturen mit dem privaten Schlüssel immer über den jeweiligen Resource Record erstellt, d.h. die Signaturen für verschiedene Zoneneinträge unterscheiden sich:

ws01.ws.dnssec.bayern.    295    IN    RRSIG    SOA 8 4 300 20170323145752 20170221145752 56961 ws01.ws.dnssec.bayern.
ApyjsLsf6u7yYoPtJS/i1mg5jdEI1DoOc8O6uaHsVqCkpSq99eE/YdE1
95p2Mdvyb328/hRBlccnbF9YhlKsp4JbCM9wLXB0csYFhlwFaFgltr5Q
psIXlxQCwXrXEyBpr6MrOFXc5qyXl/wD5vY1YFi4si90ExOlkbMo9IT/
K/21QSrQwuvxWpdPIioCWKqt3ovVrtJKKKxlXBWU0etWhk12x7ygYcco
p6T87Vot5ivVZofa9/7I7QJbhGm0+3P3qnWTDKl85kulDjk+G/UgwZzF
YJ31qYVrWJXzw/SldDVOMXJJ6wgx/u1Czb6mkEdWR6voanDTPjzhGYdF
y6tgdw==
ws01.ws.dnssec.bayern.    295    IN    RRSIG    NSEC 8 4 300 20170323145752 20170221145752 56961 ws01.ws.dnssec.bayern.
pFvpX023lNs4dXE4RkYDAwOS0g2OcAU04hms/TjYJJLlz1cheDE1kVG0
73/ICa3SN8enc+FaZS5nspIvPz9lViSpdDQPqGVIwj/mpfUhQC6dlHnT
qgoV8Ajn+Y++urbspfadQxaKx6S8BzmPo9xbaKTRo/o1p7Uj9a7Xb7uP
Pi565SibgD4ISv4pS7r59wj6DlF9+r3S8Vcah6hOQzF6EXBcNTnG9olP
vt/qATxIMiKvDyPjEzZswYYVAAreNNG5NCcBqtL3W4dIMrAUgBwJul7h
i1LWoq/FC+hUsFFfLqy3lYo4hEjd/+QPGK9Qsz8jipIn8iKypMDndSuZ
O5sVGg==

Die Signatur ist in der Zone als Hash (entweder RSA/SHA-1, oder wie zu empfehlen als RSA/SHA-256) eingetragen, vergrößert dadurch aber den Umfang der Zone merklich. DNSSEC-signierte Zonen sind ungefähr drei bis vier Mal so groß wie unsignierte Zonen.

Für moderne Nameserver-Systeme mit aktueller Hardware sollte weder der höhere Festspeicher- und RAM-Bedarf der Zonendateien, noch die Verifikation der Signaturen auf Resolvern ein Problem darstellen.

Das Signieren großer Zonen (~100000 Einträge) geschieht in unter einer Minute, und muß auch nur bei Änderungen an der Zone durchgeführt werden. Werden Zonendaten häufig aktualisiert, muss das aber berücksichtigt werden. Dies geschieht aber bei BIND mit auto-dnssec maintain zudem inkrementell, sollte also vollkommen zeitunkritisch sein.

DNSSEC-Abfrage im Detail

Die folgende Folie illustriert eine DNSSEC-gesicherte Abfrage im Detail. NB: Das Bild ist mit einer Animation verlinkt.

Man muss beachten, dass die Anfragen und Antworten auch mit DNSSEC nicht verschlüsselt sind! Aber DNSSEC garantiert damit für DNS-Abfragen folgende Merkmale:

• Authentizität der Antwort
• Integrität der Daten

Delegation und Chain-of-trust

Delegation

Da in der hierarchischen Struktur von DNS die Verantwortung jeweils weiter gereicht wird, muss sicher gestellt werden, dass auch an den richtigen Nameserver weiter verwiesen wird. Dies bezeichnet man als "Delegation", und zusätzlich zum Nameservereintrag der die IP des jeweilig nachfolgenden für eine Zone autoritativen Nameserver enthält gibt es einen zusätzlichen Eintrag, den "Delegated Signer" (DS), der garantiert, dass diesem Nameserver vertraut wird.

Chain-of-trust

Er enthält den public key des nachfolgenden Nameservers, der sogenannten "child zone", und wird vom Nameserver der "parent zone" mit dessen privaten Schlüssel signiert. Wenn also dem jeweiligen autoritativen Nameserver in der Hierarchie vertraut wird, heißt das, wir können auch dem DS-Eintrag vertrauen, da er mit dem privaten (d.h. geheimen) Schlüssel der parent zone signiert wurde. Dann können wir auch dem Nameserver vertrauen, auf den er verweist.

Den Einträgen des für die "child zone" autoritativ verantwortlichen Nameservers vertrauen wir, weil er seine Einträge mit dem nur ihm zugänglichen privaten Schlüssel signiert hat.

Daraus ergibt sich dann, sofern alle Nameserver korrekt signierte DS-Einträge besitzen, eine durchgehende "Chain-of-trust", und wir können einer DNS-Abfrage, die notwendigerweise alle für die jeweiligen Zonen verantwortlichen Nameserver abfrägt, vollständig vertrauen.

Vollständig? Jede Domänabfrage beginnt bei den Root-Servern. Diese haben aber keine übergeordnete Parentzone, die ihre Richtigkeit garantiert. Diese sind mit dem "root-Key", der unter der Verwaltung der IANA steht, und mit besonderen Maßnahmen (niemand besitzt den vollständigen Schlüssel) geschützt wird. Der öffentliche Schlüssel des root-Key kann dann herunter geladen werden, oder ist bei den meisten Nameserver-Programmen hinterlegt.

Die Handhabung des root-Key für den Signing-Prozess der root-Zone folgt besonderen Regeln (ein Artikel dazu im Magazin der Süddeutschen Zeitung), um die Sicherheit zu gewährleisten.

Da der root-Key der Anfang der "chain-of-trust" ist, dem man schlichtweg vertrauen muss, zumindest kann es nicht kryptographisch durch eine Signaturerrechnung geschehen, ist damit ein "trust anchor", an dem die "Vertrauskette" hängt.

Zone-Signing-Key (ZSK) und Key-Signing-Key (KSK)

Da die Authentizität des Schlüssels eines Nameservers nun aber davon abhängt, dass der Nameserver der Parentzone ihn signiert, erfordert der Aufbau einer Vertraunskette jeweils Interaktion mit dem Parent.

Längere Schlüssel bieten zwar mehr Sicherheit, führen auch zu längeren Signaturen und damit zu größeren Zonendateien, und in der DNS-Antwort zu übertragenden Daten. Schlüssel, gleich jeder Länge, können aber kompromittiert werden oder mit großem Aufwand geknackt werden.

Um dem entgegen zu wirken, will man die Schlüssel von zu Zeit zu Zeit erneuern. Es muß kein strikter regelmäßiger Turnus eingehalten werden, es wäre aber genauso falsch, den Schlüssel mit dem man seine Zoneneinträge signiert, jahrelang zu verwenden.

Die Lösung liegt darin, zwei Schlüsselpaare zu verwenden. Einen so genannten "Zone-Signing Key" (ZSK), der die Resource Recordsets der Zone signiert, und nur unter der Verwaltung des Zoneninhabers steht, und einen "Key-Signing Key", der nur zum Signieren des Zone-Signing Keys verwendet wird.

Der Key-Signing Key garantiert dann die Authentizität des Zone-Signing Key, und damit auch die Richtigkeit der mit ihm signierten Resource Recordsets in der Zone. Nun muss nur noch den öffentliche Teil des Key-Signing Keys an den Betreiber der Parentzone kommuniziert werden. Wie oben beschrieben, signiert dieser dann mit seinem KSK den DS-Eintrag mit dem KSK der "child zone".

Durch die Aufspaltung in Zone-Signing Key und Key-Signing Key ergibt sich folgendes Bild unserer "Delegated Signer"-Einträge:

Da nur der Zone-Signing Key zum Signieren der Zoneneinträge verwendet wird, um deren Integrität und Authentizität sicher zu stellen, können wir unabhängig vom Eintrag des DS im Parent und dem bei Änderung desselben notwendigen Signieren mit dem Schlüssel der Parent zone, das nur durch den Betreiber der Parent zone geschehen kann, unsere Zone bei Änderungen signieren oder den ZSK nach Belieben wechseln.

Der Parent-Key signiert nur noch den DS-Eintrag mit dem KSK. Bei Änderung unseres KSK ist aber die "out-of-band" Kommunikation mit dem Parent noch notwendig. Es gibt zwar Vorschläge von "in-band"-Updates der Parent-DS-Einträge, diese haben aber noch keine Verbreitung gefunden.

Ein Update des KSK und der Eintrag in der Parentzone muss daher wohl überlegt und geplant geschehen, um unsere Zone nicht als "SERVFAIL" auf validierenden Resolvern erscheinen zu lassen.

DNSSEC Schlüssel

Für Zone-Signing Keys und im besonderen für Key-Signing Keys sollte man einige Richtlinien einhalten. Um einen reibungslosen Schlüsselwechsel vollziehen zu können, einen so genannten "key rollover" haben wir auf wir im Wiki bereits diesen Howto-Artikel über DNSSEC Schlüssel und Key rollover veröffentlicht.

Voraussetzungen für DNSSEC

Um DNSSEC auf seinen Nameservern betreiben zu können, sind neben dem Einsatz DNSSEC-fähiger Nameserver-Software einige grundsätzliche Voraussetzungen zu erfüllen.

• MTU muss mindestens 1220 Byte, sollte aber besser 2048 Byte groß sein (siehe RFC 3226 und RFC 4035)
• TCP Port 53 muss in Firewalls für eingehenden und ausgehenden Verkehr geöffnet sein

DNSSEC - Neue Resource Records

Wie bereits eingangs erwähnt wurde DNSSEC als rückwärtskompatible Erweiterung des etablierten DNS-Protokollls konzipiert. Das Protokoll wurde mit dem EDNS(0), den "Extension Mechanisms fpr DNS" (RFC 6891) dahin gehend erweitert.

Weiter benötigt DNSSEC zusätzliche Resource Records in den Zonendefinitionen, die als "Resource Records for the DNS Security Extensions" (RFC 4034) definiert wurden, um die vorher gehend beschriebene PKI-basierte Authentizität und Integrität einer Zone zu ermöglichen.

NSEC - Authentische Nicht-Existenz von Einträgen

DNSSEC ermöglicht es, authentisch zu sagen, dass ein Eintrag existiert. Die Signatur des privaten Schlüssels des Zonen-Inhabers garantiert dafür, und kann durch Vergleich mit dem aus öffentlichen Schlüssel errechneten Hash verifiziert werden.

Aber wie kann man verifizieren, dass ein Eintrag nicht existiert? Ein Angreifer könnte immer noch DNSSEC-Antworten abfangen und vorgeben, dass es zu einer Anfrage an einen autoritativen Nameserver keine Antwort gibt.

Es wird intern eine sortierte Liste (bzw. ein Ring, d.h. der letzte Eintrag verweist wieder auf den ersten) aller Zonen-Einträge (inklusive MX,NS,SOA,TLSA, usw.) gebildet. Dann wird für jeden Eintrag dieser Liste ein NSEC-Eintrag mit den Daten des Resource Records des jeweils folgenden erstellt, und mit dem Zone-Signing Key eine Signatur erzeugt.

Mit den NSECs und deren RRSIGs garantiert der ZSK die Vollständigkeit der Einträge in der Liste, und darüber hinaus, dass (alphabetisch) zwischen diesen Einträge keine weiteren existieren.

Diese fixen NSEC-Einträge sind nötig, da die "on-the-fly"-Erstellung von Signaturen rechenaufwändig ist, und das Vorhalten des privaten Zone-Signing Keys gegen unsere Sicherheitsrichtlinien verstossen würde. Ein böswilliger Angreifer könnte mit einer Unzahl an NSEC-Anfragen unseren Nameserver lahm legen.

Die Implementierung von NSEC gemäß RFC 7129 in DNSSEC ist wie am folgenden Beispiel erläutert:

Unsere Zonen-Datei zeigt vereinfacht die Liste unserer beim Signieren erstellten NSEC-Einträge mit deren Signaturen. Ein anfragender Resolver, fragt nach der IPv4-Adresse, "A", von fruit.lrz.de. Wir sehen, dass fruit.lrz.de nicht in der Zone-Datei vorhanden ist, aber zwischen "dodo.lrz.de" und "mouse.lrz.de" liegen würde.

Das bedeutet für unsere authentische "Next SECure Entry"-Antwort, dass der Nameserver uns die Nachricht mit dem NSEC-Parametern, die unseren nicht-existenten Eintrag "fruit.lrz.de A" umschließen würden, authentiziert mit einer entsprechenden Signatur:

Wenn zwar ein IPv4 ("A)" Resource Record für baby.lrz.de existiert, aber kein IPv6 ("AAAA")-Eintrag, erhalten wir für eine Anfrage nach "AAAA" trotzdem die vorbereitete NSEC-Antwort für baby.lrz.de.

Antwort: Es existiert kein IPv6 "AAAA"-Eintrag für baby.lrz.de, durch die Antwort, "der nächste Eintrag nach baby.lrz.de A ist cat.lrz.de", authentiziert durch die zugehörige RRSIG über den NSEC-Eintrag.

Zone-Walking

Da uns jede NSEC-Antwort über einen nicht existierenden Eintrag den vorhergehenden Domainnamen mit allen Resource Records dazu liefert, und erlaubt über den angegebenen nachfolgenden Eintrag der Zone so durch sukzessive Abfragen das Auslesen der gesamten Zone. Das entspricht einem kompletten Zonentransfer, den man sonst versucht nur autorisierten Nameservern zu erlauben.

Diverse Tools, z.B. ldsn-walk aus den LDNS-Tools oder dnssecwalk ermöglichen das ohne besondere Umstände, zum Beispiel mit der Workshop-Zone:

ldns-walk ws01.ws.dnssec.bayern.

ws01.ws.dnssec.bayern.    ws01.ws.dnssec.bayern. NS SOA MX RRSIG NSEC DNSKEY
_25._tcp.dnssec-ws01.ws01.ws.dnssec.bayern. RRSIG NSEC TLSA

Das Credo von DNS und damit auch DNSSEC ist natürlich, meine Zone ist "sicher, aber nicht geheim". DNS-Daten sind öffentlich und die Übertragung erfolgt auch nicht verschlüsselt. Die Einträge einer Zone sollen ja gerade bekannt sein.

Dennoch kann das komplette Auslesen einer Zone einem Angreifer Informationen über Mailserver, Nameserver usw. geben, und die Rechnernamen lassen unter Umständen Rückschlüsse auf die Systeme zu. Es betrifft also durchaus Fragen der Datensicherheit.

NSEC3

Eine Lösung dieses Problems bietet seit 2008 NSEC3 mit "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence" (RFC 4055). Damit werden beim Signieren der Zone alle Einträge (mehrfach) gehasht

und das Auslesen der nicht-existierenden NSEC-Einträge fördert nur kryptische Namen zu Tage.

Bzw. die Zone-Walking-Tools erkennen bereits, dass es keinen Sinn ergibt die gehashten Daten auszugeben:

ldns-walk ws01.ws.dnssec.bayern.
ws01.ws.dnssec.bayern.    Zone does not seem to be DNSSEC secured,or it uses NSEC3

Die Zonendatei ist zwar dann nicht mehr "human-readable", aber für DNSSEC empfehlen wir "Proxy Signing" und damit sowieso auf einer Eingangsdatenbasis zu arbeiten, auf einem Proxy signieren und die DNSSEC-signierten Zonendateien auf den eigentlichen autoritativen Nameservern abzulegen, wo keine direkte Arbeit mehr auf den Zonen-Dateien stattfinden sollte.

Allerdings ist auch NSEC3 mit GPU brute force angreifbar, oder wie die Veröffentlichung "Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on NSEC3 Variants" von Goldberg et. al. aus dem Jahr 2015 zeigt. Aber es gilt immer noch das Motto, meine Zone "ist sicher, aber nicht geheim".