DNSSEC: In­ter­net­stan­dards zur si­gnier­ten Na­mens­auf­lö­sung

Jeder Nutzer und jede Präsenz im World Wide Web besitzt eine eigene, ein­zig­ar­ti­ge IP-Adresse, die sich aus mehreren Zahlen zu­sam­men­setzt. Damit beim Besuch einer Homepage oder Versenden einer E-Mail statt dieser IP-Adresse ein prak­ti­scher Domain-Name wie IONOS.de ein­ge­ge­ben werden kann, existiert das so­ge­nann­te Domain-Name-System (DNS). Es ist für die Na­mens­auf­lö­sung ver­ant­wort­lich und somit einer der wich­tigs­ten Dienste IP-basierter Netzwerke. Aus ver­schie­de­nen Name­ser­vern (auch: DNS-Server) bestehend, wandelt es Klar­text­na­men in IP-Adressen um und er­mög­licht dem Client auf diese Weise, den ge­wünsch­ten Kontakt her­zu­stel­len.

Die Kom­mu­ni­ka­ti­on zwischen Name­ser­ver und Client birgt al­ler­dings ein großes Si­cher­heits­ri­si­ko: Da die Identität des Absenders nicht überprüft wird, kann der Empfänger nicht ermitteln, ob die erhaltene DNS-Antwort tat­säch­lich vom befragten Server stammt. Schaltet sich ein Angreifer nun zwischen Name­ser­ver und Client, kann er dem Empfänger eine falsche IP-Adresse zuweisen. Um diesem Problem zu begegnen, wurde DNSSEC ent­wi­ckelt, das seit 2011 auch für .de-Domains verfügbar ist.

Bei den Domain Name System Security Ex­ten­si­ons (DNSSEC) handelt es sich um ver­schie­de­ne In­ter­net­stan­dards, die das Domain-Name-System um Quel­len­au­then­ti­fi­zie­rung ergänzen und dadurch die Au­then­ti­zi­tät und In­te­gri­tät der Daten ge­währ­leis­ten. Nachdem sich die ur­sprüng­li­che DNSSEC-Version von 1999 für größere Netze als un­taug­lich her­aus­stell­te, dauerte es einige Jahre, bis die Er­wei­te­run­gen zur DNS-Si­cher­heit schließ­lich 2005 in den drei RFCs (Requests for Comments) RFC 4033, RFC 4034 und RFC 4035 ver­öf­fent­licht und zum Standard wurden. 2010 startete die Technik endgültig auch auf der Root-Ebene des Internets, nämlich auf den 13 Root-Name­ser­vern, die für die Auflösung der Top-Level-Domains ver­ant­wort­lich sind.

DNSSEC stützt sich auf ein Public-Key-Kryp­to­sys­tem, ein asym­me­tri­sches Ver­schlüs­se­lungs­ver­fah­ren, bei dem be­tei­lig­te Parteien keinen ge­mein­sa­men geheimen Schlüssel aus­tau­schen, sondern auf ein Schlüs­sel­paar, bestehend aus einem öf­fent­li­chen (Public Key) und einem privaten Schlüssel (Private Key), zu­rück­grei­fen. Durch den privaten Schlüssel werden alle DNS-In­for­ma­ti­ons­ein­hei­ten, die so­ge­nann­ten Resource Records, mit einer digitalen Signatur versehen. Mithilfe des öf­fent­li­chen Schlüs­sels wird diese Signatur von den Clients ve­ri­fi­ziert und somit die Echtheit der Quelle bestätigt.

Jeder Name­ser­ver im Domain-Name-System ist für eine bestimmte Zone zuständig. In der Zo­nen­da­tei führt er eine voll­stän­di­ge Liste aller Resource Records, die seine Zone be­schrei­ben. Aus diesem Grund besitzt jeder Name­ser­ver auch seinen eigenen Zo­nen­schlüs­sel, mit dem allein er imstande ist, die Resource Records ab­zu­si­chern. Der Public Key des Zo­nen­schlüs­sels ist als DNSKEY Resource Record in die Zo­nen­da­tei in­te­griert, während mithilfe des öf­fent­li­chen Schlüs­sels jede einzelne In­for­ma­ti­ons­ein­heit signiert wird. Auf diese Weise entstehen RRSIG Resource Records, die nun zu­sätz­lich zum zu­grun­de­lie­gen­den Resource Record aus­ge­lie­fert werden. Diese Kom­bi­na­ti­on bleibt bestehen, egal ob sie im Cache ge­spei­chert oder an einen anderen Name­ser­ver über­tra­gen wird. Zuletzt landet sie beim an­fra­gen­den Client, der die Signatur mithilfe eines DNS-Resolvers und des öf­fent­li­chen Schlüs­sels va­li­die­ren kann.

Um das Schlüs­sel­ma­nage­ment zu er­leich­tern und eine Chain of Trust (Ver­trau­ens­ket­te) zu erzeugen, existiert neben dem Zo­nen­schlüs­sel ein syn­tak­tisch iden­ti­scher Schlüs­sel­un­ter­zeich­nungs-Schlüssel, der die Echtheit des je­wei­li­gen Zo­nen­schlüs­sels bestätigt. Ein Hashwert des Un­ter­zeich­nungs-Schlüs­sels wird in einem DNS-Eintrag der über­ge­ord­ne­ten 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 In­for­ma­tio­nen von den Name­ser­vern abrufen können. Sie gehen bei der Anfrage entweder iterativ oder rekursiv vor. In ersterem Fall erhält der Resolver entweder die ge­wünsch­te In­for­ma­ti­on oder einen Verweis auf den nächsten Name­ser­ver und verfährt auf diese Weise, bis er die Adresse aufgelöst hat. Rekursiv ar­bei­ten­de Resolver, die auch Stub-Resolver genannt werden und für ge­wöhn­li­che Clients wie Web­brow­ser typisch sind, schicken eine Anfrage an den ihnen zu­ge­ord­ne­ten Name­ser­ver im lokalen Netz oder im Netz des Providers. Ist die an­ge­for­der­te In­for­ma­ti­on nicht im Da­ten­be­stand enthalten, bleibt die voll­stän­di­ge Adress­auf­lö­sung in der Ver­ant­wor­tung dieses Servers, der sei­ner­seits iterative Anfragen versendet.

Um von DNSSEC zu pro­fi­tie­ren, ist ein va­li­die­ren­der Resolver notwendig, der die erzeugten Zu­satz­in­for­ma­tio­nen auswerten kann. Zu diesem Zweck muss der Resolver die Protokoll-Er­wei­te­run­gen Extension Me­cha­nisms for DNS (EDNS) un­ter­stüt­zen, denn nur so kann die Va­li­die­rung im DNS-Header aktiviert werden.

Die Ver­brei­tung von DNSSEC gestaltet sich bisher vor allem aufgrund der komplexen Vor­aus­set­zun­gen schwierig: Sowohl auf Seiten des Anbieters einer Web­prä­senz als auch auf Seiten des Besuchers muss die Technik un­ter­stützt werden. Domain-Inhaber sind darauf an­ge­wie­sen, dass der Registrar die Ver­schlüs­se­lung un­ter­stützt und in die Wege leitet. Nutzer haben keinen Einfluss darauf, ob eine Website durch DNSSEC-Si­gna­tu­ren geschützt ist, und benötigen außerdem einen va­li­die­ren­den Resolver. Um von der DNS-Security Gebrauch zu machen, müssen sie also entweder einen eigenen Resolver wie Bind betreiben, Browser-Er­wei­te­run­gen wie den DNSSEC Validator nutzen oder nach einem Provider suchen, der DNSSEC-Si­gna­tu­ren überprüft. In jedem Fall sollte der Aspekt be­rück­sich­tigt werden, dass DNSSEC lediglich die Na­mens­auf­lö­sung signiert bzw. au­then­ti­fi­ziert, während die über­mit­tel­ten Daten keinerlei Schutz erfahren. Eine Kom­bi­na­ti­on mit ver­schlüs­seln­den Über­tra­gungs­pro­to­kol­len wie TLS gehört fol­ge­rich­tig zum Pflicht­pro­gramm.

Zu­sätz­lich sind folgende Probleme ur­säch­lich für die zö­ger­li­che Akzeptanz der DNS-Si­cher­heits-Technik:

• Aufgrund der höheren Aus­las­tung des Name­ser­vers werden Denial-of-Service-Angriffe, die die Nicht­ver­füg­bar­keit eines Dienstes her­bei­füh­ren, er­leich­tert.

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

• Ohne einen eigenen va­li­die­ren­den DNS-Resolver besteht die Mög­lich­keit, dass ein Angriff zwischen Client und dem Name­ser­ver des Providers erfolgt, selbst wenn dieser DNSSEC-Si­gna­tu­ren ve­ri­fi­ziert.

Auf andere Schwach­stel­len wie das so­ge­nann­te DNSSEC-Walking, bei dem Angreifer den voll­stän­di­gen Inhalt einer DNSSEC-si­gnier­ten Zone auslesen, wurde bereits reagiert, indem neuere Resolver-Versionen die ver­schie­de­nen Resource Records nicht mit einem Klartext-Label, sondern einem Hashwert benennen.