zurück zum Artikel

Namen-Checker: DNSSEC für Clients und Client-Netze einrichten

| Carsten Strotmann

DANE sichert Zertifikate, die Internet-Server als Identitätsnachweis und zur Verschlüsselung nutzen. Der Anwender kann sich auf die DANE-Infos aber nur verlassen, wenn ein DNS-Client sie auf sichere Weise besorgt hat. Solch einen DNSSEC-fähigen Resolver richtet man ganz leicht lokal auf PCs ein oder stellt ihn als Server-Funktion im Netz zur Verfügung.

Zurzeit gibt es noch keine einfache, standardisierte Methode, die DNS-Kommunikation zwischen einer Anwendung und dem DNS-Resolver zu sichern. Um das Risiko klein zu halten, sollte die DNSSEC-Validierung deshalb möglichst nah an der Applikation ablaufen, also am besten mit einem lokalen Resolver auf jedem PC.

Das Umstellen auf einen öffentlichen DNS-Resolver, der DNSSEC validiert, wie es Googles Server 8.8.8.8 und 8.8.4.4 tun, ist tabu: Denn deren Antwort kommt ungeschützt per UDP und lässt sich damit leicht von einem Man-in-the-Middle [1] manipulieren.

Wenn Sie Ihrem internen Netzwerk vertrauen, genügen zwei lokale Resolver auf verschiedenen Servern. Das kann auch ein preisgünstiger Router mit OpenWRT [2] übernehmen. Alternativ übertragen Sie die Aufgabe einem Kompaktrechner wie dem Raspberry Pi [3].

Ob der DNS-Resolver Ihres Rechners das AD-Flag ausgibt, können Sie in der Shell an den bereits mit DANE/DNSSEC funktionierenden Servern des Bundes prüfen:

dig @localhost bund.de +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096
DNSSEC-Resolver-Test

Ob der lokale Resolver DNSSEC beherrscht, prüfen Resolvertest-Tools wie das der Uni Duisburg-Essen. Kommt nach dem Umkonfigurieren immer noch eine Negativmeldung, löschen Sie den Browsercache und laden die Seite neu.

Nutzen Sie einen Resolver im LAN, dann setzen Sie statt localhost dessen IP-Adresse ein. Der Test setzt freilich voraus, dass die Upstream-DNS-Server DNSSEC beherrschen. Fehlt das ad in der Ausgabezeile, müssen Sie einen anderen Resolver einsetzen.

Im Browser lässt sich die DNSSEC-Validierung mit zwei Online-Tools prüfen, die die Universität Duisburg-Essen [4] beziehungsweise das Entwicklerteam des niederländischen Registrars SIDN [5] anbieten.

Wenn Sie schon BIND [6] als Resolver nutzen, können Sie ab Version 9.9.0 einfach die Validierung im options-Block von named.conf einschalten:

options {
directory "/var/named";
# DNSSEC einschalten
dnssec-enable yes;
# Validierung mit eigenem Root-Trust-Anchor
dnssec-validation auto;
# Auflösung auf lokale Netze beschränken
allow-recursion { localnets; };
...

Der Root-Trust-Anchor (Root Key) liegt BIND ab Werk bei. Da es hier als Resolver arbeitet, ist Rekursion für Clients im LAN erlaubt. Wirft der Test mit named-checkconf -z keine Fehler aus, laden Sie die Konfiguration mit rndc reconfig neu.

Ändern Sie nun Ihre DHCP-Server-Konfiguration oder lokal die Hosts so, dass sie den oder die lokalen Resolver als DNS-Server ausgeben beziehungsweise verwenden. Laufen in Ihrem Netz mehrere Resolver, müssen alle DNSSEC validieren.

Schlägt eine DNSSEC-Überprüfung fehl, weil etwa die DNS-Daten auf dem Server oder auf dem Transportweg manipuliert wurden, erkennt der Resolver das und meldet den Fehler SERVFAIL. Der Stub-Resolver im Betriebssystem probiert dann den anderen Server. Scheitert auch der, kommt stillschweigend keine Verbindung zu Stande: Der Browser meldet lapidar, dass er die Site nicht finden kann.

DNSSEC-Trigger sucht bei Netzwerkänderungen automatisch einen neuen DNS-Server, der DNSSEC unterstützt. Ob das geklappt hat, verrrät unter Windows ein Rechtsklick auf das Tray-Symbol.

DNSSEC-Trigger sucht bei Netzwerkänderungen automatisch einen neuen DNS-Server, der DNSSEC unterstützt. Ob das geklappt hat, verrrät unter Windows ein Rechtsklick auf das Tray-Symbol.

Für mobile Rechner hat sich die Kombination von Unbound [7] mit DNSSEC-Trigger [8] bewährt, die es für Windows, Linux und Mac OS X gibt. Letzterer sucht bei Netzwerkänderungen – wenn das Notebook das WLAN wechselt – einen neuen DNS-Server, der DNSSEC unterstützt. Scheitert das, fragt DNSSEC-Trigger den Anwender per Popup, ob er mit unsicherem DNS fortfahren möchte. Unter Windows genügt es, DNSSEC-Trigger herunterzuladen und zu installieren; das Windows-Paket bringt Unbound mit.

Unbound ist ein schlanker und schneller DNS-Resolver, der ab Werk DNSSEC validiert. Nach der Installation kann man mit dem Tool unbound-anchor den Root-Trust-Anchor TLS-gesichert von der IANA-Webseite [9] holen, was Linux beim Systemstart normalerweise automatisch tut. Er liegt hernach als Datei root.key in /etc/unbound. Ob das geklappt hat, testen Sie so:

unbound-anchor -v
/etc/unbound/root.key has content
success: the anchor is ok

Auch der verbreitete Resolver dnsmasq kann inzwischen DNSSEC validieren. Jedoch brauchte er dafür selbst bei im Mai 2015 aktuellen Linux-Distributionen noch etwas Nachhilfe. [10]

Auf der Linux-Kommandozeile können Sie DNSSEC/DANE mit dem Tool ldns-dane aus dem ldns-Paket prüfen. Es lässt sich unter OpenSuse direkt per Paketmanager installieren; bei Ubuntu heißt das Paket ldnsutils. Erscheint nach dem Aufruf von ldns-dane verify www.bund.de 443 eine IP-Adresse gefolgt von dane-validated successfully, klappt alles.

Für die wichtigsten Browser – Firefox, Chrome/Chromium, Safari, Opera und Internet-Explorer – hat die tschechische DNS-Registry cz.nic [11] eine Reihe von Open-Source-Projekten rund um DNSSEC und DANE finanziert.

Dazu gehören DNSSEC- und DANE-Validatoren für Browser [12] unter Windows, Mac OS X und Linux. Für den IE, Firefox und Safari sind die Tools in einem Paket zusammengefasst, bei anderen Browsern liegen sie als einzeln zu installierende Komponenten vor. Die Installation unterscheidet sich zwar je nach Browser zwar, ist aber online ausreichend beschrieben. Die Add-ons zeigen anschließend den DNSSEC- und DANE-Status einer Website direkt in der URL-Zeile an.

(ea [13])


URL dieses Artikels:
https://www.heise.de/-2627793

Links in diesem Artikel:
[1] http://www.heise.de/security/suche/?q=man+in+the+middle&rm=search&channel=security
[2] http://www.average.org/blog/2012/07/06/dnssec-validating-resolver-on-openwrt/
[3] http://raspberrypi.tomasgreno.cz/dns-resolver.html
[4] http://dnssec.vs.uni-due.de/
[5] https://dnssectest.sidnlabs.nl/
[6] http://www.heise.de/download/bind-1143311.html
[7] http://www.heise.de/download/unbound-1154936.html
[8] http://nlnetlabs.nl/projects/dnssec-trigger/
[9] https://www.iana.org/dnssec/files
[10] https://www.heise.de/ratgeber/Auskunft-mit-Siegel-2628642.html
[11] http://nic.cz/
[12] https://www.dnssec-validator.cz/
[13] mailto:ea@ct.de