Protokoll: DNSSEC ist gescheitert

IMHO

PR für ein totes Protokoll: Am heutigen 30. Juni wird der DNSSEC-Day begangen. Dabei ist das Protokoll in seiner heutigen Form nahezu nutzlos - und wird es wohl auch bleiben.

Artikel von Hanno Böck veröffentlicht am 30. Juni 2015, 10:24 Uhr

DNSSEC ist aus heutiger Sicht total veraltet und bringt wenig Vorteile. (Bild: Oxfordian Kissuth/Wikimedia Commons/CC by-sa 3.0D/CC-BY-SA 3.0)

Das DNSSEC-Protokoll ist ein inzwischen über 20 Jahre alter Ansatz, um die Sicherheit im Domain Name System (DNS) zu verbessern. Doch durchsetzen konnte sich das Protokoll nie, bis heute ist ein praktischer Nutzen nahezu nicht vorhanden. Dafür gibt es eine Reihe von Gründen - und realistischerweise ist kaum damit zu rechnen, dass sich das irgendwann ändert. DNSSEC ist ein veraltetes, gescheitertes Konzept, das man am besten beerdigen sollte.

Doch ungeachtet seiner Erfolglosigkeit hat DNSSEC einige Fans. Praktisch jedes Mal, wenn auf Golem.de oder anderswo ein Artikel über die Probleme mit TLS-Zertifikaten und Zertifizierungsstellen berichtet wird, fordern Kommentatoren, dass man endlich das auf DNSSEC aufbauende DANE einsetzen müsse, um Zertifikate abzusichern. Das BSI, die für .de-Domains zuständige Denic und der Heise-Verlag haben für den heutigen 30. Juni einen DNSSEC-Day ausgerufen, nach ihren Angaben "eine Aktion zur Förderung der Internetsicherheit".

DNSSEC signiert, aber verschlüsselt nicht

Um nachzuvollziehen, warum DNSSEC wenig zur Internetsicherheit beiträgt, sollte man zunächst verstehen, was das Protokoll tut. Es ist ein hierarchisches System, das DNS-Einträge signiert. Ein von der Icann und der Firma Verisign verwalteter Root-Schlüssel signiert die jeweiligen Keys der Verwalter von Top-Level-Domains. Diese wiederum signieren die Schlüssel der darunterliegenden Domains. Dazu kommt noch eine Unterscheidung in Key Signing Keys (KSKs) und Zone Signing Keys (ZSKs), die Letzteren werden häufiger gewechselt.

DNSSEC authentifiziert nur die DNS-Abfragen selbst, die anschließende Verbindung jedoch nicht. Hierfür müssen weiterhin Schutzsysteme wie TLS oder SSH zum Einsatz kommen. Konkret bedeutet das beispielsweise, dass man bei funktionierendem DNSSEC sicher sein kann, dass die Domain denic.de zur IP-Adresse 81.91.170.12 gehört. Das Protokoll kann aber nicht gewährleisten, dass die Verbindungen zur IP 81.91.170.12 auch wirklich von dort kommen.

Ebenfalls keinen Beitrag leistet das Protokoll zur Geheimhaltung des Surfvorgangs. Denn DNSSEC verschlüsselt nicht, es handelt sich um ein reines Signatursystem, ein Angreifer kann nach wie vor alle DNS-Anfragen und Antworten mitlesen. Der Grund für die fehlende Verschlüsselung dürfte im Alter von DNSSEC liegen. In den späten Neunzigern, als DNSSEC standardisiert wurde, war Verschlüsselung noch vergleichsweise problematisch und rechenaufwendig. Der standardisierte Verschlüsselungsalgorithmus DES wurde gerade gebrochen, die verbreitete Alternative Triple-DES galt zwar als sicher, war aber extrem langsam. Der AES-Algorithmus war noch nicht erfunden, und von Verschlüsselungsinstruktionen auf Standard-CPUs, die heute üblich sind, wagte vermutlich noch niemand zu träumen. Heute würde vermutlich niemand mehr auf die Idee kommen, ein "sicheres" Protokoll ohne Verschlüsselung zu entwickeln.

DNSSEC: Viele Parteien müssen mitspielen

Wer DNSSEC ganz praktisch einsetzen möchte, muss einige Hürden überwinden. Zunächst einmal funktioniert DNSSEC nur dann, wenn die entsprechende Top-Level-Domain das überhaupt unterstützt. Inzwischen bieten die meisten Top-Level-Domain-Verwalter DNSSEC an, aber längst nicht alle. Wer sich beispielsweise für eine der neueren Domains wie .tel, .jobs oder .mobi entschieden hat, hat Pech gehabt. Auch eine ganze Reihe von Länderdomains unterstützt das Protokoll nicht. DNSSEC ist somit eines der wenigen Features im Netz, bei denen es von der Top-Level-Domain abhängt, ob man es überhaupt nutzen kann.

Doch selbst wenn man eine Top-Level-Domain hat, die DNSSEC theoretisch unterstützt: Einfach anschalten kann man es trotzdem nicht. Selbst wer seinen eigenen DNS-Server betreibt, benötigt die Unterstützung des jeweiligen Domainhändlers. Der muss mit den jeweiligen Top-Level-Domain-Betreibern ein Verfahren dafür vereinbaren, wie die entsprechenden Keys übermittelt werden.

Wer DNSSEC nutzen möchte, sieht sich also im ungünstigsten Fall damit konfrontiert, dass er zuerst den Domainnamen und anschließend auch den Domainprovider wechseln muss. Das dürfte einer der Hauptgründe dafür sein, dass das Protokoll sich nie durchsetzen konnte. Es ist schlicht zu komplex und involviert zu viele unterschiedliche Parteien. Alleine, um auf Serverseite DNSSEC umzusetzen, müssen der Verwalter der Top-Level-Domain, der Domainhändler und der DNS-Serverbetreiber das Protokoll unterstützen.

Die Komplexität von DNSSEC führt immer wieder zu Schwierigkeiten. Die Liste der Fehlschläge bei DNSSEC ist lang. Selbst die Betreiber von Top-Level-Domains haben immer wieder Schwierigkeiten, es korrekt zu betreiben.