DNSSEC: Lügendetektor fürs LAN

Alle Clients eines LANs lassen sich auf einen Schlag mit DNSSEC absichern, indem man einen validierenden Resolver aufsetzt, den jeder Client zur Namensauflösung verwendet. Das bietet einen Sicherheitsgewinn bei der Kommunikation mit Domains, die ihre DNS-Info mit DNSSEC absichern und lässt sich komplett von Admin-Seite her erledigen.

Wie man einen lokalen Resolver auf einzelnen Clients einrichtet, haben wir beschrieben (siehe c't-Artikel Namen-Checker, DNSSEC für Clients und Client-Netze einrichten, c’t 18/14, S. 165 und Besiegelte Wegweiser, Linux, Mac OS X und Windows per DNSSEC absichern). Das Nachfolgende erklärt die Einrichtung eines DNSSEC-Resolvers auf Windows Server 2012 R2. Als Restrisiko bleibt, dass die DNS-Antworten innerhalb des Firmen-LAN manipuliert werden können. Zum Schutz davor sichern Sie die Kommunikation zwischen Windows-Clients und dem DNS-Resolver per IPSec. Microsoft hat separate Anleitungen für den DNS-Server sowie für die Clients veröffentlicht. Für Clients mit anderen Betriebssystemen funktioniert das leider nicht.

DNSSEC nutzt zur Überprüfung von DNS-Antworten die hierarchische Struktur des Domain Name System. Dabei markieren die Inhaber übergeordneter Domains – genauer Zonen – die jeweils untergeordneten als
vertrauenswürdig und bilden so eine Vertrauenskette (Chain of Trust). Prinzipiell lassen sich zwar auch andere Vertrauensketten einrichten, aber die übliche Chain of Trust verläuft von der Stammzone der ICANN (Root-Zone) abwärts.

Wenn ein DNSSEC-Resolver eine DNS-Antwort erhält, prüft er, ob die Antwort unverfälscht ist und ob der antwortende DNS-Server zur Vertrauenskette gehört. Dazu rechnet er dessen und die Signaturen der übergeordneten Server bis zur Root-Zone gegen, was den Datenverkehr erhöht. Die Signatur der Root-Zone kann er nicht prüfen, da sie keine übergeordnete Instanz besitzt. Darum muss der Server-Admin diese Signatur selbst prüfen.

Bei einzelnen Administratoren steht DNSSEC im Verruf, das Netzwerk mit zusätzlichen Validierungspaketen zu belasten und Latenzen in die Höhe zu treiben. Die wenigen zusätzlichen Pakete lasten moderne Gigabit-Netze jedoch kaum aus. Die Antwortzeit des DNS-Resolvers steigt bei Domains, die DNSSEC bereits einsetzen, tatsächlich in geringem Umfang an. Eine DNS-Abfrage der IP-Adresse von iana.org dauert ohne DNSSEC in unserem Beispielaufbau rund 270 Millisekunden. Läuft die Anfrage über den DNSSEC-fähigen Resolver des Windows Servers, dauert sie 360 Millisekunden. Unbound als auf dem Client installierter Resolver brachte es auf 347 Millisekunden. Diese Unterschiede fallen im Alltag also kaum auf.

DNSSEC für alle

Falls Sie Ihren Server nicht schon als Resolver ohne DNSSEC-Validierung nutzen, installieren Sie darauf zunächst die DNS-Rolle. Öffnen Sie den Servermanager und wählen unter „Verwalten“ den Punkt „Rollen und Features hinzufügen“. Klicken Sie im Assistenten dreimal auf „Weiter“, markieren „DNS“, wählen „Features hinzufügen“ und arbeiten den Dialog gemäß den Bildschirmanweisungen durch.

DNSSEC lässt sich über die Bedienoberfläche an- und abschalten. Das hilft etwa, um das Datenaufkommen mit und ohne DNSSEC-Validierung zu vergleichen. Das Häkchen finden Sie, indem Sie im Dashboard unter „Tools“ den Punkt „DNS“ wählen, per Rechtsklick die Eigenschaften des DNS-Servers öffnen und zum Reiter „Erweitert“ wechseln.

Damit ein DNS-Resolver den Anfang der Vertrauenskette kennt, müssen Sie den Trust Anchor (Root-Key) von der Webseite der IANA herunterladen. In Windows-Server lässt sich der Root-Key nicht ohne Weiteres einbinden, da er nicht im passenden Format vorliegt. Um ihn dennoch ins System zu integrieren, gibt es verschiedene Wege. Der einfachste führt über ein wenig bekanntes Powershell-Kommando, das die Datei in einem Rutsch herunterlädt, umwandelt und ins System einbindet. Um sicherzugehen, dass es sich um den unverfälschten Key handelt, laden Sie ihn vorher manuell herunter und überprüfen Sie seinen Hash, etwa mittels PGP.

Öffnen Sie dann ein Powershell-Fenster mit Administrator-Rechten und geben Sie ein:

Add-DnsServerTrustAnchor -Root

Danach lesen Sie den Vertrauenspunkt mit dem Befehl Get-DnsServerTrustPoint in der Powershell aus. Steht dort unter TrustPointName ein Punkt und daneben „Active“, so war der Vorgang erfolgreich und die Resolver-Einrichtung ist abgeschlossen.

Clients einbinden

Damit die Clients den Resolver verwenden, verteilen Sie dessen IP-Adresse per DHCP etwa über die DHCP-Rolle des Windows Servers oder per Router. Der Resolver validiert Anfragen für IPv4- und IPv6-Adressen im Internet unabhängig davon, über welches der beiden Protokolle er im LAN mit den Clients kommuniziert.

Testen Sie danach, ob der DNS-Resolver wirklich validiert. Seiten wie dnssec.vs.uni-due.de prüfen nur lokal auf dem PC installierte Resolver und liefern mit einem externen falsche Resultate. Um den externen Resolver von einem Client aus zu prüfen, laden Sie den DNS-Server Bind9 herunter. Wählen Sie bei der Installation „Tools only“. Unter Windows öffnen Sie ein Eingabeaufforderungsfenster und wechseln in das Verzeichnis C:\Program Files\ISC BIND 9\bin. Führen Sie dort dig iana.org +dnssec aus (auf dem Server nutzen Sie vor dem Domainnamen @localhost). Erscheint in der Antwort das ad-Flag (Authenticated Data), so ist sie validiert. (dz)