DNSSEC: Internetstandards zur signierten Namensauflösung

Jeder Nutzer und jede Präsenz im World Wide Web besitzt eine eigene, einzigartige IP-Adresse, die sich aus mehreren Zahlen zusammensetzt. Damit beim Besuch einer Homepage oder Versenden einer E-Mail statt dieser IP-Adresse ein praktischer Domain-Name wie IONOS.de eingegeben werden kann, existiert das sogenannte Domain-Name-System (DNS). Es ist für die Namensauflösung verantwortlich und somit einer der wichtigsten Dienste IP-basierter Netzwerke. Aus verschiedenen Nameservern (auch: DNS-Server) bestehend, wandelt es Klartextnamen in IP-Adressen um und ermöglicht dem Client auf diese Weise, den gewünschten Kontakt herzustellen.

Die Kommunikation zwischen Nameserver und Client birgt allerdings ein großes Sicherheitsrisiko: Da die Identität des Absenders nicht überprüft wird, kann der Empfänger nicht ermitteln, ob die erhaltene DNS-Antwort tatsächlich vom befragten Server stammt. Schaltet sich ein Angreifer nun zwischen Nameserver und Client, kann er dem Empfänger eine falsche IP-Adresse zuweisen. Um diesem Problem zu begegnen, wurde DNSSEC entwickelt, das seit 2011 auch für .de-Domains verfügbar ist.

Bei den Domain Name System Security Extensions (DNSSEC) handelt es sich um verschiedene Internetstandards, die das Domain-Name-System um Quellenauthentifizierung ergänzen und dadurch die Authentizität und Integrität der Daten gewährleisten. Nachdem sich die ursprüngliche DNSSEC-Version von 1999 für größere Netze als untauglich herausstellte, dauerte es einige Jahre, bis die Erweiterungen zur DNS-Sicherheit schließlich 2005 in den drei RFCs (Requests for Comments) RFC 4033, RFC 4034 und RFC 4035 veröffentlicht und zum Standard wurden. 2010 startete die Technik endgültig auch auf der Root-Ebene des Internets, nämlich auf den 13 Root-Nameservern, die für die Auflösung der Top-Level-Domains verantwortlich sind.

DNSSEC stützt sich auf ein Public-Key-Kryptosystem, ein asymmetrisches Verschlüsselungsverfahren, bei dem beteiligte Parteien keinen gemeinsamen geheimen Schlüssel austauschen, sondern auf ein Schlüsselpaar, bestehend aus einem öffentlichen (Public Key) und einem privaten Schlüssel (Private Key), zurückgreifen. Durch den privaten Schlüssel werden alle DNS-Informationseinheiten, die sogenannten Resource Records, mit einer digitalen Signatur versehen. Mithilfe des öffentlichen Schlüssels wird diese Signatur von den Clients verifiziert und somit die Echtheit der Quelle bestätigt.

Jeder Nameserver im Domain-Name-System ist für eine bestimmte Zone zuständig. In der Zonendatei führt er eine vollständige Liste aller Resource Records, die seine Zone beschreiben. Aus diesem Grund besitzt jeder Nameserver auch seinen eigenen Zonenschlüssel, mit dem allein er imstande ist, die Resource Records abzusichern. Der Public Key des Zonenschlüssels ist als DNSKEY Resource Record in die Zonendatei integriert, während mithilfe des öffentlichen Schlüssels jede einzelne Informationseinheit signiert wird. Auf diese Weise entstehen RRSIG Resource Records, die nun zusätzlich zum zugrundeliegenden Resource Record ausgeliefert werden. Diese Kombination bleibt bestehen, egal ob sie im Cache gespeichert oder an einen anderen Nameserver übertragen wird. Zuletzt landet sie beim anfragenden Client, der die Signatur mithilfe eines DNS-Resolvers und des öffentlichen Schlüssels validieren kann.

Um das Schlüsselmanagement zu erleichtern und eine Chain of Trust (Vertrauenskette) zu erzeugen, existiert neben dem Zonenschlüssel ein syntaktisch identischer Schlüsselunterzeichnungs-Schlüssel, der die Echtheit des jeweiligen Zonenschlüssels bestätigt. Ein Hashwert des Unterzeichnungs-Schlüssels wird in einem DNS-Eintrag der übergeordneten Zone als Trusted Key abgelegt, wodurch dem Resolver einzig der Public Key der obersten Zone – der Root-Ebene – bekannt sein muss.

DNS-Resolver sind Software-Module der Clients, die Informationen von den Nameservern abrufen können. Sie gehen bei der Anfrage entweder iterativ oder rekursiv vor. In ersterem Fall erhält der Resolver entweder die gewünschte Information oder einen Verweis auf den nächsten Nameserver und verfährt auf diese Weise, bis er die Adresse aufgelöst hat. Rekursiv arbeitende Resolver, die auch Stub-Resolver genannt werden und für gewöhnliche Clients wie Webbrowser typisch sind, schicken eine Anfrage an den ihnen zugeordneten Nameserver im lokalen Netz oder im Netz des Providers. Ist die angeforderte Information nicht im Datenbestand enthalten, bleibt die vollständige Adressauflösung in der Verantwortung dieses Servers, der seinerseits iterative Anfragen versendet.

Um von DNSSEC zu profitieren, ist ein validierender Resolver notwendig, der die erzeugten Zusatzinformationen auswerten kann. Zu diesem Zweck muss der Resolver die Protokoll-Erweiterungen Extension Mechanisms for DNS (EDNS) unterstützen, denn nur so kann die Validierung im DNS-Header aktiviert werden.

Die Verbreitung von DNSSEC gestaltet sich bisher vor allem aufgrund der komplexen Voraussetzungen schwierig: Sowohl auf Seiten des Anbieters einer Webpräsenz als auch auf Seiten des Besuchers muss die Technik unterstützt werden. Domain-Inhaber sind darauf angewiesen, dass der Registrar die Verschlüsselung unterstützt und in die Wege leitet. Nutzer haben keinen Einfluss darauf, ob eine Website durch DNSSEC-Signaturen geschützt ist, und benötigen außerdem einen validierenden Resolver. Um von der DNS-Security Gebrauch zu machen, müssen sie also entweder einen eigenen Resolver wie Bind betreiben, Browser-Erweiterungen wie den DNSSEC Validator nutzen oder nach einem Provider suchen, der DNSSEC-Signaturen überprüft. In jedem Fall sollte der Aspekt berücksichtigt werden, dass DNSSEC lediglich die Namensauflösung signiert bzw. authentifiziert, während die übermittelten Daten keinerlei Schutz erfahren. Eine Kombination mit verschlüsselnden Übertragungsprotokollen wie TLS gehört folgerichtig zum Pflichtprogramm.

Zusätzlich sind folgende Probleme ursächlich für die zögerliche Akzeptanz der DNS-Sicherheits-Technik:

• Aufgrund der höheren Auslastung des Nameservers werden Denial-of-Service-Angriffe, die die Nichtverfügbarkeit eines Dienstes herbeiführen, erleichtert.

• Die DNSSEC Chain of Trust ist insofern gefährdet, dass die Public Keys ebenfalls über das Domain-Name-System verteilt werden.

• Ohne einen eigenen validierenden DNS-Resolver besteht die Möglichkeit, dass ein Angriff zwischen Client und dem Nameserver des Providers erfolgt, selbst wenn dieser DNSSEC-Signaturen verifiziert.

Auf andere Schwachstellen wie das sogenannte DNSSEC-Walking, bei dem Angreifer den vollständigen Inhalt einer DNSSEC-signierten Zone auslesen, wurde bereits reagiert, indem neuere Resolver-Versionen die verschiedenen Resource Records nicht mit einem Klartext-Label, sondern einem Hashwert benennen.