Domain Name System absichern mit DNSSEC

Inhaltsverzeichnis

Eines der zentralen, aber noch weitgehend ungesicherten Elemente des Internet ist das Domain Name System (DNS). Es stellt eine Datenbank dar, die online über Bezüge zwischen lesbaren Maschinennamen und IP-Adressen Auskunft gibt. Zum Beispiel erreichen Browser den Dienst heise online, indem sie zunächst einen Nameserver des DNS befragen, auf welche IP-Adresse der Webserver www.heise.de hört (DNS-Query). Der Nameserver fischt aus seiner Datenbank (der Zonendatei) die zugehörigen Einträge heraus (Ressource Records) und sendet sie zum Client (DNS-Response). Aus dem Response-Paket entnimmt der Client die IP-Adresse und steuert diese dann an (zurzeit 193.99.144.85).

Normalerweise läuft diese Kommunikation zwischen Client und Nameserver über das User Datagram Protocol ab (UDP). Das hat ein gravierendes Manko: Das Protokoll sieht eine Überprüfung der Identität des Absenders nicht vor; die Absenderadresse eines UDP-Päckchens kann sogar beliebig eingetragen werden, weil dem inzwischen dafür genutzten Feld ursprünglich gar keine Funktion zugedacht war. Der Empfänger kann also nicht überprüfen, ob eine DNS-Antwort vom befragten DNS-Server stammt und schon gar nicht, ob sie vertrauenswürdig ist.

Mangels Sicherheitsvorkehrungen kann ein Angreifer, der sich in die Kommunikation zwischen DNS-Server und Client einschaltet, dem Empfänger eine andere IP-Adresse unterjubeln und diesen so in eine Falle locken. Man möchte aber doch sehr sicher sein, dass der eigene Browser beispielsweise bei www.meine-bank.de vom DNS wirklich zur richtigen IP-Adresse geleitet wird und nicht in eine Falle tappt. Die Browser-Interaktion ist nur ein Beispiel für das Gefährdungspotenzial, das ein ungesichertes DNS birgt; im Grunde sind sämtliche Internet-Anwendungen gefährdet, also auch Mail-, VoIP-, Filesharing- oder VPN-Programme.

Experten haben früh erkannt, dass hier Handlungsbedarf besteht. So kam es bereits 1997 zu einer ersten Definition der Domain Name System Security Extensions (DNSSEC) im RFC 4034. Diese Fassung funktionierte jedoch nur in kleinen Netzen; bei großen überforderte das geschwätzige Protokoll die Domain Name Server. Nach verschiedenen Überarbeitungen liegt seit März 2005 die aktuelle Version vor, bekannt auch unter der Bezeichnung DNSSEC-bis. Mit DNSSEC signiert der Administrator einer Domain die Namenseinträge in seinem Nameserver kryptografisch. Dafür werden zusätzliche Ressource Records angelegt, sodass DNSSEC-Antworten länger sind als herkömmliche DNS-Antworten. Die zusätzlichen DNS-Records werden bei Anfragen als Bestandteile des DNS-Response versendet, sodass Empfänger zunächst prüfen können, ob der Response integer, also unverfälscht ist. Weil der Response auch ein Zertifikat enthält (einen signierten kryptografischen Schlüssel), kann der Empfänger in einem zweiten Schritt auch den Absender verifizieren und so feststellen, ob die im Paket enthaltene Information vertrauenswürdig ist.

Die Signatur der Pakete ist das Resultat einer Hash-Funktion. Der Empfänger kann den Hash des Paketinhalts selbst mit derselben Hash-Funktion gegenrechnen; stimmt sein Resultat mit der Signatur überein, gilt das Paket als unverfälscht. Den Absender des DNS-Response überprüft der Empfänger anhand des Zertifikats. Das Zertifikat weist den Inhaber als Element einer Vertrauenskette aus (Chain of Trust). Dabei stellt der Administrator einer übergeordneten Domain seinen unterstellten Domains Zertifikate aus; er signiert die kryptografischen Schlüssel der untergeordneten Administratoren. Den Hauptschlüssel einer Vertrauenskette hat die oberste Instanz, die Domain-Verwaltung (Registry). Beispielsweise ist die Registry der .de-Domain für die Zertifizierung aller Domains mit der Endung .de zuständig.

Viel Zeit wurde darauf verwendet, das Verfahren abwärtskompatibel zum herkömmlichen DNS zu machen, damit ältere Geräte oder Programme, die noch vor der Spezifikation der DNSSEC-Erweiterungen entwickelt wurden, weiterhin funktionieren. Solche Geräte und Programme ignorieren die neuen DNS-Records, während die modernen, die gemäß der DNSSEC-Spezifikation entwickelt worden sind, damit die Echtheit der Antwort überprüfen können. Die DNS-Abfrage (Query) ist gegenüber dem herkömmlichen DNS-Verfahren unverändert.

Einige wenige Domains wurden schon früh auf DNSSEC aufgerüstet. Seit Anfang 2007 sendet zum Beispiel die Top Level Domain (TLD) Schwedens (.se) signierte DNS-Pakete. Bei der Einführung kam es zwar hier und da zu Problemchen, aber sie ließen sich leicht beseitigen, sodass seither alle .se-Domains reibungslos funktionieren. Daraufhin hat man in Schweden DNSSEC auch für Subdomains eingeführt – und dieser Schritt verlief ebenso problemlos.

DNSSEC: Zwickmühle

Zwickmühle

Bis man DNSSEC in der Form hatte, wie es jetzt ist, mussten etliche Hürden überwunden werden. Zu Beginn der Entwicklung stand die Suche nach einem geeigneten Verfahren. Dabei kam man ziemlich schnell zur asymmetrischen Kryptografie. Grundsätzlich betrachtet setzt das Verfahren ein Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel ein (Private und Public Keys), um Nachrichten zu signieren und deren Echtheit zu prüfen.

Bei diesem Prinzip werden beliebige Nachrichten mit dem privaten Schlüssel signiert: Zuerst wird ein Fingerabdruck der Nachricht berechnet (Hash) und dann verschlüsselt; das Resultat wird Signatur genannt. Sie wird der Nachricht hinzufügt. Wenn der Empfänger den zugehörigen öffentlichen Schlüssel hat, kann er damit die Nachricht entschlüsseln und prüfen, ob sie unversehrt ist — er berechnet dafür selbst den Fingerabdruck der Nachricht. Ist der berechnete mit dem gesendeten identisch, gilt die Nachricht als unverändert. Wenn der Absender dem Empfänger bekannt ist und sichergestellt ist, dass nur der Absender Zugriff auf seinen privaten Schlüssel hat, kann der Empfänger zudem eindeutig auf den Verfasser der Nachricht rückschließen. Damit Nachrichten nur berechtigte Personen signieren können, hält man den privaten Schlüssel also geheim.

Die Sicherheit, die die asymmetrische Kryptografie bietet, nimmt mit der Länge der Schlüssel zu – aber mit der Schlüssellänge steigt auch der Rechenaufwand drastisch, sodass dafür teure Hardware erforderlich ist. Als zu Beginn der 1990er Jahre das DNSSEC-Verfahren langsam Form annahm, wurde schnell klar, dass die hohen Investitionen kaum einer der großen Domain-Betreiber aufbringen wollte, sodass das DNSSEC-Verfahren auf der Kippe stand. Ein Ausweg aus dieser Zwickmühle wäre eine Methode mit kürzeren Schlüsseln gewesen, bei der die Schlüssel immer mal wieder gewechselt werden, damit Angreifer möglichst wenig Zeit haben, sie zu knacken.

Diese Auslegung allein genügte jedoch nicht, denn bei näherem Hinsehen stellte sich heraus, dass der einfache Kompromiss lediglich den Aufwand verlagern würde: Die kürzeren Schlüssel würden den Betreibern zwar die Anschaffung teurer Hardware ersparen, aber den Administratoren zusätzliche Arbeit aufbürden, weil jeder neue Schlüssel vom übergeordneten Administrator signiert werden muss. Für sich betrachtet ist das ein einfacher Vorgang. Bei hunderten oder tausenden Domains wird der Aufwand für den Schlüsseltausch aber einfach zu hoch.

Mit einem weiteren Trick lässt sich aber auch dieser Aufwand verringern: Man setzt zwei verschiedene Typen von Schlüsseln ein, nämlich einen langen Key Signing Key von langer Lebensdauer (KSK, z. B. 2048 Bit) und einen kurzen Zone Signing Key von kurzer Lebensdauer (ZSK, z. B. 512 Bit zum Signieren der DNS-Records), jeweils als privat und öffentlich ausgeführt. Mithin hat eine Domain mindestens vier Schlüssel. Um den gleitenden Wechsel von einem abgelaufenen zu einem neuen Schlüssel zu gewährleisten, hat eine Domain in der Regel sogar mehrere Exemplare gleichzeitig, auch mehrere KSK (sinnvoll, um unterschiedliche Signieralgorithmen nutzen zu können).

Wenn der Domain-Betreiber seinen aktuellen KSK dem Administrator der übergeordneten Domain bekannt gegeben hat, kann er mit diesem anschließend alle Schlüssel der eigenen Zone signieren und nutzen. Alle anderen Daten der Zone werden mit dem aktuellen ZSK signiert. Neue ZSK kann man nach Gutdünken erzeugen und ohne Meldung gegenüber der Registry nutzen. Die übergeordnete Domain erkennt selbstständig, dass sie gültig sind, wenn man sie mit dem aktuellen KSK signiert hat, weil ihr dieser ja gemeldet worden ist. Ist ein Nameserver auf DNSSEC umgestellt, liefert er ausschließlich signierte Antworten.

Eine Besonderheit der ersten DNSSEC-Version hat zu vielen Problemen und letztlich zu der Neuimplementation vom März 2005 geführt: Im DNS gibt es keine Möglichkeit, dem Empfänger mitzuteilen, dass eine bestimmte Domain nicht existiert. Wenn ein DNS-Server eine Anfrage für eine Domain erhält, die er nicht kennt, antwortet er sinngemäß "keine Ahnung". Zum Beispiel würde ein .se-Nameserver die Anfrage nach der nicht existierenden Domain zzz.se mit der Meldung „Name Error: The domain name does not exist on this server“ beantworten. Für den anfragenden Client bleibt aber unklar, ob es die Domain wirklich nicht gibt oder ob sich der befragte Server nicht zuständig fühlt, die Anfrage zu beantworten. Um präzisere Antworten zu ermöglichen, hat man deshalb den NSEC-Record eingeführt, mit dem ein DNSSEC-Server explizit mitteilt, dass eine Domain nicht existiert.

Doch leider hatten es die Vordenker mit NSEC zu gut gemeint: Der Server teilt nämlich ungefragt auch noch mit, welche Domains der gesuchten am nächsten kommen; er liefert eine alphabetisch sortierte Liste – über eine Reihe von Anfragen lässt sich also die komplette Liste einer Zone ermitteln (Zone Enumeration, Zone Walking). Das dürfte für den Server von kleinkleckersdorf.de kein Problem sein, denn er wird ohnehin nur wenig frequentiert und deshalb wird er NSEC-Antworten selten liefern. Eine Registry wie DE-NIC mit über 12 Millionen Subdomains sieht das aber nicht ganz so gelassen. Viele Domain-Betreiber betrachten ihre Zonendatei als ein Geschäftsgeheimnis und lehnen NSEC schon deshalb ab. Aber vor allem störten sie sich daran, dass Zone Walking die Last auf den Servern drastisch erhöht hätte. Erste Tools zum automatischen Zone Walking wurden bereits kurz nach Fertigstellung der NSEC-Erweiterung veröffentlicht.

Deshalb lehnten die großen und länderspezifischen Domain-Betreiber NSEC und damit auch DNSSEC zunächst ab – ohne die ganz großen Mitspieler wäre DNSSEC aber kein Erfolg beschieden. Also wurde mit NSEC3 eine überarbeitete Spezifikation entworfen (auch als Hashed Authenticated Denial of Existence bekannt). Diese ist seit März 2008 festgeklopft und unter den Domain-Betreibern akzeptiert. Mit NSEC3 kann ein Server dem Client weiterhin eindeutig mitteilen, wenn eine Domain nicht existiert, aber er plappert nicht ungefragt weitere Domain-Namen aus (RFC 5155).

DNSSEC: Wartungsintervalle

Wartungsintervalle

Den größten Unterschied zwischen einem "normalen" DNS-Server und einem DNSSEC-Server stellt der ständige Bedarf an Aufmerksamkeit dar. Eine kleine Zone mit nur wenigen Updates, etwa Änderungen von IP-Adressen, kann viele Jahre ohne Administratoreingriffe auf einem DNS-Server laufen. Mit DNSSEC wird das anders, denn DNSSEC signiert alle DNS-Daten, und weil alle Signaturen nur eine begrenzte Lebensdauer haben, müssen sie regelmäßig erneuert werden. Sicherlich könnte man die Lebensdauer auch auf zehn Jahre setzen, aber das würde die Sicherheit einer Zone kompromittieren, sodass man dann DNSSEC ebensogut abschalten könnte.

Um die repetitive Verwaltung zu vereinfachen, braucht es also neue, möglichst automatische Abläufe. Aus Sicherheitsgründen geht aber nicht alles automatisch. So sollte man keine privaten Schlüssel auf dem DNSSEC-Server speichern, denn ein Einbrecher könnte so Zugriff auf die Zonendaten erhalten. Vielmehr sollten die Schlüssel auf einem mobilen Datenspeicher liegen (USB-Stick, CD …) – was bedeutet, dass man ihn zum Signieren jedes Mal aufs Neue auf dem Server mounten und anschließend entfernen muss. Gleiches gilt für kommerzielle DNSSEC-Appliances, bei denen der Schlüssel zum Beispiel auf einer Smartcard gespeichert wird. Zwar sind die Daten auf einer Smartcard ziemlich sicher aufbewahrt, aber die Einträge der Zonendatei müssen wiederum manuell signiert werden – und das ist nur bei Zonen mit wenigen Änderungen praktisch. Eine Registry oder ein großer Hoster muss den Vorgang automatisieren, was gegenwärtig mit Smartcards nicht geht.

Bei hohen Sicherheitsanforderungen empfiehlt es sich, die Zonendatei auf einem anderen Rechner zu signieren; die signierte Datei kopiert man dann zurück zum DNSSEC-Server – womit der Aufwand damit noch ein wenig zunimmt.

Die Top Level Domain .SE führt zum Beispiel einen eigenen Server, der nur für die Übertragung von Zonendateien im Netzwerk genutzt werden kann; das stellt eine spezielle Firewall-Konfiguration sicher. Alle zwei Stunden holt sich der Server eine neue Zonendatei, signiert sie und kopiert das Ergebnis zurück. Allen übrigen Netzwerkverkehr von und zu der Maschine unterbindet die Firewall. Änderungen zum Beispiel des Schlüssels sind nur auf der lokalen Konsole des Administrators in einem zutrittsgesicherten Raum möglich.

DNSSEC-Schlüsselpositionen

Schlüsselpositionen

Den ZSK zu erneuern ist zumindest auf Linux-Rechnern, auf denen die wesentlichen DNSSEC-Techniken und Programme etabliert wurden, nicht sonderlich schwierig. Mit Hilfe der Tools, die zu Nameservern wie BIND oder Unbound gehören, erzeugt man einen neuen Schlüssel, fügt ihn der Zonendatei hinzu, signiert den Eintrag mit einem gültigen KSK und schon kann er verwendet werden – jedenfalls in der Theorie. In der Praxis muss man wegen der auf vielen Ebenen verteilten DNS-Caches teilweise sehr lange warten, bis ein ZSK-Update überall angekommen ist, sodass man den neuen Schlüssel nicht sofort nutzen kann.

Ab wann er sich schadlos nutzen lässt, kann man aber hinreichend genau anhand von TTL-Werten der Einträge in der Zonendatei bestimmen (Time To Live, Dauer der Gültigkeit). Die TTL kann zwar durchaus auf mehrere Jahre gesetzt werden (maximal sind 232–1 Sekunden möglich !!!soll heissen 2 hoch 32 -1), aber das ist nicht empfehlenswert. Üblicherweise beträgt die TTL 24 Stunden. Beim ZSK-Wechsel geht man in der Praxis vom doppelten Wert der längsten in der Zonendatei verwendeten TTL aus. Bis dahin sollten alle interessierten Resolver (Namensauflöser) den neuen ZSK verinnerlicht haben – und erst ab diesem Zeitpunkt signiert man alle Daten mit dem neuen ZSK. Den alten ZSK belässt man noch in der Zonendatei, damit alte, in Caches befindliche Signaturen noch eine Weile gültig sind. Erst wenn ein weiterer TTL-Zyklus verstrichen ist, tilgt man den alten ZSK aus der Zonendatei.

Wenn während der TTL-Wartefrist DNS-Anfragen eingehen, entsteht eine knifflige Situation, denn die neue Signatur gilt ja noch nicht und die alte würde erneut bei irgendeinem Resolver im Cache landen und so die Frist verlängern. Die DNSSEC-Väter haben sich aus dieser Klemme herausgewunden, indem sie für eine Weile gleichzeitig zwei gültige Schlüssel zugelassen haben – den alten und den aktuellen. Während der TTL-Frist werden nun alle Antworten mit beiden Schlüsseln signiert und beide Signaturen mit der Antwort geschickt. Ein Resolver, der den alten Schlüssel im Cache hat, kann damit also die Antwort wie bisher verifizieren. Ein Resolver, der den alten Schlüssel nicht hat, kann die Antwort mit einem der beiden Schlüssel verifizieren. In beiden Fällen legen die Resolver aber beide Schlüssel in den Cache ab. Wenn dann bei der nächsten Anfrage die Signatur mit dem alten Schlüssel fehlt, hat der Resolver bereits den neuen und kann damit die Antwort verifizieren.

Bei der Erneuerung des KSK muss man äußerste Vorsicht walten lassen, denn Fehler können komplette Domains lahmlegen und das unter Umständen für sehr lange, wenn der TTL-Wert hoch ist. Der Vorgang ähnelt aber der ZSK-Erneuerung – man erzeugt einen neuen Schlüssel, fügt ihn der Zonendatei hinzu und signiert ihn dort mit dem alten KSK. Zusätzlich muss der neue KSK aber auch alle anderen KSK und alle ZSK der betreffenden Zone signieren. Anschließend wartet man wieder eine TTL-abhängige Frist ab und kontaktiert dann die Registry, damit dort der neue KSK aufgenommen wird. Nach einer weiteren Wartezeit kann der alte KSK entfernt werden.

DNSSEC kontrolliert Abschalten

Kontrolliertes Abschalten

Soll das DNSSEC-Verfahren für eine Domain abgeschaltet werden, etwa wegen ADSL-Routern, die mit DNSSEC Probleme haben, muss zunächst die Registry den KSK aus ihrer Datenbank löschen. Andernfalls, also wenn der Domain-Betreiber den ZSK und KSK unkoordiniert aus seiner Zonendatei tilgt, kann seine Domain nicht mehr erreicht werden: Die Registry teilt nämlich bei Anfragen weiterhin mit, dass die betreffende Zone DNSSEC-gesichert ist, und deshalb behandeln Clients DNS-Antworten ohne DNSSEC-Daten als Fälschungen und verwerfen sie. Daher wartet man ab, bis der KSK aus der Registry gelöscht ist, kalkuliert wie üblich eine TTL-abhängige Frist ein und entfernt, wenn diese verstrichen ist, alle Schlüssel und Signaturen gefahrlos aus der Zonendatei.

Aus Sicherheitsgründen sollte jeder KSK von Zeit zu Zeit erneuert werden. Wenn ein KSK aber in einem Resolver fest eingetragen ist, wird der Resolver bei einem KSK-Wechsel alle mit dem neuen KSK signierten Antworten als gefälscht verwerfen. Der Administrator eines Resolvers muss daher den Schlüsseltausch aller ihm unterstellten Domains überwachen, andernfalls sind diese nicht mehr erreichbar – im Falle der Domain .se also ein ganzes Land. Top Level Domains veröffentlichen ihre neuen Schlüssel deshalb mit reichlich Vorlauf, damit Resolver-Administratoren Zeit genug haben, die Änderungen zu übernehmen.

Probleme

DNSSEC ist nicht problemfrei. Das erste und auffälligste Problem betrifft die Zonendatei. Durch die Signatur wächst sie auf ungefähr den dreifachen Umfang gegenüber der Zonendatei ohne Schlüssel. Die weitaus meisten Domain-Betreiber wird das kaum stören, denn weil deren Domains klein sind, ist es auch die Zonendatei. Für Registries spielt es aber schon eine Rolle, denn deren Zonendateien können schon ohne DNSSEC leicht mehrere Gigabyte groß sein – unter Umständen müssen sie also ihre Server-Hardware an die erhöhten Anforderungen anpassen.

Herkömmliche Resolver eignen sich für die DNSSEC-Anforderungen nicht; sie sind nicht für die aufwendigen kryptografischen Operationen ausgelegt, sodass man sie auf einen Schlag ersetzen müsste. Weil das teuer ist, kann man sie jedoch auch im herkömmlichen DNS-Modus weiterbetreiben (Stubresolver) und für die Verifizierung der signierten DNS-Antworten einen spezialisierten Resolver anschaffen – mehrere Stubresolver stützen sich dann auf einen zentralen Server. Diese Kommunikation ist jedoch eine Schwachstelle, denn prinzipiell können auf diesem Wege doch verfälschte DNS-Antworten eingeschleust werden. Man nimmt das Risiko aber zu Gunsten niedrigerer Kosten in Kauf.

Denial-of-Service-Attacken werden durch den erhöhten Rechenaufwand erleichtert. Wenn man davon ausgeht, dass die Nameserver-Hardware mit DNSSEC näher am Leistungslimit arbeitet, genügen weniger Angriffe, um sie lahmzulegen.

DNSSEC: Router-Inkompatibilität

Router-Inkompatibilität

Das bedeutet, dass der Betreiber eines Resolvers die Signaturen aller Top Level Domains manuell eintragen muss. Bei über 240 Landes-Domains ist das schon aufwendig und diese Schlüssel müssen auch noch aktuell gehalten werden. Man kann daher annehmen, dass ohne die Signatur der Root-Zone DNSSEC nur zögerlich angenommen wird. Bereits während der ersten DNSSEC-Inbetriebnahmen sind einige Fehler aufgefallen. Die wohl schwerwiegendsten betreffen DSL-Router. Nachdem die schwedische Gemeinde Gävle ihre Domains auf DNSSEC umgestellt hatte, konnte etwa die Hälfte aller Mitarbeiter nicht mehr von zu Hause auf die Server der Gemeinde zugreifen. Betroffen waren ausschließlich Kunden des Internet-Providers Telia. Analysen brachten zutage, dass der vom Provider verwendete Resolver fehlerhafte DNS-Antworten verschickte – immerhin konnte der Hersteller den Fehler innerhalb von 24 Stunden beseitigen, sodass der Internet-Zugriff von da an für die Telia-Kunden reibungslos klappte.

Als Nebenprodukt dieser Tests wurde aber festgestellt, dass viele DSL- und WLAN-Router nicht mit DNSSEC-Antworten umgehen können. DNSSEC ist nicht nur zur Absicherung zwischen Servern gedacht, sondern auch zur Sicherung von Applikationen. Ein Browser zum Beispiel soll so die Echtheit von DNS-Antworten überprüfen können, ist aber darauf angewiesen, dass der vorgeschaltete Router die DNS-Pakete unangetastet durchlässt.

Die aktuelle Generation der DSL- und WLAN-Router ist dafür aber kaum geeignet. Etliche Modelle lassen DNS-Antworten nicht durch, wenn sie größer sind als ein UDP-Paket, andere sieben DNS-Antworten aus, die wegen DNSSEC zusätzliche Informationen enthalten und bei ganz missratenen Geräten ist der Resolver gegenüber dem Internet geöffnet: Der Router beantwortet also DNS-Anfragen aus dem Internet und kann daher für DDos-Attacken missbraucht werden.

DNSSEC: Gehversuche

Gehversuche

DNSSEC baut auf der Verifikation von Schlüsseln auf: Jeweils die übergeordnete Instanz bestätigt die Echtheit der Schlüssel der ihr untergeordneten Instanzen. Im DNS ist die oberste Instanz die Root-Zone. Diese muss also die Echtheit von Schlüsseln aller Top Level Domains bestätigen (.de, .se, .com …). Die Root-Zone wird vom ICANN kontrolliert und dieses hat in Zusammenarbeit mit dem Unternehmen VeriSign im Oktober 2009 erstmals konkrete Pläne vorgelegt, die Root-Zone zu signieren. Über den Plan und den Fortgang der Prüfungen informiert das ICANN auf einer eigens angelegten Web-Site (http://www.root-dnssec.org/). Wenn die diversen mehrstufigen internen Tests erfolgreich verlaufen, soll die Root-Zone ab Juli 2010 per DNSSEC abgesichert sein.

Da die Eingriffe ins DNS erheblich sind und bei Fehlern die Abfragen ganzer Zonen blockiert werden können (und somit die darin aufgeführten Server bis zur Reparatur der Zone nur noch direkt anhand ihrer IP-Adresse erreichbar sind), soll der Roll-Out in kleinen Schritten erfolgen. Nacheinander werden ab Januar die Rootserver L, J, M, I, D, K und so weiter signierte Antworten ausgeben. Einen möglichen Stopp des gesamten Roll-Outs für den schlimmsten Fall hält man sich offen: Bis Juli werden nämlich nur nicht validierbare Schlüssel verwendet. So lässt sich eine signierte Zone jederzeit schadlos zurückziehen.

Den Masterschlüssel für die Rootzone, also den Key Signing Key, hütet die Internet-Verwaltung ICANN. Alle zwei bis fünf Jahre soll ein neuer Masterschlüssel erzeugt werden; bei Notfällen kann dies auch in kürzeren Zeiträumen passieren. Die Elemente, die die zur Signatur- und Schlüsselgenerierung vorgesehene Hardware freischalten, liegen in verschlossenen Boxen bei der ICANN. Die Schlüssel zu diesen Boxen verwahren sieben von der ICANN als besonders vertrauenswürdig eingestufte Personen aus der ganzen Welt. Um einen neuen Masterschlüssel zu erzeugen, müssen mindestens fünf dieser Schlüsselbewahrer anwesend sein und mindestens drei für neue Signaturen. Ähnliche Verfahren gibt es bei VeriSign für das Management des Rootzonen-Schlüssels (Zone Signing Key, ZSK). Anders als der Key Signing Key wird dieser viermal im Jahr ausgetauscht.

Auch die deutsche Internet-Verwaltung DeNIC plant, DNSSEC einzuführen. Erste Tests laufen seit Dezember 2009. So können Provider seitdem zwei eigens aufgesetzte Testserver mit Bind und Unbound in Frankfurt und Amsterdam ansprechen. Signierte Antworten liefern dieser beiden Testserver ab Januar. Der Test soll bis Anfang 2011 laufen. Erst dann wird über den Wirkbetrieb entschieden.

Das kleine DNSSEC-Einmaleins

Das kleine DNSSEC-Einmaleins

Erste Schritte mit DNSSEC kann man auch im heimischen LAN üben. Im Weiteren erklären wir, wie man den sehr weitverbreiteten DNS-Server BIND für DNSSEC aufsetzt. Da DNSSEC in ersten BIND-Versionen nicht oder nur fehlerhaft unterstützt wird, setzen wir mindestens Version 9.4.2 voraus. Wir gehen davon aus, dass eine Zone namens example1.com eingerichtet ist, die Zonendatei im Verzeichnis /etc/bind liegt und example1.com heißt. Die Zonendatei kann beispielsweise so aussehen:

$TTL 1W

@ IN SOA ns1.example1.com. mail.example.com. ( 

2007100801 ; serial 

28800 ; refresh (8 Stunden) 

7200 ; retry (2 Stunden) 

604800 ; expire (1 Woche) 

39600 ; minimum (11 Stunden) 

)

example1.com. IN NS ns1.nameserver1.tld.

example1.com. IN NS ns2.nameserver2.tld.

example1.com. IN MX 10 mx1.mailserver1.tld.

example1.com. IN MX 20 mx2.mailserver2.tld.

example1.com. IN A 1.2.3.4

www CNAME example1.com.

ns1 IN A 2.3.4.5

ns2 IN A 3.4.5.6

mx1 IN A 7.8.9.10

mx2 IN A 11.12.13.14

Öffnen Sie eine Shell und wechseln Sie in das Verzeichnis /etc/bind. Für einige der Befehle sind Administratorrechte erforderlich. Zunächst wird ein Zone Signing Key erzeugt, dann der Key Signing Key (ZSK und KSK). Bind bringt dafür das Program dnssec-keygen mit:

dnssec-keygen -a RSASHA1 -b1024 -e -n ZONE example1.com

dnssec-keygen -a RSASHA1 -b1024 -e -n ZONE -f KSK example1.com

Die beiden Befehle erzeugen je zwei 1024 Bit lange private und öffentliche Schlüssel, also insgesamt vier (z. B. Kexample1.com.+005+42768.key und Kexample1.com.+005+42768.private). Der Dateiname beginnt grundsätzlich mit einem K (für Key). Nach dem Domain-Namen folgt eine dreistellige Zahl, die den verwendeten Algorithmus identifiziert. Den Inhalt der .key-Dateien kann man beispielsweise mit less anzeigen lassen; er sollte etwa so aussehen:

example1.com. IN DNSKEY 257 3 5

AQPEAo5p4+7iyM3QuNGf80f7EEqlblR+avRH88XIb7wo3bNI2KKv2hCrXoOAPkXGiV0Dob/EAMQ99Je+zSoMHyYx

Als Nächstes müssen die Schlüssel zur Zonendatei hinzugefügt werden:

cat K*.key >> example1.com

Nun signiert man die Zone mit den Schlüsseln:

dnssec-signzone -s now+0 -e now+2419200 -o example1.com -k Kexample1.com.+005+15342 example1.com \ Kexample1.com.+005+63344

Wenn alles fehlerfrei ablief, liegt im Ordner /etc/bind/ eine Datei namens example1.com.signed. Nun müssen Sie bind mitteilen, diese Zonendatei zu benutzen. Dazu wird in /etc/named.conf die Zeile

file "/etc/bind/example1.com";

durch

file "/etc/bind/example1.com.signed";

ersetzt und in der gleichen Datei im Bereich Options

dnssec-enable yes;

eingefügt. Nach dem Speichern startet man bind neu und hat dann eine per DNSSEC abgesicherte Zone. Die ersten Zeilen einer solchen Zonendatei sehen beispielsweise so aus:

; File written on Tue Apr  8 16:37:43 2008

; DNSSEC_signzone version 9.3.2

example1.com. 604800 IN SOA ns1.example1.com.

mail.example.com. (

2007100801 ; serial

28800 ; refresh (8 hours)

7200 ; retry (2 hours)

604800 ; expire (1 week)

39600 ; minimum (11 hours) 

)

604800 RRSIG SOA 5 2 604800

20080506143743 ( 20080408143743 63344 example1.com.

byogQ0rgEP3etDtrwoi+QWWRBMwwIUhlE1YY

BR54rJal0O1KDLSVoVMWDsv8ey68z+ROKNgW

fZqNbAsJR1sWVQ== )

604800 NS ns1.nameserver1.tld.

Ein einfaches Verfahren, um die Antworten einer DNSSEC-gesicherten Zone zu überprüfen, liefert das Kommando dig:

dig dnssec.se any

Es sollte eine Liste von DNS-Records liefern, darunter auch RRSIG, NSEC und DNSKEY – daran erkennt man, dass die abgefragte Domain DNSSEC-Einträge hat. Der Befehl

dig @a.ns.se dnssec.se DS

liefert die bei der Registry hinterlegten Schlüsseldaten. Der Server http://dnscheck.iis.se/ kann auch dnssec überprüfen, leider nur auf Englisch. Erschrecken Sie mal Ihren Admin:

http://dnscheck.iis.se/? time=1209996669&id=695&view=basic

Siehe auch:

• DNSsec Walker: Automatisches Zone-Walking auf DNSSEC-Servern
• Unbound: Validierender DNS-Server als Alternative zu Bind

(dz)