DNS-Pionier warnt vor DNSSEC-Designfehlern
Paul Mockapetris warnte bei einer Konferenz zur "Gesundheit des DNS" vor Designfehlern in der DNS-Erweiterung DNSSEC, rät aber gleichzeitig und trotz seiner Vorbehalte zur raschen und umfassenden DNSSEC-Einführung.
Der DNS-Pionier Paul Mockapetris warnte bei einer Konferenz zur "Gesundheit des DNS" in Rom vor Designfehlern von DNSSEC. Mit DNSSEC kann ein Empfänger feststellen, ob die DNS-Antwort verfälscht wurde und ob die im Paket enthaltene Information vertrauenswürdig ist. Doch noch geht die Verbreitung von DNSSEC-Signaturen recht schleppend voran.
Experten diskutierten bei der Konferenz aktuelle Fehlerraten des Protokolls, ein Vertreter der staatlichen US-Forschungseinrichtung Sandia National Laboratories sprach von Ausfällen durch fehlerhafte Signaturen bei rund einem Drittel der signierten Domains in verschiedenen Top-Level-Domains. Mockapetris riet trotz der Fehler dazu, den Einsatz des Protokolls voranzutreiben. Er empfahl aber dringend, die Validierung direkt beim Endnutzer anzusiedeln. Bisher ist es so, dass meist nur die Provider die DNSSEC-Informationen validieren. Besser wäre es jedoch wenn, PCs, Notebooks, Smartphones, Server und Appliances sie auswerten würden. Dazu müssten allerdings etwa die DNS-Resolver der Betriebssysteme dafür vorbereitet sein.
"Bringt DNSSEC auf die Maschine des Nutzers", sagte Mockapetris den Entwicklern. Die "letzte Meile" darf nicht das Einfallstor für Angriffe werden, denn von hier will der Nutzer schließlich auch seine Bankgeschäfte erledigen. Die DNSSEC-Sicherheitslücke auf der "letzten Meile" gilt als eine der noch offenen Fragen für DNSSEC. Mockapetris nannte jedoch auch die zentrale Gestaltung mit einem einzigen Wurzelzertifikat einen Fehler. Fehler etwa durch das Nicht-Erneuerns auslaufender Signaturen oder beim Wechsel von Zonenschlüsseln verbreiteten sich innerhalb kürzester Zeit im Netz, berichtete Kensuke Fukuda vom japanischen National Institute of Informatics.
Fukuda hatte gemeinsam mit der japanischen Registry die Zeiten ermittelt, nach denen Fehler sich in negativen Validierungen bei umliegenden Systemen bemerkbar machen und dabei fest gestellt, dass nach nur 10 Minuten bereits 18 Prozent der Cacheserver in der .jp-Zone Alarm schlagen, wenn es einen einzigen Fehler bei einem autoritativen .jp-DNS-Server gibt. In den ersten beiden Stunden versagt die Validierung bei 85 Prozent der Autonomen Systeme und 35 Prozent aller IP-Adressen, so der Test der Forscher. Aktuell spielen diese Zahlen noch eine kleine Rolle, vor allem, weil bislang kaum validiert wird und daher die Fehler meist unbemerkt bleiben. Bei größerer Verbreitung würden die entsprechenden Zonen oder Einzeldomains jedoch nicht mehr erreicht.
Will eine Zone wie .jp (oder auch .de) jedoch einen raschen Schlüsseltausch in der zentralen Rootzone vornehmen, dauert das deutlich länger. Zwei Tage, wie die japanischen Forscher gerechnet hatten, reiche gerade mal dafür, dass falsche Schlüssel aus den letzten Caches verschwinden, sagte BIND-Guru Paul Vixie. Bis die Faxe innerhalb des für den Betrieb der zentralen Schlüsselverwaltung zuständigen Triumvirats (die Internet Corporation for Assigned Names and Numbers, VeriSign und das US-Handelsministerium) ausgetauscht seien, dauere es im Zweifel länger, sagte Vixie. "Kein gutes Design", konterte Mockapetris, räumte aber ein, dass er keinen konkreten Vorschlag für eine dezentrale Gestaltung habe.
In einigen Jahren ließe sich so etwas neu machen, sagte Vixie, doch dann müssten diejenigen, die schon implementiert haben, erneut umbauen. Am Rande der Konferenz wurde als einfacheres Mittel gegen die Fehleranfälligkeit schon einmal darüber diskutiert, auf die kontinuierlichen Wechsel nicht-kompromittierter DNSSEC-Schlüssel einfach zu verzichten. An einen völlig fehlerfreien Einsatz des wegen der Krypto-Komponente recht komplexen Protokolls glaubt aber kaum jemand. ICANNs DNSSEC-Experte Rick Lamb warnte davor, DNSSEC zwar rasch, aber auf Kosten sauberer Prozesse einzuführen. Stör- und Zwischenfälle können dann das Protokoll in Verruf bringen.
Wenn es nach Mockapetris geht, müsste alles simpler gestaltet werden, vor allem auch mit Blick auf den Einsatz von DNSSEC auf der letzten Meile. Generell sprach sich Mockapetris dafür aus, viel mehr Sicherheitswerkzeuge in die Hand der Nutzer zu geben – etwa auch die nicht unumstrittenen Reputationslisten. Statt einer externen Instanz zu vertrauen, sollten die Nutzer eher selbst ermächtigt werden. Bemühungen von Seiten von Regierungen, das DNS zu filtern, wurden bei der Tagung generell abgelehnt. Viele Experten sehen wegen der Begehrlichkeit von Regierungen auch die Bemühungen Vixies überaus kritisch, ein Reputationssystem direkt bei rekursiven DNS-Servern zu integrieren. Das im DNS-Server BIND bereits vorhandene System der "Response Policy Zones" (RPZ kollidiert dabei in ähnlicher Weise mit DNSSEC wie klassische DNS-Filter. Vixie sagte, an der "Interaktion" beider Systeme müsse noch gearbeitet werden. Demnächst will er die dritte RPZ-Version herausbringen. (rek)
