Das Domain Name System (DNS) ist das Telefonbuch des Internets: Jede Anfrage an eine Website beginnt mit einer DNS-Abfrage, die den Domainnamen in eine IP-Adresse auflöst. Pi-hole setzt genau an diesem Punkt an. Als netzwerkweiter DNS-Resolver beantwortet Pi-hole alle DNS-Anfragen der Clients im lokalen Netz – und blockiert bekannte Werbe-, Tracking- und Malware-Domains, bevor eine einzige Verbindung aufgebaut wird.
Der entscheidende Unterschied zu einem Browser-Werbeblocker wie uBlock Origin liegt im Wirkungsbereich: Ein Browser-Addon greift nur im jeweiligen Browser auf einem einzelnen Gerät. Pi-hole hingegen wirkt auf Netzwerkebene und schützt damit alle Geräte im Heimnetz gleichzeitig – PCs, Laptops, Smartphones, Smart-TVs, IoT-Geräte und Spielekonsolen. Selbst Apps, die keine Erweiterungen unterstützen, profitieren von der Filterung.
Technisch ersetzt Pi-hole den DNS-Server, der üblicherweise vom Router vergeben wird. Statt Anfragen direkt an einen öffentlichen Resolver (z. B. den des Internetanbieters oder 8.8.8.8) weiterzuleiten, beantwortet Pi-hole blockierte Domains mit der IP-Adresse 0.0.0.0 (IPv4) bzw. :: (IPv6). Der anfragende Client erhält so keine gültige IP zurück – die Verbindung wird still verworfen, ohne dass eine Anzeige geladen wird. Legitime Anfragen werden transparent an einen konfigurierten Upstream-DNS-Server weitergeleitet.
2. Installation
Pi-hole lässt sich auf verschiedene Weisen betreiben. Empfohlen für ein dauerhaft laufendes Heimnetz ist eine dedizierte Instanz auf einem Raspberry Pi, als Docker-Container oder in einer leichtgewichtigen VM.
2.1 Raspberry Pi (natives Setup)
Auf einem Raspberry Pi mit Raspberry Pi OS (Debian-basiert) genügt ein einziger Befehl für die Installation:
curl -sSL https://install.pi-hole.net | bash
Das interaktive Installationsskript führt durch die Konfiguration des Upstream-DNS-Servers, der Blocklisten und der Netzwerkschnittstelle. Nach der Installation ist das Web-Interface unter http://<pi-ip>/admin erreichbar. Das Admin-Passwort wird am Ende der Installation angezeigt und kann jederzeit mit pihole -a -p geändert werden. Wichtig: Dem Raspberry Pi sollte eine statische IP-Adresse zugewiesen werden, entweder über den Router per DHCP-Reservation oder direkt im Betriebssystem.
2.2 Docker-Container (empfohlen)
Für alle, die bereits Docker betreiben, ist der Container-Ansatz flexibler und leichter zu warten. Das offizielle Image ist pihole/pihole. Eine typische docker-compose.yml:
Der network_mode: host ist auf Linux notwendig, damit Pi-hole Port 53 (DNS) direkt belegen kann. Auf Systemen, auf denen systemd-resolved aktiv ist (z. B. Ubuntu), muss der lokale DNS-Stub-Listener zuerst deaktiviert werden:
Wer Pi-hole in einer VM betreiben möchte, empfiehlt sich ein minimales Debian oder Ubuntu Server als Basis. Ein LXC-Container in Proxmox mit 512 MB RAM und einer virtuellen CPU ist vollkommen ausreichend. Die Installation erfolgt anschließend identisch zur Raspberry-Pi-Methode via Installationsskript. Der Container sollte eine privilegierte Netzwerkkonfiguration erhalten, damit dnsmasq auf Port 53 lauschen kann.
3. FTL DNS – Der Kern von Pi-hole
Pi-hole verwendet seit Version 4 einen eigenen DNS-Resolver namens FTL (Faster Than Light). FTL ist ein in C geschriebener, schlanker DNS-Forwarder, der auf dnsmasq aufbaut und speziell für die Anforderungen von Pi-hole optimiert wurde.
FTL übernimmt mehrere Aufgaben gleichzeitig: Es verarbeitet eingehende DNS-Anfragen, gleicht sie gegen die Blocklist-Datenbank ab (gespeichert in einer lokalen SQLite-Datenbank unter /etc/pihole/gravity.db), leitet legitime Anfragen an den Upstream-Resolver weiter und protokolliert alle Abfragen in Echtzeit. Aus diesen Protokolldaten speist sich das Web-Dashboard mit Statistiken wie Gesamtanfragen, Blockrate, meistgefragte Domains und aktivste Clients.
Die Blocklist-Verarbeitung erfolgt über den Befehl pihole -g (Gravity), der alle konfigurierten Blocklist-URLs herunterlädt, dedupliziert und in die SQLite-Datenbank importiert. Dieser Vorgang kann manuell ausgelöst oder per Cronjob automatisiert werden. Pi-hole richtet standardmäßig eine wöchentliche Aktualisierung ein. FTL lädt die aktualisierte Datenbank ohne Neustart ein, sodass es zu keiner Unterbrechung der DNS-Auflösung kommt.
Die Qualität der Pi-hole-Installation steht und fällt mit der Auswahl guter Blocklisten. Standardmäßig bringt Pi-hole die StevenBlack Unified Hosts-Liste mit, die eine solide Basis für Werbung und Tracking bietet.
Advertising Lists – Werbeanbieter und Ad-Tracking-Netzwerke
Tracking & Telemetry – Nutzungsdaten-Übertragungen, Telemetrie von Betriebssystemen und Apps
Malicious Lists – bekannte Malware, Phishing und Botnet-C2-Server
Other Lists – diverse Kategorien wie Kryptomining und Fakenews-Domains
Firebog kennzeichnet Listen mit einem Häkchen (Tick), wenn sie als besonders zuverlässig und mit wenigen False Positives gelten. Für die meisten Heimnetz-Setups empfiehlt sich der Import aller Tick-markierten Listen. Die URLs lassen sich direkt im Pi-hole Web-UI unter Group Management → Adlists eintragen.
Nach dem Hinzufügen der Adlists muss pihole -g ausgeführt werden, damit die neuen Listen heruntergeladen und in die Gravity-Datenbank importiert werden.
4.2 Regex-Filter
Für Domains, die sich nicht als feste Einträge listen lassen, bietet Pi-hole reguläre Ausdrücke. Regex-Filter werden unter Blacklist → RegEx filter gepflegt. Reguläre Ausdrücke in Pi-hole folgen der POSIX-ERE-Syntax:
# Alle Subdomains von doubleclick.net blockieren
(^|\.)doubleclick\.net$
# Telemetrie-Subdomains von Microsoft blockieren
^.+\.data\.microsoft\.com$
# Google Analytics blockieren
(^|\.)google-analytics\.com$
# Alle .telemetry-Domains blockieren
.*\.telemetry\..*
4.3 Whitelist für falsche Positiv-Treffer
Aggressivere Blocklisten erzeugen gelegentlich False Positives – legitime Dienste, die fälschlicherweise blockiert werden. Klassische Kandidaten sind CDN-Domains, Microsoft-Login-Dienste oder Captive-Portale. Die Whitelist lässt sich im Web-UI oder per CLI verwalten:
# Domain zur Whitelist hinzufügen
pihole -w example.com
# Häufig benötigte Whitelist-Einträge
pihole -w fonts.googleapis.com
pihole -w fonts.gstatic.com
pihole -w clients.l.google.com
# Whitelist anzeigen
pihole -w -l
# Domain aus der Whitelist entfernen
pihole -w -d example.com
Das Query-Log im Dashboard hilft dabei, blockierte Anfragen zu identifizieren. Ein Klick auf eine blockierte Domain öffnet direkt die Option, sie zur Whitelist hinzuzufügen oder den blockierenden Listeneintrag zu inspizieren.
5. Lokale DNS-Einträge für Heimnetz-Dienste
Eine der praktischsten Funktionen von Pi-hole ist die Möglichkeit, eigene DNS-Einträge für lokale Dienste zu pflegen. Statt IP-Adressen auswendig lernen zu müssen, lassen sich sprechende Hostnamen vergeben – etwa proxmox.local, nas.local oder homeassistant.local.
5.1 Lokale DNS-Records im Web-UI
Im Pi-hole Web-Interface findet sich unter Local DNS → DNS Records die Verwaltungsoberfläche für eigene A-Records. Domain und Ziel-IP werden dort direkt eingetragen. Änderungen sind sofort wirksam, ohne dass Pi-hole neugestartet werden muss:
Alternativ können die Einträge direkt als dnsmasq-Konfigurationsdatei hinterlegt werden. Eigene dnsmasq-Konfigurationsdateien werden im Verzeichnis /etc/dnsmasq.d/ abgelegt und beim Start von FTL eingelesen:
Unter Local DNS → CNAME Records lassen sich Aliase für bereits definierte DNS-Einträge anlegen. Das ist nützlich, wenn mehrere Dienste auf demselben Host laufen, zum Beispiel mehrere virtuelle Hosts hinter einem Reverse Proxy wie Nginx Proxy Manager oder Traefik:
Nach Änderungen an Konfigurationsdateien sollte der DNS-Dienst neu gestartet werden: pihole restartdns.
6. Upstream-DNS und DNS-over-HTTPS
Der Upstream-DNS-Server ist der Resolver, an den Pi-hole alle nicht-blockierten Anfragen weiterleitet. Die Wahl des Upstream-Servers beeinflusst Datenschutz, Geschwindigkeit und Sicherheit erheblich.
6.1 Öffentliche Resolver
Häufig genutzte öffentliche Resolver für Pi-hole und deren Besonderheiten:
Cloudflare (1.1.1.1 / 1.0.0.1) – sehr schnell, datenschutzorientiert, keine Protokollierung von Nutzer-IP laut Richtlinie
Quad9 (9.9.9.9 / 149.112.112.112) – blockiert zusätzlich bekannte Malware-Domains auf DNS-Ebene, gemeinnützige Schweizer Organisation
Google (8.8.8.8 / 8.8.4.4) – weit verbreitet und sehr zuverlässig, aber aus Datenschutzsicht bedenklich
Mehrere Upstream-Server können gleichzeitig eingetragen werden. Pi-hole verwendet dann den schnellsten verfügbaren Resolver.
6.2 Unbound als rekursiver Resolver
Die datenschutzfreundlichste Variante ist die Kombination von Pi-hole mit Unbound. Unbound ist ein vollwertiger, rekursiver DNS-Resolver, der Anfragen direkt bei den autoritativen Nameservern der jeweiligen TLD auflöst – ohne Zwischenstation bei einem kommerziellen Anbieter. Die Anfragen verlassen das Heimnetz nur fragmentiert an viele verschiedene Nameserver.
Anschließend wird in Pi-hole als Upstream-DNS der Wert 127.0.0.1#5335 eingetragen (Custom 1 im Einstellungsmenü). Damit übernimmt Pi-hole die Filterung, Unbound die vollständige rekursive Auflösung.
DNS-over-HTTPS (DoH) verschlüsselt DNS-Anfragen über HTTPS und verhindert, dass der Internetanbieter den DNS-Verkehr im Klartext mitlesen kann. cloudflared ist der offizielle Tunnel-Client von Cloudflare und kann als lokaler DoH-Proxy eingesetzt werden, der auf Port 5053 lauscht und Anfragen verschlüsselt an Cloudflaresserver weiterleitet:
# cloudflared installieren (ARM64, z. B. Raspberry Pi 4)
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm64.deb
sudo dpkg -i cloudflared-linux-arm64.deb
# Systemd-Service-Datei: /etc/systemd/system/cloudflared.service
[Unit]
Description=cloudflared DNS over HTTPS proxy
After=network.target
[Service]
Type=simple
User=cloudflared
ExecStart=/usr/local/bin/cloudflared proxy-dns \
--port 5053 \
--upstream https://1.1.1.1/dns-query \
--upstream https://1.0.0.1/dns-query
Restart=on-failure
[Install]
WantedBy=multi-user.target
# Service aktivieren
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
# Pi-hole Upstream-DNS anschließend konfigurieren auf:
# 127.0.0.1#5053
7. Pi-hole als DHCP-Server
Standardmäßig wird Pi-hole im Heimnetz als DNS-Server eingetragen – entweder manuell im Router oder per DHCP-Option des Routers. Eine elegantere Alternative ist, Pi-hole selbst als DHCP-Server zu betreiben und den DHCP-Dienst im Router zu deaktivieren.
Der Vorteil: Pi-hole vergibt die IP-Adressen an alle Clients und trägt sich dabei direkt als DNS-Server ein. Es ist keine gesonderte Router-Konfiguration nötig, und auch Geräte, die ihren DNS-Server manuell überschreiben würden (z. B. Smart-TVs mit hart verdrahteten Google-DNS-IPs), werden zuverlässig über Pi-hole geleitet – solange sie DHCP verwenden.
Der DHCP-Server wird im Web-UI unter Settings → DHCP aktiviert. Dort werden Adressbereich, Gateway und optionale statische Leases konfiguriert:
# DHCP-Konfiguration (via Web-UI oder /etc/dnsmasq.d/02-pihole-dhcp.conf):
dhcp-range=192.168.1.100,192.168.1.200,24h
dhcp-option=option:router,192.168.1.1
dhcp-option=option:dns-server,192.168.1.2
# Statische DHCP-Leases (MAC-Adresse → IP → Hostname):
dhcp-host=dc:a6:32:xx:xx:xx,192.168.1.10,proxmox
dhcp-host=b8:27:eb:xx:xx:xx,192.168.1.20,nas
dhcp-host=aa:bb:cc:xx:xx:xx,192.168.1.30,homeassistant
Statische Leases stellen sicher, dass wichtige Heimnetz-Server immer dieselbe IP erhalten – unabhängig von der Lease-Zeit. Im Dashboard erscheinen alle bekannten Clients mit Hostnamen, was das Query-Log deutlich lesbarer macht und die Zuordnung von DNS-Anfragen zu einzelnen Geräten vereinfacht.
8. Redundanz mit Gravity Sync
Ein einzelner Pi-hole ist ein Single Point of Failure: Fällt er aus, etwa bei einem Update, einem Neustart oder einem Stromausfall, funktioniert die DNS-Auflösung im gesamten Heimnetz nicht mehr. Die Lösung ist eine zweite Pi-hole-Instanz als Fallback-DNS-Server.
Der Router (oder der Pi-hole-eigene DHCP-Server) kann zwei DNS-Server eingetragen bekommen – den primären und den sekundären Pi-hole. Clients nutzen automatisch den zweiten, wenn der erste nicht innerhalb eines Timeouts antwortet.
8.1 Gravity Sync einrichten
Das Problem bei zwei unabhängigen Pi-hole-Instanzen ist die Synchronisierung: Blocklisten, Whitelist, Blacklist, Regex-Filter und lokale DNS-Einträge müssen auf beiden Instanzen identisch sein. Gravity Sync ist ein Shell-Skript, das genau das automatisiert – per SSH-basierter Replikation vom primären auf den sekundären Pi-hole.
# Gravity Sync auf dem primären Pi-hole installieren
curl -sSL https://raw.githubusercontent.com/vmstan/gravity-sync/master/gs-install.sh | bash
# SSH-Key-Authentifizierung für den sekundären Pi-hole einrichten
ssh-keygen -t ed25519 -C "gravity-sync"
ssh-copy-id pi@192.168.1.12
# Konfigurationsdatei: /etc/gravity-sync/gravity-sync.conf
REMOTE_HOST="192.168.1.12"
REMOTE_USER="pi"
# Synchronisierung testen (zeigt Unterschiede an)
gravity-sync compare
# Gravity-Datenbank und Konfiguration vom primären auf den sekundären Pi-hole übertragen
gravity-sync push
# Automatische Synchronisierung alle 15 Minuten einrichten
gravity-sync automate
Gravity Sync überträgt per SSH die SQLite-Datenbank (gravity.db), die Konfigurationsdateien sowie die benutzerdefinierten Listen vom primären auf den sekundären Pi-hole. Nach einem Push wird auf dem sekundären Server automatisch pihole restartdns ausgeführt, sodass die neuen Einträge sofort aktiv sind.
Mit zwei synchronisierten Pi-hole-Instanzen und einem DHCP-Server, der beide als DNS-Server einträgt, entsteht eine ausfallsichere DNS-Filterung für das gesamte Heimnetz. Fällt eine Instanz aus oder wird sie für Updates neu gestartet, übernimmt die andere nahtlos – ohne dass Nutzer im Netz eine Unterbrechung bemerken.