Am Nutzen der kryptografischen Absicherung des weltweiten Domain Name System gibt es einige Jahre nach deren Einführung kaum noch Zweifel. Die Fortführung könnte freilich holperig werden, weil in der Spezifikation schwerwiegende Lücken klaffen.

Augen zu und durch – nach diesem Motto forderten Experten und die US-Aufsichtsbehörde NTIA vor Jahren, endlich auch den Anker des hierarchisch organisierten Domain Name System zu signieren, also die DNS-Rootzone, und so den Startschuss für ein weltweites DNS mit Security Extensions zu geben (DNSSEC). 2010 war es dann so weit und seitdem hat sich DNSSEC langsam weltweit verbreitet.

Die Technik erhöht die Sicherheit beim Internet-Verkehr, indem sie DNS-Auskünfte kryptografisch gegen Manipulation absichert und die Quelle der Auskünfte authentifiziert. Das kommt vielen Anwendungen zu Gute, beispielsweise dem Mail-, Messaging-, VoIP- oder auch dem VPN-Verkehr. Wie schutzwürdig DNS-Auskünfte sind, leuchtet am ehesten bei der vertraulichen Kommunikation mit Online-Banken ein. So gewann DNSSEC nach erwartet langer Einführung gerade in den vergangenen Jahren immer mehr Fürsprecher und Nutzer.
Prinzip Hoffnung

Doch je länger das System in der aktuellen Form läuft, desto mehr ist es gefährdet, denn der Hauptschlüssel, auf dem letztlich das gesamte signierte DNS fußt, ist seit dem DNSSEC-Start vor fünf Jahren immer noch der gleiche. Seit einigen Monaten arbeitet immerhin ein Design-Team an einem Konzept für einen nahtlosen Schlüsselwechsel. Nun hat das Team aber festgestellt, dass für den Tausch des Hauptschlüssels schlecht vorgesorgt wurde.

Im Einzelnen muss ein neuer privater Key Signing Key (KSK) für die DNS-Rootzone erzeugt und sicher verwahrt werden und zugleich der zugehörige neue öffentliche KSK verteilt werden. Der private KSK signiert in einem aufwendig gesicherten Verfahren, bei dem stets eine Mindestanzahl von Schlüsselbewahrern aus etlichen Ländern zusammenkommen muss, die kontinuierlich neu erzeugten ZSK (Zone Signing Key). Mit den signierten ZSK werden die Zonen signiert. Wie ein Rootzone-ZSK-Tausch abläuft, hat beispielsweise Ólafur Guðmundsson von CloudFlare ausführlich dokumentiert.

Beim Tausch des Root-KSK tut sich jedoch Neuland auf. Das größte Kopfzerbrechen verursacht den Fachleuten die Verteilung des neuen öffentlichen KSK. Den benötigt man, um die Signaturen zu validieren, die mit dem privaten KSK erzeugt worden sind (siehe Grafik weiter unten im Beitrag).
Ausfall könnte leicht zehntausende Nutzer treffen

Diese Gegenprüfungen vollzieht jeder der weltweit eingerichteten DNS-Resolver, der die signierten Daten auf Validität untersucht. Fehlt einem Resolver der aktuelle öffentliche Schlüssel, setzt seine Namensauflösung aus – er antwortet nicht, wenn er beispielsweise befragt wird, unter welchen IP-Adressen ct.de zu erreichen ist (zurzeit 193.99.144.80 und 2a02:2e0:3fe:1001:302::). Die Nutzer, die ihre DNS-Auskünfte von diesem Resolver beziehen, sind dann vom üblichen Internet-Verkehr abgeschnitten.

Das kann, je nach Provider und Resolver, gleich zehntausende und mehr Teilnehmer betreffen. In Deutschland wurden noch im Sommer 2015 nach Erhebungen des APNIC bis zu 18 Prozent der Nutzer von validierenden Resolvern versorgt. Mitte Dezember waren es laut APNIC-Statistik schon rund 29 Prozent. In einigen anderen Ländern lag der Wert zum Jahresende noch deutlich höher (Dänemark knapp 50 Prozent, Rumänien und Tschechien rund 44 Prozent, Schweden fast 85 Prozent).
Rucke di ku ...

In einschlägigen Foren prallen daher gegensätzliche Meinungen um das richtige Timing beim Schlüsseltausch aufeinander. Einige DNS-Experten wollen das Schlüssel-Update sofort. Sie verweisen darauf, dass der aktuelle Schlüssel bereits fünf Jahre alt ist.

APNIC Chef-Wissenschaftler Geoff Huston warnt hingegen eindringlich vor Risiken bei einem Schlüsseltausch unter den aktuellen Gegebenheiten. Er werde "beträchtliche Schwierigkeiten nach sich ziehen". Die Ursache sei ein "erheblicher Mangel an Klarheit" der betreffenden Spezifikation. Beispielsweise gebe es keine Strategie für den Fall, dass der private KSK der Rootzone kompromittiert wird, wettert Huston.
Gefährdeter Vertrauensanker

Laut Huston wiegt das um so schwerer, als immer mehr vertrauenswürdiges Material im Domain Name System abgelegt wird. Denn das DNS wird wegen seiner DNSSEC-Absicherung zunehmend als vertrauenswürdiger Anker akzeptiert. Es lässt sich beispielsweise als eindeutige Bezugsquelle für öffentliche PGP- und S/MIME-Schlüssel sowie für SSL-Zertifikate verwenden (Grundlagen und weitere Details dazu finden Sie auf unserer DANE-Themenseite).

Damit wächst die Dringlichkeit, Verfahren für den Austausch des KSK auszuarbeiten. Über den richtigen Weg für den Tausch des Root-KSK wird jedoch seit 2013 diskutiert. Zwischenzeitlich bremste die Einführung neuer Top-Level-Domains die Entwicklung einer Strategie. Ab Mitte 2014 war es dann der Rückzug der US-Administration NTIA aus ihrer Aufsichtsrolle, der die Diskussion in die Länge zog.
Desaster ohne Umgehung

Nur so viel scheint bisher klar: Ein automatischer, fehlerfreier Schlüsselwechsel, den alle Resolver umgehend mitmachen, ist nicht absehbar. Das liegt hauptsächlich daran, dass die Implementierungen der Resolver sehr verschieden sind. Eigentlich hat die IETF mit dem RFC 5011 eine Spezifikation zum automatischen Beziehen eines neuen öffentlichen KSK herausgegeben.

Doch das RFC ist von einem allgemein anerkannten Standard weit entfernt. Huston hält es für bestenfalls vage und lückenhaft und das sei der Grund, weshalb Resolver so unterschiedlich implementiert sind – die Spezifikation sieht schlicht keine Server-seitige Rückmeldung vor und so bleibt es für die Rootzone-Betreiber im Dunkeln, ob ein Resolver einen neuen öffentlichen KSK abgeholt hat und mit welchem er arbeitet.

Immerhin sind einige Resolver für den automatischen Schlüsselbezug ausgelegt. Es gibt jedoch auch Implementierungen, denen die Entwickler den aktuellen Schlüssel fest in den Code eingepflanzt haben. Nutzer solcher Resolver sind im Falle eines Schlüsseltauschs also auf Software-Updates und damit auf eine schnelle Reaktion des Herstellers angewiesen. Huston, der selbst im aktuellen Design-Team für den Schlüsseltausch sitzt, meint deshalb, dass jetzt "selbst ein von langer Hand geplanter Wechsel in einem Desaster enden" würde – erst recht ein Ad-hoc-Tausch, für den Fall, dass der KSK kompromittiert wird.

Und wenn man die ungünstig programmierten Resolver betrachtet, die den Key hartkodiert mitbringen, muss man zusätzlich zum Ausfall der Namensauflösung auch Update-Kosten einkalkulieren. "Braucht man wirklich einen neuen Schlüssel?", hatte daher DNS-Experte Florian Weimer in der ersten Konsultationsrunde noch gefragt. In den DNSSEC-Spezifikationen sei der KSK-Tausch jedenfalls nicht zwingend vorgesehen.
Das Zaudern vor dem Update

Doch die Community weiß auch: Falls der Schlüssel kompromittiert oder die aktuelle RSA-Verschlüsselung (2048 Bit) geknackt wird, wird es brenzlig. Manche Diskussionsteilnehmer drängen daher auf eine Kampagne für mehr Aufmerksamkeit, um dann aktuelle Lösungsvorschläge mit höherer Beteiligung zu verbessern. An der jüngsten Konsultation der ICANN nahmen nur wenige Spezialisten teil.

Parallel versucht das Design-Team weiter, seinen Vorschlag abzuschließen. Der aktuelle Entwurf sieht eine Übergangsphase von neun Monaten vor, während der sowohl der neue als auch der alte Schlüssel gültig sind. Den neuen soll man im Notfall zurückziehen können. Dass aber weiterhin ein Datum für den Start der Wechselphase fehlt, lässt ahnen, wie groß die Vorbehalte noch immer sind.