© Franz Pfluegl, Fotolia.com

Um das leicht angreifbare Uralt-Protokoll DNS abzusichern, bedarf es mehrerer Zutaten: ein stabiles Protokoll, verlässliche Nameserver, eine funktionierende Konfiguration und vor allem Schlüssel. Nach langem Zaudern sind die endlich für die Rootzone vorhanden, sodass DNSSEC praktisch starten kann.

Seit dem 15. Juli 2010 ist die Rootzone des globalen DNS signiert, dem produktiven Einsatz von DNSSEC steht damit nichts mehr im Wege. Ab dem ISC Bind 9.6.2 verfügen Systemverwalter auch über die notwendigen Tools [1] und gute Vorlagen [2].

Neben der Rootzone müssen auch die einzelnen Top Level Domains DNSSEC unterstützen. Der Status bei den verschiedenen Verwaltungsstellen ist unterschiedlich [3]: Das Denic testet noch bis Ende des Jahres [4], während die österreichischen Kollegen bei »nic.at« lesenswerte Kritik an den Sicherheitserweiterungen üben [5]. Auf Anfrage des Linux-Magazins erklärte die Registratur jedoch, bis zum ersten Quartal 2011 eine Testumgebung einzurichten. Verisign will bei den TLDs ».com« und ».net« im Laufe des Jahres 2011 bereit sein [6].

Die schweizer- und liechtensteinische Registratur Switch bietet DNSSEC seit Februar 2010 produktiv an. Auf Anfrage erklärte sie, dass von 1,5 Millionen registrierten Domains 111 über DNSSEC verfügen. Das gilt auch für TLDs wie ».biz« und ».org«. Vorreiter ist Schweden: Das Land hatte DNSSEC bereits im Februar 2007 eingeführt.

Zu groß für DNS

Der ursprüngliche DNS-Standard stößt mit DNSSEC an seine Grenzen. Bei der Verwendung von UDP besteht ein Größenlimit von 512 Bytes pro Paket. Die kryptographischen Schlüssel und Signaturen sind dafür zu groß. DNS kennt auch keine Flags, um Statusinformationen zur Validierung auszutauschen.

Die Extension Mechanisms for DNS (EDNS) aus RFC 2671 heben diese Grenzen auf und erlauben größere Pakete und neue Flags. Deshalb sind sie Voraussetzung für die Nutzung von DNSSEC. Trotz der Tatsache, dass sie bereits seit 1999 spezifiziert sind, können einige wenige aktuelle Firewallmodelle mit ihnen aber nicht umgehen. Ein Administrator tut also gut daran, seine Umgebung entsprechend zu prüfen.

Kette des Vertrauens

DNSSEC bildet mit Hilfe einer PKI eine hierarchische Vertrauenskette vergleichbar mit den X.509v3-Zertifikaten und ihren CAs fürs Web [7]. Der Standard ergänzt eine Delegation um DS-Records und deklariert damit, welcher Key Signing Key (KSK) zu der jeweiligen Subdomain gehört. In diesem Zusammenhang fällt oft der Begriff Secure Entry Point (SEP). Innerhalb der Subdomain signiert (und legitimiert) der KSK die Zone Signing Keys (ZSK). Von ihnen sind auf den einzelnen Records Signaturen zu finden. Der KSK verrichtet also vergleichsweise wenig Arbeit und ist resistenter gegenüber der Kryptoanalyse.

Die ZSK und KSK sind in jeder Domain in Form von DNSKEY-Records zu finden. Sie stehen auf derselben Stufe wie der SOA. Um Signaturen abzubilden, erhält jede Ressource einen zusätzlichen RRSIG-Record. Die DNSKEY-Records weisen RRSIGs von KSK und ZSK auf, während bei den anderen Records lediglich eine RRSIG vom ZSK zu finden ist.

Abbildung 1 zeigt, wie die Delegation von »example.org« in der übergeordneten ».org«-Domäne mit DNSSEC ergänzt wird und welcher Schlüssel dabei was signiert. Die Delegation von ».org« in der Rootzone funktioniert dazu analog. Kennt ein rekursiver DNS-Server den KSK oder den SEP der Rootzone, kann er der Kette folgen. Bei autoritativen Servern muss der Verwalter für jede Zone ein Paar aus KSK und ZSK erstellen und publizieren.

Abbildung 1: In der Kette des Vertrauens referenziert der DS-Record einer Delegation von »org.« den von der Subzone »example.org.« verwendeten KSK. Der signiert seinerseits den ZSK, um schließlich einen A-Record zu unterzeichnen.

Um zu verhindern, dass ein Angreifer zwischen Client und Resolver einzelne Antwort-Records unbemerkt unterdrückt – und so beispielsweise den Einruck erweckt, eine Subdomain sei gar nicht signiert -, kommt NSEC zum Einsatz. Weil dies seinerseits alle Records einer Zone ringförmig verkettet, wären Angreifer in der Lage, sie vollständig auszulesen. Dieses Zonewalking unterbindet die neuere Erweiterung NSEC3 [8].

Schlüssel der Rootzone

Die grundlegende DNSSEC-Funktionalität schaltet der Systemverwalter in der »named.conf« mit den beiden Anweisungen »dnssec-enable yes« und »dnssec-validation yes« im »options«-Block ein (siehe Listing 1). Die Optionen sind zwar standardmäßig aktiv, der Admin sollte sie zu Dokumentationszwecken aber explizit festhalten. Der rekursive DNS-Server benötigt auch eine Kopie des SEP oder des KSK der Rootzone. Dazu dient der »trusted-keys«-Block. Darin stehen Einträge ähnlich den DNSKEY-Records. In den Listings steht der Platzhalter KEY für den längeren Schlüsselstring.

01 options {
02   [...]
03   nssec-enable yes;
04   dnssec-validation yes;
05   [...]
06 };
07 
08 trusted-keys {
09   . 257 3 8 "KEY";
10 };

Mit »dig . dnskey | grep -w 257 > dnssec_root.key« besorgt sich der Admin den KSK direkt aus dem DNS. Durch den Aufruf landet nur der KSK (Typ 257) in der Datei »dnssec_root.key«. Der Befehl »dnssec-dsfromkey -2 dnssec_root.key« wandelt ihn in einen DS-Record um. Er enthält den Hash des KSK. Das Tool stammt aus dem Debian-Paket »bind9«, die Werkzeuge »dnssec-keygen« oder »dnssec-signzone« hingegen aus »bind9utils«. Der Administrator vergleicht den Record mit dem publizierten Hash und prüft so, ob in der Datei »dnssec_root.key« der gültige SEP steht. Die IANA erklärt auf ihrer Website ausführlich mehrere Wege zur Verifikation [9].

Ist der Schlüssel korrekt, kann der Admin den Inhalt der Datei leicht anpassen und in den »trusted-keys«-Block einpflegen (siehe Listing 2). Dazu entfernt er die TTL, die Klasse und den Namen des Record-Typs und schließt per Neustart des »named« die Konfiguration ab.

01 # Ausgabe von Dig in der Datei dnssec_root.key:
02   .             86400   IN      DNSKEY  257 3 8 KEY
03 
04 # Übernahme in die named.conf:
05   trusted-keys {
06     . 257 3 8 "KEY";
07   };

Der aktuelle Root-KSK ist voraussichtlich bis 2015 gültig. Danach müssen Systemverwalter ihre rekursiven DNS-Server anpassen. RFC 5011 definiert einen Mechanismus zur automatischen Aktualisierung des SEP. Allerdings unterstützt erst Bind 9.7 diese nützliche Funktion [10].

Auf Antwort bestehen

Nach der beschriebenen Konfiguration nimmt der Resolver die Validierung vor. Er beantwortet keine Anfragen nach ungültigen Informationen, sondern schreibt entsprechende Meldungen ins Syslog. Die Clients sind somit bereits geschützt, ohne selber DNSSEC kennen zu müssen.

Vorbereitete Clients finden jedoch dank neuer EDNS-Flags noch mehr Informationen heraus: Sie können in ihrer Anfrage mit AD (Authentic Data) um den Status der Validierung bitten oder sie mit CD (Checking Disabled) deaktivieren. In der Antwort des Resolvers bedeutet AD die erfolgreiche Verifizierung. Domains ohne DNSSEC zählen dabei nicht als erfolgreich verifiziert. Bei CD hingegen hat der Resolver die Validierung ausgelassen. In der Antwort stehen diese Flags nur, wenn der Client danach gefragt hat.

Um den eigenen Resolver zu testen, aktiviert der Admin bei Dig mit den Optionen »+ad« und »+cd« nach Bedarf eines der beiden Flags (siehe Abbildung 2). Keinen Sinn ergibt, beide Flags gleichzeitig zu setzen, da sie sich widersprechen.Dig zeigt bei seiner Ausgabe an, welche Flags der rekursive Server in seiner Antwort gesetzt hat.

Abbildung 2: Mit dem Flag »+ad« fordert Dig den Nameserver explizit auf, Antworten per DNSSEC zu validieren. Durch »+dnssec« erfährt der Client, ob sein Server das Protokoll überhaupt beherrscht. Dann erhält er signierte Records.

Mit dem dritten Flag DO (DNSSEC OK) zeigt ein Client an, dass er DNSSEC unterstützt. Erhält es der Resolver, setzt er – sofern die Validierung erfolgreich ist – das AD-Flag in seiner Antwort. Er sendet zudem auch alle für DNSSEC relevanten Records mit. Die Antwort auf die Anfrage nach einem A-Record würde also zusätzlich die RRSIG-Records enthalten. Mit der Option »+dnssec« sendet Dig das DO-Flag.

Natürlich dürfen Applikationen die neuen Flags ebenfalls nutzen. Ein gutes Beispiel dafür ist das Addon DNSSEC Validator für Firefox [11]. Es zeigt in der Adresszeile an, ob die Adresse der aktuell geöffneten Webseite per DNSSEC geschützt und authentisch ist. Auch FTP-, Mail- und VPN-Clients sowie viele andere könnten den Status beim Verbindungsaufbau prüfen.

Kryptoalgorithmen wählen

Ein Administrator muss sich neben den Resolvern auch mit seinen eigenen autoritativen DNS-Servern auseinandersetzen, damit er seine Zonen signiert publizieren kann. Er muss nach der Angabe von »dnssec-enable yes« in der Konfiguration jede Zone einzeln vorbereiten und signieren. Sich vorher ein Konzept zu überlegen ist unumgänglich.

DNSSEC unterstützt mehrere kryptographische Algorithmen. Empfohlen ist die Kombination von RSA und SHA1 mit dem Schlüsseltyp »RSASHA1«. Der unterstützt allerdings kein NSEC3. Wer dies nutzen möchte, wählt als Typ »NSEC3RSASHA1«. Einmal erstellte Schlüssel lassen sich nicht nachträglich konvertieren. Eine Mischung beider Typen in derselben Zone ist nicht empfohlen.

Der Administrator muss sich auch entscheiden, wie lange die mit den Schlüsseln erzeugten Signaturen gültig sein sollen. Sind sie abgelaufen, gelten sie als ungültig und müssen rechtzeitig erneuert werden. Ein rekursiver Server behält selbst eine abgelaufene Signatur für die Dauer der TTL im Cache.

Dies gilt auch für DS- oder DNSKEY-Records. Der Administrator publiziert deshalb mit Vorteil neue Schlüssel zuerst parallel zu den alten, wartet die Zeitdauer der TTL und erstellt erst danach Signaturen mit den neuen und alten Schlüsseln gleichzeitig. Nachdem er nochmals die Zeitdauer der TTL abgewartet hat, entfernt er die alten Schlüssel.

Schlimmer ist es, wenn ein KSK oder ZSK verloren geht. Aufgrund der TTL und des Caching wird ein Notfall-Ersatz dieser Keys nicht sofort überall sichtbar. Bei einem verlorenen KSK kommt noch hinzu, dass der Systemverwalter den DS-Record in der übergeordneten Zone ebenfalls ersetzen muss. Er könnte sich deshalb überlegen, in den DNSKEY-Records einer Zone jeweils inaktive KSK oder ZSK einzufügen. DNSSEC benutzt sie dann zwar nicht, aber sie stehen im Notfall entsprechend schnell bereit.

Ein Administrator muss sich auch darüber im Klaren sein, wie oft er seine Schlüssel wechseln will. DNSSEC setzt KSK und ZSK unterschiedlich ein: Experten empfehlen eine Lebensdauer von zwölf Monaten für KSK und von einem Monat für ZSK. Das Intervall zwischen dem Ersatz der Schlüssel hängt auch von der gewählten Schlüssellänge ab.

Der Admin hat nach eigenem Ermessen die Wahl zwischen 1024 (tief), 1300 (mittel) oder 2048 (hoch) Bit. Den eigenen Schlüssel länger als den der übergeordneten Zone zu wählen, ergibt allerdings keinen Sinn. Im Hinblick auf die Geschwindigkeit steigen die Länge der Antwortpakete und die Zeitdauer für die Verifizierung zudem mit größerer Schlüssellänge an.

Neue Schlüssel erzeugen

Ein Systemverwalter sollte diese Fragen im Hinblick auf sein konkretes Sicherheitsbedürfnis beantworten. Eine große Hilfe bei diesen Überlegungen ist RFC 4641 [12]. Wichtig ist auch, die korrekte Reihenfolge bei der Einrichtung und dem Ersatz von Schlüsseln einzuhalten. Die Abbildung 3 zeigt, dass zwischen der Publikation des DNSKEY-Record, der Signierung und dem Eintrag des DS-Record in der übergeordneten Zone jeweils die TTL der Zone abzuwarten ist. Sind mehrere TTLs in der Zone zu finden, wartet der Administrator den Ablauf der längsten ab.

Abbildung 3: Die TTL beeinflusst die Wartefristen zwischen den Schritten der DNSSEC-Umsetzung.

Einen KSK von 1024 Bit Länge für die Zone »example.org« erzeugt der Administrator mit dem Befehl:

dnssec-keygen -f KSK -a NSEC3RSASHA1
 -b 1024 -n ZONE example.org

Damit wählt er RSA und SHA1 und unterstützt NSEC3-Records. Als Ergebnis erhält er beispielsweise die Ausgabe »Kexample.org.+007+61008«, wobei die erste Zahl der Schlüsseltyp und die zweite die numerische ID des KSK ist. Im Verzeichnis entstehen außerdem zwei Dateien mit diesem Namen und den Endungen »key« und »private«, die das Schlüsselpaar des KSK enthalten.

Um einen ZSK für dieselbe Zone und mit denselben Parametern zu erzeugen, ruft der Administrator den gleichen Befehl ohne die Option »-f KSK« nochmals auf und erhält beispielsweise analog einen ZSK mit der ID 15584. Damit die Zone die beiden Schlüssel beinhaltet, fügt der Admin per »$INCLUDE«-Anweisung die beiden »key«-Dateien ein, die den DNSKEY-Record im Klartext enthalten (siehe Listing 3).

01 ; start SOA
02 $TTL    2560
03 @       IN      SOA    ns1.example.org. hostmaster.example.org. (
04                      2010092001         ; Serial
05                           43200         ; Refresh
06                            7200         ; Retry
07                         1209600         ; Expire
08                            2560 )       ; Negative Cache TTL
09 
10 $TTL 86400
11 
12 $INCLUDE /etc/bind/dnssec-keys/Kexample.org.+007+61008.key
13 $INCLUDE /etc/bind/dnssec-keys/Kexample.org.+007+15584.key
14 
15 
16 @       IN      NS       ns1.example.org.
17         IN      NS       ns2.example.org.

Zonen signieren

Aus der unsignierten Zonendatei »example.org« generiert der Administrator mit dem Befehl

dnssec-signzone -e +2592000
 -k Kexample.org.+007+61008
 -f example.org.signed example.org
 Kexample.org.+007+15584.key

das unterschriebene Pendant »example.org.signed«. Die Signaturen sind während den nächsten 2 592 000 Sekunden (30 Tage) gültig. Die Option »-k« spezifiziert den KSK (Schlüssel 61008), während das letzte Argument den ZSK (Schlüssel 15584) bezeichnet.

Nur wenn die verwendeten Schlüssel vom Typ »NSEC3RSASHA1« sind, lassen sich auch NSEC3-Records generieren. Dazu dient die Option »-3 -«, die den Salt auslässt. Die Variante »-3 $(openssl rand 4 | od -t x4 | awk ‘/0000000/ {print $2}’)« generiert zufällig einen Salt und wandelt ihn ins Hex-Format. Mit der Option »-a« lassen sich die erstellten Signaturen verifizieren und mit »-t« Statistiken anzeigen. Wer den Dateinamen der Zonendatei nicht gleichlautend mit dem Domainnamen wählt, sieht sich in der Dokumentation am besten noch die Bedeutung der Option »-o« an.

Nach dem Signieren passt der Administrator in seiner »named.conf« die Quelldatei von »example.org« an. Der Named muss diese neu aus »example.org.signed« (mit der Extension »signed«) lesen. Abgesehen davon darf der Systemverwalter die Publikation des KSK in der übergeordneten Zone nicht vergessen. Dort sind dann ihrerseits neben den NS- auch DS-Records nötig. Die meisten Registries bieten dazu Webinterfaces an.

Testen der Signaturen

Mit »rndc reload« oder einem Neustart des Named liest der Administrator die Zone aus der neuen Datei ein und prüft das Syslog auf Fehler. Der Befehl »dig +dnssec -t a www.example.org @ns1.example.org« stellt eine Anfrage an den eigenen autoritativen Nameserver. Er liefert bei korrekter Konfiguration die DNSSEC-Records zurück. Die Flags AD und CD anzugeben bringt hier übrigens nichts, da ein autoritativer Server nie seine lokalen Zonen validiert.

Um die Signatur zu prüfen, nutzt der Admin entweder einen Resolver ohne lokale Kopien der Zone oder Dig. Für Letzteres speichert er den DNSKEY-Record mit dem KSK in der Datei »mykey« ab und ruft

dig +sigchase +trusted-key=mykey -t a
 www.example.org @ns1.example.org

auf. Dig validiert dank der Option »+sigchase« selbst und nutzt dazu den angegebenen KSK (Abbildung 4).

Abbildung 4: Digs Optionsflag »+sigchase« hilft beim Testen der eigenen Zone. Hier zeigt es an, dass der signierte Eintrag von »test.example.org« abgelaufen ist. Den passende Schlüssel enthält die Datei »mykey«.

Dig kann auch von der Rootzone ausgehend den ganzen DNS-Baum bis zur eigenen Zone durchgehen und verifizieren. Der KSK der Rootzone muss in der Datei »rootkey« abgespeichert sein. Der Administrator lässt Dig mit dem Befehl

dig +sigchase +topdown +trusted-key=rootkey
 -t a www.example.org

allen Signaturen bis zur eigenen Zone folgen. Entsprechende Meldungen zeigen das Resultat dieser Verifizierung.

DNSSEC wäre, abgesehen von der regelmäßigen Erneuerung der Signaturen, nun fertig eingerichtet. Will es sich der Administrator einfach machen, lässt er den letzten Befehl zum Unterzeichnen erneut laufen. Er erzeugt alle Signaturen neu. Die Option »-N« zählt bei mehrfachem Aufruf von »dnssec-signzone« die Seriennummer der Zone hoch.

Aufgrund der Ablaufdaten der Signaturen reicht ein einmaliges Unterzeichnen nicht aus. Der Administrator muss deshalb den vorhin vorgestellten Signaturprozess regelmäßig neu absolvieren. Das Tool »dnssec-signzone« liest auch bereits beglaubigte Zonen ein und ersetzt die kurz vor dem Ablauf stehenden Signaturen. Dazu legt der Admin eine Kopie der »example.org.signed« an und gibt sie beim Signieren als Eingabedatei an. Die Kriterien, anhand derer das Programm eine Signatur zur Erneuerung auswählt, lassen sich im Handbuch nachschlagen.

Abläufe automatisieren

Über ein Makefile lässt sich die Wartung einer signierten Zone automatisieren. Wer mehr Komfort will, nutzt die DNSSEC Zone Key Tools [13]. Sie enthalten einfach einsetzbare Kommandos, die vom Erzeugen über das Roll-over von Schlüsseln bis zur Erneuerung der Signaturen alles bieten.

Der Befehl »zkt-conf -w -d« legt eine Beispielkonfiguration in der Datei »dnssec.conf« im Standardpfad »/var/named« ab. Dort lassen sich Schlüsselparameter und Lebensdauer von Signaturen einstellen. Ihre Option »ZoneDir« legt den Pfad zu den Zonendateien fest. Unter ihm erwartet ZKT etwa in »example.org/zone.db« die Zone von »example.org«.

Nach einem Wechsel in ein solches Unterverzeichnis legt der Befehl »zkt-conf -w zone.db« eine zusätzliche »dnssec.conf« an. Sie beinhaltet zonenspezifische Parameter, die sich anpassen lassen. Neben der »zone.db«-Datei muss zudem eine leere »zone.db.signed« zu finden sein.

Wechselt der Administrator nach der Einrichtung der Zone zurück ins »ZoneDir«, unterzeichnet er sie mit dem Befehl »zkt-signer -f -v -v«. ZKT merkt, wenn der KSK oder ZSK fehlen, und erzeugt sie dann neu. Beim ersten Aufruf ist die Option »-f« nötig, die routinemäßige Erneuerung der Signaturen später kommt ohne die Option aus. Den Schlüsselstatus zeigt »zkt-ls« an, zum Erzeugen und zur Statusänderung gibt es »zkt-keyman«.

DNSSEC ist bereit

Die Standardisierung von DNSSEC ist abgeschlossen, die Rootzone ist signiert und der ISC Bind wird sich in seiner Implementation nicht mehr signifikant verändern. Noch sind zwar nicht alle TLDs bereit, dennoch lohnt es bereits jetzt, sich um eine funktionierenden DNSSEC-Konfiguration zu kümmern. Die gesammelten Erfahrungen nützen Anwendern schon heute und die Namensauflösung ist für die Zukunft gerüstet. (mg)