Sicheres DNS mit Unbound

Auftritt Unbound

Unbound ist ein validierender, rekursiver DNS-Resolver, der Ergebnisse cachen kann. Er ist modular und besteht aus mehreren Komponenten. Unbound wird von der niederländischen NLnet Labs-Stiftung entwickelt, derselben Organisation, die auch den autoritativen DNS-Server NSD entwickelt.

Wo installiert man Unbound am besten? Wenn man die Anforderung stellt, dass der Dienst rund um die Uhr laufen soll, kommen der eigene Router, ein NAS oder ein Server in Frage. Notfalls tut es auch der eigene Desktop.

Die Installation von Unbound ist einfach, meist kann sie über ein Distributionspaket erfolgen. Wird die aktuellste Version gewünscht und diese ist noch nicht als Paket verfügbar, kann man den Quellcode von NLnet Labs herunterladen und ihn selbst compilieren. Es empfiehlt sich, auch das Paket »dnsutils« zu installieren, das unter anderem das Programm dig enthält.

Die Konfiguration von Unbound fällt einem nicht so einfach in den Schoß. Es wird zwar möglicherweise eine Standardkonfiguration installiert, die einfache Fälle abdeckt, doch wir wollen mehr Möglichkeiten von Unbound nutzen. Dazu muss man sich die Dokumentation genau ansehen.

Doch da dies alles nicht in ein paar Worten zu erklären ist, wollen wir vorerst nur eine minimale Konfiguration betrachten, eine, die lediglich die Auflösung von externen Adressen vornimmt (ich gehe davon aus, dass die meisten Leute zuhause ihre wenigen Rechner über /etc/hosts verwalten). Unsere initiale Konfigurationsdatei /etc/unbound/unbound.conf sieht folgendermaßen aus:

include: "/etc/unbound/unbound.conf.d/*.conf"

server:
    interface: 0.0.0.0
    interface: ::0
    access-control: 0.0.0.0/0 allow
    chroot: ""

    cache-min-ttl: 600
    root-hints: root.hints

    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10
    private-address: ::ffff:0:0/96

    unwanted-reply-threshold: 10000000

    do-not-query-address: 127.0.0.1/8
    do-not-query-address: ::1

forward-zone:
    name: "."
    forward-addr: 193.101.111.10
    forward-addr: 212.51.16.1
    forward-addr: 109.234.249.10
    forward-addr: 85.88.19.11
    forward-ssl-upstream: no

Die erste Zeile inkludiert weitere Direktiven, die vielleicht von der Distribution mitgeliefert werden. Bei Debian wird zum Beispiel die QNAME Minimisation gleich aktiviert, die wir folglich auch gleich erklären müssen. Diese Funktionalität sorgt für etwas mehr Privatsphäre, indem sie ganz einfach bei einer Anfrage ein einen DNS-Server nur den benötigten Domain-Teil des Hostnamens übergibt. Am meisten nützt das auf der obersten Ebene, wenn statt pro-linux.de oder www.pro-linux.de nur noch de angefragt wird.

Ansonsten hat die Datei zwei Abschnitte, server und forward-zone. In ersterem wird festgelegt, dass auf allen Netzwerkschnittstellen gelauscht wird, sowohl auf IPv4 als auch IPv6. Vorerst sind Anfragen von allen Adressen erlaubt und wir verzichten auf eine chroot-Umgebung. Es folgen einige technische Details und die Deklaration der privaten Adressen, die nicht in DNS-Antworten auftauchen dürfen und aus diesen entfernt werden, wenn sie erscheinen sollten. Die do-not-query-address-Direktiven sperren die Anfrage dieser Adressen bei externen Servern.

Der Abschnitt forward-zone definiert, wie Anfragen behandelt werden sollen. name: "." steht für alle Anfragen, wir machen also zunächst keinen Unterschied zwischen verschiedenen Zonen (Domains). Mit der forward-addr-Direktive definieren wir hier vier DNS-Server, die wir für vertrauenswürdig halten. Hier muss jeweils eine IPv4- oder IPv6-Adresse angegeben werden. Unbound benutzt die Server abwechselnd, evtl. auch in zufälliger Reihenfolge. Doch welchen Servern kann oder sollte man vertrauen? Das muss jeder selbst entscheiden. Eine Suche in einer Suchmaschine nach den Begriffen offene dns-server liefert eine Reihe von Listen, die dabei weiterhelfen. Leider zeigt die Erfahrung, dass man seine Liste aktiv pflegen muss, denn es kommt gelegentlich vor, dass einer der ausgewählten Server nicht mehr erreichbar ist.

Ist die Datei erstellt, kann man Unbound mit service unbound restart neu starten. Ob er tatsächlich beendet und neu gestartet wurde, kann man an den Einträgen in /var/log/messages sehen. Erste Tests kann man nun mit dig vornehmen, um Unbound aber tatsächlich zu nutzen, muss man seine Datei /etc/resolv.conf anpassen. Minimal muss sie nur eine Zeile enthalten:

nameserver <IP des Unbound-Servers>

Von nun an sollte die Namensauflösung über den neuen Unbound-Server laufen - sofern man kein DNS über HTTPS irgendwo aktiviert hat. Im nächsten Artikel der Serie werden wir die Konfiguration verfeinern.