Namen-Checker: DNSSEC für Clients und Client-Netze einrichten
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.
- Carsten Strotmann
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 manipulieren.
Wenn Sie Ihrem internen Netzwerk vertrauen, genügen zwei lokale Resolver auf verschiedenen Servern. Das kann auch ein preisgünstiger Router mit OpenWRT übernehmen. Alternativ übertragen Sie die Aufgabe einem Kompaktrechner wie dem Raspberry Pi.
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
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 beziehungsweise das Entwicklerteam des niederländischen Registrars SIDN anbieten.
Validieren mit BIND
Wenn Sie schon BIND 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.
