DNSSEC (manuell) mit BIND Werkzeugen

ACHTUNG: In der kompletten Notiz wird die Domain “example.com” als Platzhalter verwendet.

Es wird im folgenden davon ausgegangen, dass bereits ein DNS Server konfiguriert ist, der DNSSEC Validierung durchführt, und nur eine bestehende Zone mittels DNSSEC abgesichert werden soll.

Die verwendeten Schlüssel können in 2 Kategorien unterteilt werden:

• Key Signing Keys (KSK): Mit diesen Schlüsseln werden nur die Zone Signing Keys signiert. Fingerprints zu diesen Schlüsseln werden in der Parent Zone in DS Records untergebracht. Eine Änderung der KSK setzt also eine Interaktion mit der Parent Zone voraus.
• Zone Signing Keys (ZSK): Mit diesen Schlüsseln werden die einzelnen Zonen Einträge signiert. Nach jeder Zonenänderung muss diese neu signiert werden. Desweiteren hat eine Signatur eine begrenzte Lebensdauer (im Normalfall von max. 30 Tagen), nach denen ebenfalls eine neue Signatur benötigt wird.

Für den Wechsel der KSK stehen 2 Modelle zur Verfügung:

• Das parallele Signieren der Zone (für eine Mindestzeit der größten TTL innerhalb der Zone) mit zwei verschiedenen KSKs, um eine gültige Signatur auch dann zu gewährleisten, wenn der Nutzer die neuen Schlüssel noch nicht kennt.
• Das Pre-Publishing neuer Schlüssel (für eine Mindestzeit der größten TTL innerhalb der Zone), wobei der alte Schlüssel während der parallelen Veröffentlichung, der neue Schlüssel nach Ablauf der parallelen Veröffentlichung zur Signatur der Zone verwendet wird.

Im folgenden wird eine Methode beschrieben, bei der jeweils ein aktiver und ein pre-published Key (sowohl KSK als auch ZSK) verwendet wird.

Erstellen und veröffentlichen der Schlüssel

Zuerst müssen je 2 ZSK und KSK erstellt werden, wobei davon ausgegangen wird, dass sich diese in einem Verzeichnis “example.com” relativ zum Zonefile befinden. Die Zone Signing Keys (ZSK) werden mit den folgenden Kommandos erzeugt:

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com

Hierbei werden 2 Schlüssel Kexample.com.+005+53508 sowie Kexample.com.+005+22950 erstellt. Nun werden die Key Signing Keys (KSK) erstellt:

dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.com
dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.com

Hierbei werden 2 Schlüssel Kexample.com.+005+51601 sowie Kexample.com.+005+53053 erstellt

Die öffentlichen Schlüssel (im Beispiel Kexample.com.+005+53508.key (aktiver ZSK), Kexample.com.+005+22950.key (Standby ZSK), Kexample.com.+005+51601.key (Aktiver KSK), Kexample.com.+005+53053.key (Standby KSK)) müssen in die Zone inkludiert werden. Hierzu können entweder die Einträge aus den Key Dateien in das Zonefile kopiert oder einfacher mittels der $include Anweisung in selbige inkludiert werden. Hierbei darf nicht auf das Updaten der Seriennummer vergessen werden!

$include "./example.com/Kexample.com.+005+53508.key"
$include "./example.com/Kexample.com.+005+22950.key"
$include "./example.com/Kexample.com.+005+51601.key"
$include "./example.com/Kexample.com.+005+53053.key"

Durchführen der Signatur

Nun wird die Zone (im folgenden wird davon ausgegangen, dass das nicht signierte Zonefile example.com.master heißt) mit dem aktiven KSK und aktiven ZSK signiert:

dnssec-signzone -a -e +3024000 -t -o example.com -k ./example.com/Kexample.com.+005+51601 example.com.master ./example.com/Kexample.com.+005+53508

Die -k Option wählt hierbei den zu verwendenden Key-Signing-Key aus, wobei auch mehrere KSKs (mit mehreren -k Optionen) angegeben werden können, wenn die Zone mit mehreren Schlüsseln parallel signiert werden sollen. Dies ist bei pre-publishing allerdings nicht notwendig. Der am Ende des Kommandos angegebene Schlüssel ist der zu verwendende Zone Signing Key.

Im Beispielkommando wird die Option -e +3024000 angegeben, mit deren Hilfe die Gültigkeit der Signatur auf 35 Tage gesetzt, um eine Neusignatur nur jedes Monat vornehmen zu müssen. Wird diese Option nicht gesetzt, ist die Gültigkeitsdauer auf 30 Tage beschränkt.

Nach der Erfolgreichen Signatur wurde die Zonendatei example.com.master.signed erzeugt, die nach der ersten Publikation der DS Records in der Elternzone statt der ursprünglichen example.com.master Zonendatei durch named ausgeliefert werden muss.

ACHTUNG: Das hier gezeigte signzone Kommando verwendet NSEC Signaturen anstelle der neueren NSEC3 Signaturen. Diese sind zwar auch mit älteren DNSSEC Tools erstellbar, erlauben aber das Enumerieren der Zone, da NSEC Records im Falle ungültiger Ressource Records an den Abfragenden geliefert werden, um die Authentizität der NXDOMAIN Antwort zu bestätigen. Bei NSEC3 Signaturen wäre bereits eine Berücksichtigung bei der Erstellung der Schlüssel sowie die Option “-3” gefolgt von einem entsprechenden zufälligen Initialisierungswert, der sich bei jeder Signatur ändert notwendig.

Nur nach der ersten Signatur / nach dem Wechsel von KSKs

Um die KSKs auch in der Elternzone zu publizieren, werden DS Records benötigt. Diese werden von dnssec-signzone in der Datei dsset-example.com. gespeichert und müssen nach der ersten Signatur mit den KSKs publiziert werden. Zusätzlich erstellt dnssec-signzone eine weitere Datei keyset-example.com., in der alle verwendeten DNSKEY Resource Records enthalten sind.

Automatisierung

Im einfachsten Fall bietet sich die periodische Neusignatur mittels Shellscript einmal im Monat an. Nach jeder Änderung in der Zone muss dennoch eine (manuelle) Signatur erfolgen.

Verifizierung

Um zu prüfen, ob DNSSEC korrekt funktioniert kann ein Service wie DNSViz genutzt werden. Dieses versucht alle Signaturen von der Root Zone an zu verifizieren. Eine Ausgabe kann zum Beispiel wie in der folgenden Grafik dargestellt aussehen:

This article is tagged:

• Computer
• Administration
• Security
• Cryptography