Die Domain Name System Security Extensions (DNSSEC) ist eine Reihe von Erweiterungen, die dem DNS Protokoll weitere Sicherheitsmassnahmen hinzufügt und in den RFCs 4033, 4034 und 4035 spezifiziert wird. DNSSEC fügt DNS Origin Authority, Data Integrity und Authenticated Denial of Existence hinzu. Alle Antworten seitens DNSSEC-geschützten Zonen sind kryptographisch signed. Ein DNS Resolver kann den Public Key erhalten und validieren, dass die Antworten authentisch sind und nicht verändert worden sind.

DNS abzusichern ist essentiell um das Internet sicherer zu Machen. Allerdings wird es Jahre dauern, bevor DNSSEC breite Anwendung finden wird. Google Public DNS unterstützt DNSSEC seit März 2013 und lediglich 7% aller Queries von Clients waren DNSSEC-enabled. 24% aller DNS-Queries aus der Schweiz haben die DNSSEC-Validierung in den vergangenen Monaten verwendet (Quelle: APNIC statistics). Im Februar 2013 hat SWITCH entschieden die Statistiken im Zusammenhang mit DNSSEC nicht zu publizieren, da lediglich 0.05% aller aktiven Domains DNSSEC verwendet haben. Daher sei die Veröffentlichung ungerechtfertigt, hiess es. Heute listet ICANNs Deploying DNSSEC list nur zwei Registrars, die End User DNSSEC Management für die Top Level Domain .ch unterstützen. Da diese Situation weit vom Ideal entfernt ist, sucht dieses Labs eine Übersicht über DNSSEC zu geben und darüber zu informieren wie DNSSEC eingesetzt und gewartet werden kann. Ausserdem, seien wir ehrlich: Wie hart kann das sein?

DNSSEC Keys

DNSSEC funktioniert dadurch, dass es Datensätze mittels Public Key Kryptopgraphie für DNS Lookup signiert. Es gibt zweierlei Keys um eine DNS-Zone zu signieren: den Key Signing Key (KSK) und den Zone Signing Key (ZSK).

Der KSK wird dazu verwendet, das DNSKEY Resource Record Set (RRSet) in einer Zone zu signieren. Sein Public Key muss im _Delegation Signer Record (DS) veröffentlicht werden. Dies kann geschehen, indem der KSK Public Key einem Registrar (und der Top Level Domain Zone) übermittelt wird. Dieser Schritt ist notwendig um die DNSSEC Kette des Vertrauens zu etablieren. Andererseits wird ein ZSK verwendet, der alle anderen RRSets in regelmässigen Abständen signiert. Diese Keys dürfen einem Registrar nicht übermittelt werden.

Aus Sicherheitsperspektive wird empfohlen, die Private Keys wie auch die Zone Master File nur offline und auf nicht mit dem Netzwerk verbundenen Maschinen, die auch noch physisch sicher sind, abzuspeichern und zu benutzen. Alle Signaturen sollten auf diesen Maschinen laufen und dann auf alle Nameserver übertragen werden. Eine weitere Best Practice ist es, die DNSSEC Keys regelmässig auszutauschen. Je länger ein Key im Einsatz ist, desto grösser die Wahrscheinlichkeit, dass er durch Nachsicht, Unfall, Spionage oder Kryptoanalyse kompromittiert wird. Ein ZSK sollte vierteljährlich ausgewechselt werden. Dieser Key Rollover wird später erklärt.

DNSSEC Keys erstellen

Der Prozess zur Key Generation ist von Umgebung zu Umgebung unterschiedlich. In diesem Labs verwednen wird dnssec-keygen um alle Keys zu erstellen. Der Prozess kann eine Weile dauer, da ein Server nicht genug Entropie Die Option -r in dnssec-keygen unterstützt die Nutzung einer Datei mit zufälligem Inhalt, wie /dev/random/. Ein weiterer Weg ist die Nutzung eines Random Number Generator Daemons wie haveged.

In diesem Labs verwenden wir eine Domain namens scip.example.com und wir erstellen den KSK mit 4096 bit Keysize (default ist 2048 bit) und einen ZSK mit Keysize 2048 bit (Default: 1024 bit). Der Algorithmus für beide Keys ist der NSEC3-fähige Algorithmus RSASHA256.

KSK:
dnssec-keygen -3 -a RSASHA256 -b 4096 -n ZONE -f KSK scip.example.com
ZSK:
dnssec-keygen -3 -a RSASHA256 -b 2048 -n ZONE scip.example.com

Nach der Ausführung dieser Befehle haben wir zwei Files pro Key. Eine Datei beinhaltet den Private key (.private), der andere den Public Key (.key). Beide Public Keys müssen in der Zone File enthalten sein. Dies kann mit dem Hinzufügen der folgenden zwei Zeilen am Ende der Zone File geschehen.

$INCLUDE <KSK_filename>.key
$INCLUDE <ZSK_filename>.key

Zone Signing und Zone Walking

Nutzen wir nun die Keys um die Zone File von @scip.example.com# zu signieren. Wie erwähnt signiert der KSK das DNSKEY RRSet und der ZSK alle anderen Datensätze. Die Signatur (RRSig) ist 30 Tage lang gültig, danach muss eine Zone neu signiert werden. Geschieht das nicht, kann ein Resolver keine Requests validieren und die Daten als Nonsense abstempeln. Somit würde es unmöglich werden, irgendwelche Daten aus der Zone aufzulösen.

Der Signaturprozess generiert einen NSEC Record pro Domainnname. Dieser listet alle existierenden Resource Record Types für einen Datensatz auf und leitet in den nächsten Datensatz über. Der letzte NSEC Record leitet zurück auf den ersten Record in der Datei. Das hat den Nebeneffekt, dass jeder alle Zonen-Records erhalten kann, wenn er der verlinkten Liste von NSEC Records folgt. Dies wird Zone Walking genannt.

Zum Beispiel: Wir haben unsere Zone File für scip.example.com, die zwei Domainnamen enthält.

$ORIGIN scip.example.com.
$TTL 1h
scip.example.com.       IN      SOA     ns1.example.com. username.example.com. ( 2014072801 1d 2h 4w 1h )
scip.example.com.       IN      NS      ns1.example.com.
scip.example.com.       IN      NS      ns2.example.com.
scip.example.com.       IN      A       192.0.2.1
www                     IN      A       192.0.2.2

Signieren wir diese nun mit den Standardoptionen.

# dnssec-signzone -N INCREMENT -o scip.example.com -t scip.example.com.zone

Überprüfen wir nun den NSEC Record für scip.example.com.: Er listet alle RR Types auf (A NS SOA RRSIG NSEC DNSKEY) und leitet auf den nächsten Eintrag der Liste weiter (in diesem Falle www). Entsprechend leitet der NSEC Record für www.scip.example.com. zurück auf scip.example.com., was ihn zum letzten Eintrag in der Zone File macht

scip.example.com.        3600    NSEC    www.scip.example.com. A NS SOA RRSIG NSEC DNSKEY
www.scip.example.com.    3600    NSEC    scip.example.com. A RRSIG NSEC

NSEC3 wurde veröffentlicht, um Zone Walking zu verhindern oder es zumindest schwieriger zu Machen. Wenn NSEC3 in den Domain Name Records mit einem Salt Value gehasht werden. Dieser Salt Value kann mit dnssec-keygen und der Option -3 festgelegt werden. Daher nutzen wir einen zufälligen String, der 16 Zeichen lang ist, als Salt Value und setzen die Option -H um 50 Iterationen durchzuführen (Standard: 10).

# dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -N INCREMENT -o scip.example.com -t scip.example.com.zone

Jetzt sind alle NSEC Records durch NSEC3 ersetzt und die Domainnamen in den Records sind gehasht.

ILMFC5R61RDV7BLGMA4FM0K5BMJ2USGE.scip.example.com. 3600 IN NSEC3 1 1 10 BECEC0C7ED27D96A TASH4704H4T65N9E4I61B0C57EDQ9RP4 A NS SOA MX RRSIG DNSKEY NSEC3PARAM
TASH4704H4T65N9E4I61B0C57EDQ9RP4.scip.example.com. 3600 IN NSEC3 1 1 10 BECEC0C7ED27D96A ILMFC5R61RDV7BLGMA4FM0K5BMJ2USGE A RRSIG

Ein entschlossener Angreifer kann immer noch den Salt Value (query dig NSEC3PARAM <domain>) herausfindne und ihn zur Erstellung einer Rainbow Table nutzen, damit er alle gehashten Werte entschlüsseln kann. Dies dauert aber eine lange Zeit und der Angreifer muss jedes Mal von vorne beginnen, wenn der Salt Value ändert. Daher ist es good practice, einen neuen Salt Value für jede neu signierte Zone zu verwenden.

Um das zusammenzufassen: Die Key-Generierung und das Signieren der Zonen kann vollständig offline geschehen. Ein Nameserver benötigt nur eine signierte Zone File dazu. Nachdem wir also die Zone File signiert haben, transferieren wir diese auf den Nameserver. Wenn der KSK zum ersten Mal verwendet wird, müssen wir seinen public key dem Registrar (DS Record) übermitteln. Alle Informationen, die dazu benötigt werden, sind in der Datei dsset-scip.example.com abgelegt.

Key Rollover

DNSSEC Keys müssen regelmässig gewechselt werden: Ein ZSK sollte nach 90 Tagen ausgetauscht werden und ein KSK sollte einmal pro Jahr ein Rollover erfahren. Der Unterschied zwischen einem ZSK und einem KSK Rollover ist, dass ein KSK Rollover Interaktion mit dem Registrar benötigt.

Ein Key Rollover ist nicht einfach nur Entferne alten Key, nutze neuen Key aufgrund des DNS Caching. DNS Zone Data und Public Keys sind unabhängig voneinander in den DNS Resolvern gecached. Der DNS-Validationsprozess scheitert wenn ein Resolver, der den alten Key nicht gechached hat, oder andersherum, wenn ein Resolver versucht, Daten zu validieren die mit einem neuen Key signiert wurden, der Resolver aber nur einen alten Key lokal gecached hat. Ein Zonenadministrator muss daher sicherstellen, dass gecachte Daten während des Rollovers immer noch validiert werden können. RFC 4641 beschreibt zwei Prozesse, die einen Key Rollover sauber abwickeln: Pre-Publish (Vorpublikation) und Double Signature (Doppelsignatur).

Double Signature

Im Prozess Double Signature wird eine Zone während des Rollovers von zwei Signaturen signiert. In der initialen Phase wird die Zone von Key K1 signiert. In der Phase new DNSKEY wird Key K2 eingeführt und K1 wie auch K2 signieren. Diese Rolloverphase dauert dann an, bis alle Daten im Cache des Resolvers abgelaufen sind. Das ist zu Beginn minimal die Zeit der maximalen TTL der Zone. Nach dieser Phase folgt die Phase DNSKEY removal während der K1 aus dem Keyset entfernt wird und die Zone nur von K2 signiert wird.

Beispiel eines Double Signature Befehls:

dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -k KSK/Kscip.example.com.+008+61219.key -k KSK/Kscip.example.com.+008+49831.key -N INCREMENT -o scip.example.com -t scip.example.com.zone ZSK/Kscip.example.com.+008+63084.key

Pre-Publish

Der pre-publish Prozess läuft in vier Schritten ab. In der initialen Phase wird K1 dazu verwendet, die Zone File zu signieren. Während new DNSKEY wird K2 ins Keyset eingeführt, aber K1 signiert die Zone weiterhin. Die minimale Laufzeit dieser pre-roll_-Phase ist die Zeit, die DNS-Daten benötigen, um zum _authoritative server zu propagieren plus die TTL des Keysets. In der Phase new RRSIG ist es nur K2, der die Zone signiert. K1 bleibt aber im Keyset enthalten. Diese Zone muss ebenfalls andauern, bis alle Daten in den Caches der Resolver aus der initialen Phase abgelaufen sind. K1 wird dann in der Phase DNSKEY removal entfernt. Dieser Prozess kann vereinfacht werden, indem der zukünftige Key gleich nach dem Rollover publiziert wird.

Beispiel eines pre-publish Befehls:

dnssec-signzone -3 $(head -c 1024 /dev/random | sha1sum | cut -b 1-16) -H 50 -A -k KSK/Kscip.example.com.+008+61219.key -N INCREMENT -o scip.example.com -t scip.example.com.zone ZSK/Kscip.example.com.+008+63084.key

Der Nachteil des Double Signature Prozesses ist es, dass während dem Rollover die doppelte Anzahl Signaturen in einer Zone vorhanden sind. Die könnte sich auf die Performance von grossen Zonen auswirken. Von Vorteil ist aber, dass der gesamte Prozess in nur drei Schritten bewältigt werden kann. Die Best Practice in der Praxis ist es, Double Signature für den KSK zu verwenden und Pre-Publish für den ZSK Key Rollover.

Als Beispiel verwenden wir Pre-Publish für ein ZSK Rollover, der alle drei Monate stattfindet:

Wenn wir das selbe Beispiel in der vereinfachten Version ansehen, dann wird der zukünftige Key unmittelbar nach dem Rollover publiziert.

Ein Key Rollover kann manuell oder voll automatisiert stattfinden. Daher speichern will alle Keys offline. Auch die Key Generation und das Signieren der Zonen geschieht offline, die signierte Zone muss jedes Mal dem Nameserver übermittelt werden.

DNSSEC validieren

Nachdem wir nun wissen, wie eine DNSSEC-gesicherte Zone aufgesetzt wird, ist es an der Zeit DNSSEC Antworten zu validieren. Alles, was wir dazu brauchen, ist das Tool dig. Einige DNS Resolver wie Google unterstützen DNSSEC-Validierung. Wenn wir einen Request für nic.ch (ein Record mit DNSSEC) an einen Google Nameserver senden, (dig nic.ch A +dnssec +multi @8.8.8.8), taucht die Flag Authenticated Data (AD) im Response Header auf. Sie zeigt an, dass der Request validiert wurde. Wir können dig verwenden, um eine Chain of Trust in einer Domain zu validieren. Dazu benötigen wir die folgenden Befehle:

dig . DNSKEY | grep -Ev '^($|;)' > root.key
dig +multiline +sigchase +trusted-key=./root.key www.nic.ch. A

Eine DNS Response enthält nützliche Informationen, die uns helfen, ein DNSSEC-Setup selbst zu validieren. Zuerst fordern wir alle DNSKEY_-Records für _statdns.net an, indem wir die Query dig +dnssec +multiline statdns.net dnskey senden. In der Antwort finden wir alle DNSSEC-Keys der Zone, deren Key ID und den Public Key Algorithmus wie auch, logischerweise, den Public Key.

Diese Informationen werden dazu verwendet, einen DNS Record wie www.statdns.net zu validieren. Die Antwort enthält ein Key Tag, das den verwendeten Key wie auch dessen Einführung und Ablaufdatum anzeigt.

Tip für Profis: Wenn ein DNSSEC Resolver keine Daten anzeigt, da die Zonendaten invalid sind (zum Beispiel durch das Ablaufen der Signatur), dann fügen sie der DNS Query die Flag Checking Disabled hinzu. Sie erhalten die Daten dann.

Zudem gibt es zwei DNSSEC Analysetools, die online verfügbar sind. Das eine stammt von Verisign Labs Das andere von Sandia National Laboratories.

Verweise

• mattiasgeinar.be
• digitalocean.com
• zombofant.net
• RFC 4641: DNSSEC Operational Practices
• RFC 6781: DNSSEC Operational Practices, Version 2
• strotmann.de
• nlnetlabs.nl
• Registrars that support end user DNSSEC management, including entry of DS records
• DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• usenix.org
• thenoccave.com
• cisco.com
• enisa.europa.eu

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://dnssec-debugger.verisignlabs.com
• http://dnsviz.net/
• http://googleonlinesecurity.blogspot.ch/2013/03/google-public-dns-now-supports-dnssec.html
• http://gronggrong.rand.apnic.net/cgi-bin/ccpage?c=CH
• http://mattiasgeniar.be/2010/07/12/implementing-maintaining-dnssec-on-bind9-nameservers/
• http://securityblog.switch.ch/2013/02/19/dnssec-deployment-in-ch/
• http://static.usenix.org/event/lisa08/dnssec_bof.pdf
• http://strotmann.de/roller/dnsworkshop/entry/take_your_dnssec_with_a
• http://tools.ietf.org/html/rfc4641
• http://tools.ietf.org/html/rfc5155
• http://tools.ietf.org/html/rfc6781
• http://www.cisco.com/web/about/security/intelligence/dnssec.html
• http://www.ietf.org/rfc/rfc4033.txt
• http://www.ietf.org/rfc/rfc4034.txt
• http://www.ietf.org/rfc/rfc4035.txt
• http://www.ietf.org/rfc/rfc4641.txt
• http://www.irisa.fr/caps/projects/hipsor/
• http://www.thenoccave.com/2013/05/17/dnssec-complete-howto-how-dnssec-works/
• http://zombofant.net/blog/2013/8/roll-out-dnssec-with-bind-step-by-step
• https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server—2
• https://www.icann.org/resources/pages/deployment-2012-02-25-en
• https://www.nlnetlabs.nl/publications/dnssec_howto/#x1-510005.5.2