Manche Angriffe aus dem Internet richten sich gegen den wichtigen Dienst der Namensauflösung. DNSSEC tritt an, um diesen Dienst mit moderner Kryptographie zu versehen. Sowohl die Admins der Anwender als auch die der Anbieter müssen aber mitspielen, um mehr Authentizität zu schaffen.

Normalerweise läuft die Sache so: Surft ein Anwender etwa [https://www.linux-magazin.de] per Browser an, schickt sein Rechner zuerst eine Anfrage an den in der »/etc/resolv.conf« konfigurierten Nameserver [1]. Der möge anhand der in der URL enthaltenen FQDN die IP liefern. Kann dieser kontaktierte Resolver den Request nicht selbst beantworten, fragt er hierarchisch im Internet weitere Server, bis er eine Antwort erhält [2]. Die Adresse nutzt der Browser schließlich, um die Inhalte abzurufen.

Für den Benutzer verläuft dieser Vorgang automatisch im Hintergrund. Er will sich aber darauf verlassen, dass die Antwort unverfälscht, also authentisch bei ihm ankommt. Manipulieren Angreifer die Namensauflösung, landet der Benutzer auf einer ganz anderen Webseite.

Um das zu verhindern, erweitern die DNS Security Extensions (DNSSEC) den bewährten Namensdienst um kryptographische Signaturen der einzelnen Einträge [3]. Aber auch das reicht alleine noch nicht aus: Die öffentlichen Schlüssel der verwendeten asymmetrischen Verschlüsslung müssen ebenso authentisch sein. Effektiv ist dazu eine Public-Key-Infrastruktur (PKI) notwendig.

Public Keys für das DNS

Um beide Elemente der Namensauflösung hinzuzufügen, bedarf es zunächst eines Resolvers, der mit DNSSEC umgehen kann. Da die meisten – zum Beispiel die in der Libc eingebauten – Stub-Resolver dazu nicht in der Lage sind, installieren Admins im Netz des Unternehmens oder der Organisation einen Nameserver und aktiviert dessen DNSSEC. Fragen nun die Clients im Netzwerk diesen Server nach IP-Adressen, liefert er mittels DNSSEC gesicherte Erkenntnisse.

Der Weg zwischen Client und erstem Server bleibt dabei jedoch ungesichert und lässt sich zumindest theoretisch manipulieren. Jeder Sicherheitsverantwortliche muss für sich entscheiden, ob dies für seine Nutzer ein Problem ist.

Der DNSSEC-Resolver prüft nun, ob die Anfrage in einer Zone liegt, die der Betreiber der Domain durch DNSSEC gesichert hat. Das ist immer dann der Fall, wenn der Request im Bereich eines Secure Island liegt. Die obersten Knoten solcher Strukturen heißen Secure Entry Points (SEP, siehe Abbildung 1). Der Admin muss sie a priori im DNSSEC-Resolver eintragen. Die Liste der SEPs entspricht damit funktional ungefähr den mitgelieferten CA-Zertifikaten in einem Webbrowser.

Abbildung 1: DNSSEC bildet Secure Entry Points (SEP) im Domänenbaum des DNS. Später sollen die Secure Islands einmal zu einem großen DNS-Kontinent zusammenwachsen.

Eine einsame Insel

Praktisch ist, dass DNSSEC die gleichen Zugriffsmechanismen wie das klassische DNS nutzt. Weil der Resolver nur Resource Records (RR) von einem Server abfragt, ist das System abwärtskompatibel. Die zusätzliche Sicherheit besteht darin, dass ein DNSSEC-aktivierter Resolver Signaturen auf den Resource Records validiert. Ist eine Antwort mal nicht korrekt signiert, verwirft er sie. Das ist ein sehr sicheres Verfahren, da die Benutzer gar nicht erst in Versuchung kommen, eine potenziell kompromittierte Antwort zu verwenden.

Für die Anwender kann es aber auch ungewohnt sein, da der Server mit »NXDOMAIN« antwortet. Dies bedeutet so viel wie “Diese Domain gibt es nicht”. Im Vergleich dazu öffnet sich beim Einsatz einer PKI mit Webzertifikaten in diesem Fall ein Fenster. Der Benutzer entscheidet nun, wie er auf das ungültige Zertifikat reagiert − leider schlagen viele die Warnung einfach aus.

Liegt die Anfrage jedoch nicht innerhalb eines Secure Island, löst der Resolver die Anfrage mit herkömmlichen Methoden auf und liefert die Antwort an den anfragenden Client. Sicherheitsverantwortliche sollten sich beim Einsatz von DNSSEC im Klaren darüber sein, dass Nutzer nicht ohne Weiteres erkennen können, ob Antworten vom Server durch DNSSEC gesichert waren oder nicht.

Langfristig streben die Befürworter des DNSSEC-Systems dahin, nur noch einen einzigen SEP zu haben, der auf die Root-Zone des DNS zeigt. Eine Chain of Trust verkettet die Signaturschlüssel sämtlicher hierarchisch darunterliegender Zonen. Dies erlaubt es DNSSEC-Resolvern, Signaturen zu validieren. In der Praxis ist es jedoch noch nicht ganz so weit gekommen, noch existieren mehrere unabhängige Secure Islands. Bis diese zusammenwachsen, werden Administratoren von Resolvern noch mehrere Trusted Keys als SEPs pflegen müssen.

Teamwork ist gefragt

Um DNSSEC zu einem Erfolg werden zu lassen, ist die Mithilfe zweier Gruppen notwendig: Anwender profitieren nur dann vom System, wenn Netzverwalter für ihre Anwender Server bereitstellen, die per DNSSEC Antworten validieren, und Betreiber von Nameservern ihre Zonen signieren und in das Vertrauensgeflecht der über ihnen liegenden Zonen einbinden [4]. Der freie Nameserver ISC Bind, der vielen als Referenzimplementation von DNS gilt, liefert für beide Einsatzzwecke Lösungen [5].

Dazu erweitert der DNSSEC-Nameserver sein Zonefile. Neben den administrativen Informationen im SOA enthält es hauptsächlich Resource Records, die eine entsprechende Zuordnung von DNS-Namen zu IP-Adressen oder anderen Namen oder umgekehrt enthalten. DNSSEC schützt diese RRs mittels Signaturen. Um das zu bewerkstelligen, führt DNSSEC eine Reihe weiterer RRs ein, die Tabelle 1 auflistet.

Verkettetes Vertrauen

DNSSEC arbeitet mit asymmetrischen Schlüsselpaaren, also mit öffentlichen und zugehörigen privaten Schlüsseln. Die Architekten der IETF (Internet Engineering Task Force) haben das System zweistufig entworfen: Ein Zone Signing Key (ZSK) schützt die einzelnen Resource Records eines Zonefile. Er ist seinerseits durch den Key Signing Key (KSK) geschützt (Abbildung 2).

Abbildung 2: Der Key Signing Key (KSK) signiert den Zone Signing Key (ZSK), der alle anderen Zonefile-Einträge signiert. Das hierarchische PKI-System ist analog zur Struktur Aufbau von DNS-Zonen aufgebaut.

Innerhalb einer Zone reicht die Kenntnis des öffentlichen KSK aus, um zunächst den ZSK und dann die RRs zu validieren. Von einer Parent- zu einer Child-Zone stellt DNSSEC das Vertrauen über den Resource Record “Delegation Signer” her. Ganz oben in der Kette des Vertrauens thront ein KSK, den die Spezifikation Secure Entry Point oder auch Trusted Anchor nennt, der darunter liegende Zonenbaum dient als Secure Island. Es liegt am Admin einer Organisation, solche SEPs in der Konfiguration seines DNSSEC-Servers zu pflegen.

Dazu trägt er die KSKs der von ihm gewünschten Secure Islands in die Sektion »trusted-keys« der Konfigurationsdatei »named.conf« ein (siehe Listing 1). Er sollte in der Hierarchie möglichst die höchsten verfügbaren KSKs nutzen − und natürlich darauf achten, dass diese Schlüssel selbst authentisch übertragen wurden. Nach dem Zonennamen folgen drei Felder: Das Flags Field definiert die Art des Schlüssels – 256 steht für ZSK und 257 für KSK. Das zweite Feld nennt sich Protocol Field und muss laut RFC 4034 immer 3 enthalten. Der dritte Wert spezifiziert den benutzten Algorithmus, wobei 5 für RSA/SHA-1 steht.