Immer wieder kommt im Zuge von DNS die Diskussion auf, wie es um den Datenschutz und die Privatsphäre bei DNS Providern steht. Außerdem sind gerade große DNS Provider wie Google oder Cloudflare ein beliebtes Ziel für DNS-Spoofing Attacken. All diese Bedenken lassen sich um gehen, indem man sich einen lokalen DNS Server aufsetzt und mit dem Pi-Hole kann man im gleichen Schritt noch ein Stückweit den Überfluss an Werbung stoppen.

In Vorbereitung auf diesen Artikel sollte man ein Grundverständnis von DNS haben. Ansonsten habe ich in diesem Artikel nochmal alles erklärt.

Was ist Pi-Hole

Pi-Hole ist ein OpenSource Projekt, dass es sich als Ziel gesetzt hat einen Netzwerkweiten AdBlocker zu entwickeln. Wie der Name schon verrät, ist das Projekt für den Raspberry Pi gedacht und daher sehr Ressourcen schonend. Grundsätzlich ist die Installation für Raspberry-OS ausgelegt, funktioniert in der Regel aber auch auf Ubuntu und anderen Derivaten.

Wie funktioniert Pi-Hole als AdBlocker

Das AdBlocking funktioniert indem man seinen Pi-Hole Server als DNS-Server im Lokalen Netz angibt. Dadurch werden alle DNS Anfragen der Clients and den Pi-Hole geschickt (Voraus gesetzt, jeder Client nutzt den Pi-Hole als DNS-Server).

Auf dem Pi-Hole selber kann man nun Blocklisten führen, die Domains die im Zusammenhang mit Werbung stehen sammeln. Diese Blocklisten gibt es zu Hauf frei verfügbar auf Plattformen wie GitHub. Man muss also nicht mühsam duzende Domains in eine Textdatei schreiben, sondern kann diese einfach kopieren.

Bekommt der Pi-Hole nun eine DNS-Anfrage, schaut er durch seine Blocklisten und blockt alle Domains auf der Blockliste. Dadurch können diese Teile vom Browser nicht geladen werden. Da Werbung im Regelfall über eine externe Internetadresse geladen wird und nicht direkt im HTML der Website verankert ist, sollte die Website weiterhin laden und nur die Werbeelemente blockiert werden.

Man muss allerdings dazusagen dass, da Pi-Hole nur nach Domains filtern kann, das Ergebnis meiste nicht so gut ist wie eine Browser-Erweiterung. Dafür hat er den Vorteil, das er auf allen Geräten wirkt, also auch auf Smartphones und Tablets. Außerdem spricht nichts dagegen den Pi-Hole mit einem Browser-PlugIn zu kombinieren.

Wie beantwortet Pi-Hole nicht geblockte DNS-Anfragen

Gehen wir nun davon aus, es wird eine Domain angefragt, die nicht auf einer der Blocklisten steht. Der Pi-Hole muss nun natürlich eine IP Adresse zurück geben, da der Client sonst nicht weiter arbeiten kann. Doch woher bekommt der Pi-Hole diese Information?

Für diesen Fall hat man bei der Installation einen Upstream DNS-Provider ausgewählt (Google, Cloudflare, etc…). Der Pi-Hole gibt sich nun als Client aus und stellt eine rekursive Anfrage an den Upstream DNS-Provider. Dieser gibt ihm darauf hin die IP Adresse der Domain, die der Pi-Hole an den Client weiter gibt.

Wir können also nun Domains blocken, allerdings haben wir immer noch das Problem, dass wir auf einen Upstream DNS-Provider angewiesen sind. Wir haben also noch keinen der Punkte in der Einleitung gelöst.

An dieser Stelle kommt Unbound ins Spiel.

Was ist Unbound

Unbound ist ein leightweight lokaler DNS-Server mit Caching Funktion. Er nimmt also die Rolle des Upstream DNS-Providers ein. Wenn er eine rekursive Anfrage eines Clients bekommt, fragt er die IP Adresse über interative Anfragen zuerst bei den Root-DNS-Servern, dann bei den Top-Level-Domain-Servern und zum Schluss bei dem Autoiterativen DNS-Server nach und gibt die IP Adresse and den Client zurück.

Wer hier nicht mit gekommen ist, sollte sich nochmal die Erklärung zu DNS anschauen.

Das ist natürlich ein deutlich längerer Web als über den Upstream DNS-Server, allerdings geht nun nicht mehr der gesamte DNS Verkehr über einen Server sondern verteilt sich auf viele verschiedene. Dadurch lässt sich schlechter zurück verfolgen, welcher Nutzer welche Websites aufgerufen hat.

Um dem längeren Weg und die damit verbunden Verzögerungen zu minimieren, führt Unbound einen Cache. Das heißt jede IP Adresse die er infolge einer Anfrage zurück bekommt, speichert er zusammen mit der Domain. So muss er beim nächsten mal nur in seinem Cache schauen und kann die Anfrage sofort beantworten.

Das heißt in der Regel, dass die erste Anfrage einer Domain länger dauert als bei einem Upstream DNS-Provider, jeder weitere Anfrage der Domain ist aber in der Regel schneller, weil die Anfrage Netzwerkintern beantwortet wird.

Um auf möglicherweise wechselnde IP Adressen reagieren zu können ist der Unbound Cache nicht unendlich gültig, sondern läuft irgendwann ab. Allerdings frischt Unbound diese Einträge in festen Intervallen wieder auf, wodurch möglichst viele Anfragen aus dem Cache beantwortet werden.

Unbound installation

Der Original Artikel zur Installation findet sich hier.

Ich gehe hier davon aus, dass Pi-Hole bereits installiert ist und läuft. Außerdem sind die folgenden Befehle für Ubuntu bzw. Raspberry-OS.

Als erstes installiert man Unbound aus dem Repository

sudo apt install unbound

Danach müssen wir eine Konfiguration für den Pi-Hole erstellen. Dazu öffnen wir die Date /etc/unbound/unbound.conf.d/pi-hole.conf mit einem beliebigen Editor (nano, vim, etc…) und fügen folgende Konfiguration ein.

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Danach müssen wir Unbound einmal neustarten

sudo service unbound restart

Nun ist Unbound einsatzbereit.

Unbound als DNS-Server auf dem Pi-Hole einrichten

Nun müssen wir dem Pi-Hole noch mitteilen, dass er bitte unseren Unbound Server anstelle des Upstream DNS-Proviers nutzen soll.

Dazu gehen wir zuerst auf die Weboberfläche (<Ip des Pi-Hole>/admin) und loggen uns ein.

Danach gehen wir links auf Settings und dann auf den Reiter DNS.

Nun löschen wir alle Harken bei den Upstream-DNS Servern und tragen Custom 1 127.0.0.1:5335 ein und setzen den Harken.

Das ganze sollte dann wie folgt aussehen:

Danach gehen wir unten rechts auf Save und unsere Pi-Hole nutzt von nun an den Unbound DNS-Server anstelle eines Upstream DNS-Providers.