DNSSEC

Copyright © Shutterstock / Aitor Serra Martin

Was ist DNSSEC?

Die ursprüngliche DNSSEC-Version wurde 1999 veröffentlicht. Allerdings stellte sich schnell heraus, dass sie für größere Netze untauglich ist. Erst einige Jahre später, im Jahr 2005, wurden die Erweiterungen in drei Request for Comments (RFC) veröffentlicht und zum Standard erhoben. Es handelt sich hier um RFC 4033, RFC 4034 und RFC 4035. Im Jahr 2010 wurde die Technik schließlich auf der Root-Ebene im Internet implementiert, und zwar auf den 13 Root-Nameservern, die für die DNS-Auflösung der Top-Level-Domains sorgen.

Bedeutung

Jeder Internet-User und jede Website besitzt eine IP-Adresse. Diese Adresse ist jeweils einzigartig und setzt sich aus mehreren Ziffern zusammen. Niemand will beim Besuch einer Website oder beim E-Mail-Versand eine IP-Adresse eingeben. Aus diesem Grund existiert das Domain-Name-System (DNS): Es ermöglicht die Eingabe eines praktischen Domain-Namens.

Das Domain-Name-System sorgt für die Namensauflösung und gilt damit als einer der wichtigsten Dienste innerhalb IP-basierter Netzwerke. Klartext-Namen werden in IP-Adressen umgewandelt und bieten damit eine Möglichkeit, den geforderten Kontakt herzustellen.

Bei der Kommunikation zwischen Client und DNS-Nameserver besteht ein Sicherheitsrisiko, das nicht unterschätzt werden darf. Die Identität des Absenders ist vom Empfänger nicht zu überprüfen. Somit kann er nicht ermitteln, ob die DNS-Antwort tatsächlich von dem Server stammt, von dem angeblich die Anfrage gesendet wurde.

Ein Angreifer kann sich zwischen Client und Nameserver einschalten und dem Empfänger eine falsche IP-Adresse zuordnen. Um dieses Risiko zu kontrollieren, wurde DNSSEC (Domain Name System Security Extensions) entwickelt. Seit 2011 ist DNSSEC auch für Domains mit der Endung .de verfügbar.

DNSSEC: die Funktionsweise der Verschlüsselung

Die DNSSEC verwendet ein Public-Key-Kryptosystem. Dabei handelt es sich um ein asymmetrisches Verfahren zur Verschlüsselung. Die beteiligten Parteien tauschen keinen geheimen gemeinsamen Schlüssel aus, sondern greifen auf ein Schlüsselpaar zurück. Dieses Paar besteht aus einem Public Key (öffentlicher Schlüssel) und einem Private Key (privater Schlüssel).

Der private Schlüssel versieht sämtliche Resource Records (DNS-Informationseinheiten) mit einer digitalen Signatur. Der öffentliche Schlüssel des Clients prüft und verifiziert die Signatur und bestätigt so die Authentizität der Quelle.

Im Domain-Name-System ist jeder Nameserver für eine festgelegte Zone zuständig. Der Nameserver beinhaltet eine Zonendatei, in der er alle Resource Records seiner Zone aufführt. Jeder Nameserver besitzt einen eigenen Zonenschlüssel, der ihn allein dazu befähigt, die jeweiligen Resource Records abzusichern.

Der öffentliche Schlüssel des Zonenschlüssels ist als DNSKEY Resource Record in die Zonendatei implementiert. Mit seiner Hilfe wird jede einzelne Informationseinheit signiert. So entstehen RRSIG Resource Records, die mitsamt dem zu Grunde liegenden Resource Record übermittelt werden.

Die Kombination ist von Dauer, und zwar unabhängig davon, ob sie an einen weiteren Nameserver übertragen oder im Cache gespeichert wird. Im letzten Schritt erreicht die Kombination den anfragenden Client. Dieser kann die Signatur anhand eines DNS-Resolvers und des Public Key validieren.

Die Auswertung der Daten durch den Resolver

Beim DNS-Resolver im DNSSEC-Prozess handelt es sich um Client-seitige Software-Module. Sie rufen die Informationen von den Nameservern ab, und zwar auf iterative oder rekursive Weise. Beim iterativen Verfahren wird dem Resolver die gewünschte Information entweder direkt zur Verfügung gestellt, oder er erhält einen Verweis auf den folgenden Nameserver. Diesen Verweisen folgt der Resolver so lange, bis die Adresse aufgelöst ist.

Beim rekursiven Verfahren sendet der Resolver eine Anfrage an den ihm zugewiesenen Nameserver im Netz des Providers oder im lokalen Netz. Findet der Resolver die benötigten Informationen nicht im Datenbestand, sorgt der Server für die vollständige Adressauflösung, indem er wiederum iterative Anfragen auf den Weg schickt. Rekursiv arbeitende Resolver werden auch als Stub-Resolver bezeichnet und sind typischerweise für übliche Clients wie zum Beispiel Web-Browser im Einsatz.

Erst wenn ein validierender Resolver die generierten zusätzlichen Informationen auswerten kann, bietet das DNSSEC die anvisierte Sicherheit. Der Resolver muss zwingend die Protokoll-Erweiterungen EDNS (Extension Mechanisms for DNS) unterstützen. Nur so lässt sich die Validierung im Header des DNS aktivieren.

DNSSEC: Verbreitung und Akzeptanz

Die Verbreitung von DNSSEC gestaltet sich zäh – in erster Linie aufgrund der komplexen Voraussetzungen. Die Technologie muss auf beiden Seiten unterstützt werden – auf der des Hosters ebenso wie auf der des Website-Besuchers. Die Inhaber einer Domain sind darauf angewiesen, dass der Hoster die Verschlüsselungstechnik unterstützt und organisiert. Ob eine Webpräsenz durch DNSSEC-Signaturen geschützt ist, können die Nutzer nicht beeinflussen. Darüber hinaus benötigen sie einen validierenden Resolver.

Dafür haben sie grundsätzlich drei Möglichkeiten:

• Sie wählen einen Provider, der die Überprüfung von DNSSEC-Signaturen anbietet.
• Sie betreiben einen eigenen Resolver.
• Sie nutzen Browser-Erweiterungen wie zum Beispiel den “DNSSEC Validator”.

Dabei müssen die Nutzer in jedem Fall berücksichtigen, dass DNSSEC nur die Namensauflösung authentifiziert bzw. signiert. Die übermittelten Daten sind in keiner Weise geschützt. Dementsprechend ist eine Kombination aus DNSSEC und verschlüsselnden Übertragungsprogrammen – zum Beispiel TLS – nicht nur sinnvoll, sondern notwendig.

Es gibt zusätzliche Probleme, die die schleppende Akzeptanz der DNS-Sicherheitstechnik verursachen. So sind die Nameserver stärker ausgelastet, was Denial-of-Service-Angriffe erleichtert. Der Chain of Trust birgt Risiken, weil die Public Keys via DNS mit verteilt werden.