Grafana – Monitoring & Visualisierung mit Docker
20. August 2026
1. Einleitung & Das Problem mit Standard-DNS
Warum reicht ein normales Pi-hole oft nicht aus? Ein Pi-hole blockiert zwar Werbung und Tracker, leitet alle verbleibenden DNS-Anfragen standardmäßig aber immer noch an Drittanbieter wie Google, Cloudflare oder deinen Internetanbieter (ISP) weiter. Diese Anbieter können Profile über dein gesamtes Surfverhalten erstellen.
Die Lösung ist Unbound. Unbound arbeitet auf deinem Server als validierender, eigener rekursiver DNS-Resolver. Statt einen kommerziellen Zwischenhändler zu fragen, hangelt sich Unbound bei einer Anfrage direkt von den offiziellen Root-Nameservern der IANA bis zur Ziel-Domain durch.
• Deine Privatsphäre: Es gibt keinen zentralen DNS-Anbieter mehr, der deine Daten sammelt.
• Deine Sicherheit: Die integrierte DNSSEC-Validierung schützt dich aktiv vor DNS-Spoofing und Cache-Poisoning (manipulierten IP-Adressen).
2. Pi-hole installieren (One-Step Automated Install)
Bevor Unbound eingerichtet werden kann, muss das Pi-hole auf dem System laufen. Wer schnell und bequem starten möchte, installiert Pi-hole mit dem folgenden offiziellen automatisierten Befehl:
curl -sSL https://install.pi-hole.net | bash
Folge einfach den Anweisungen auf dem Bildschirm, um die Grundkonfiguration (Netzwerkschnittstelle, statische IP und Passworteinrichtung) abzuschließen
3. Unbound-Installation auf dem Server
Verbinde dich erneut per SSH auf deinen Server. Aktualisiere zuerst die Paketquellen und installiere Unbound sowie die nützlichen DNS-Werkzeuge (dnsutils für den Befehl dig):
sudo apt update && sudo apt install unbound dnsutils -y
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
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 no if you don't have IPv6 connectivity
do-ip6: yes
# 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.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# 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
# Ensure no reverse queries to non-public IP ranges (RFC6303 4.2)
private-address: 192.0.2.0/24
private-address: 198.51.100.0/24
private-address: 203.0.113.0/24
private-address: 255.255.255.255/32
private-address: 2001:db8::/32
5. Root-Hints & DNSSEC einrichten
Damit Unbound weiß, wo sich die weltweit obersten DNS-Server (Root-Server) befinden, laden wir die offizielle Liste der InterNIC herunter:
wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints
Der DNSSEC-Schlüssel (root.key) wird bei modernen Debian/Ubuntu-Systemen in der Regel automatisch bei der Installation des Pakets initialisiert und unter /var/lib/unbound/root.key abgelegt.
6. Systemd-Dienst neustarten & Funktionstest
Starte Unbound neu, damit die neue Konfiguration geladen wird, und aktiviere den automatischen Start bei Systemneuboot:
sudo systemctl restart unbound sudo systemctl enable unbound
Der kritische Funktionstest an der Konsole
Prüfe nun, ob Unbound wie gewünscht auf Port 5335 antwortet und ob DNSSEC fehlerhafte Signaturen blockiert.
1. Standard-Abfrage: Muss eine IP-Adresse zurückliefern.
dig google.com @127.0.0.1 -p 5335
DNSSEC-Sicherheitstest: Diese Test-Domain besitzt absichtlich eine ungültige Signatur. Unbound muss hier mit dem Status SERVFAIL antworten und darf keine IP auflösen:
dig sigfail.atck.in @127.0.0.1 -p 5335
7. Pi-hole Web-UI Konfiguration
Sobald die Konsole grünes Licht gibt, binden wir Unbound in die grafische Oberfläche des Pi-holes ein:
1. Öffne dein Pi-hole Dashboard im Browser und navigiere zu Settings -> DNS.
2. Entferne alle Haken bei den vorgegebenen Upstream-DNS-Servern (z. B. Google, Cloudflare) auf der linken Seite.
3. Trage auf der rechten Seite unter Custom 1 (IPv4) exakt Folgendes ein:
127.0.0.1#5335
4. Setze unten rechts den Haken bei Use DNSSEC (da Unbound die Validierung übernimmt, dient dies zur sauberen Anzeige im Pi-hole Log).
5. Klicke ganz unten auf Save.
8. Wichtige Fallstricke & Troubleshooting
• Problem 1: resolvconf überschreibt die lokale DNS-Konfiguration
Auf manchen Ubuntu/Debian-Systemen installiert sich der Dienst resolvconf mit. Dieser krallt sich oft Port 53 oder überschreibt die /etc/resolv.conf bei jedem DHCP-Wechsel, was zu Konflikten mit Pi-hole führen kann.
• Lösung: Du kannst den Nameserver in der /etc/dhcp/dhclient.conf über die Zeile prepend domain-name-servers 127.0.0.1; fest verankern oder den störenden, automatischen Dienst mittels sudo systemctl disable --now resolvconf deaktivieren, falls Pi-hole die DNS-Hoheit auf dem System haben soll.
• Problem 2: Höhere Ladezeiten beim allerersten Aufruf einer Webseite
Es ist völlig normal, dass der erste Aufruf einer unbekannten Webseite direkt nach der Einrichtung gefühlt 100 bis 300 Millisekunden länger dauert. Unbound muss die Domainhierarchie von ganz oben (Root-Nameserver) herab abfragen.
• Entwarnung: Dank des in Schritt 4 konfigurierten, großzügigen RAM-Caches und der prefetch-Funktion sinkt die Antwortzeit bei jedem Folgeaufruf auf unter 1 ms. Unbound wird dadurch im Alltag extrem schnell.
