Eintrag

Pi-hole: Das schwarze Loch für Werbung in deinem Netzwerk

Veröffentlicht Aktualisiert
Preview Image
Von Darth Vaper
23 Minuten Lesezeit
Pi-hole: Das schwarze Loch für Werbung in deinem Netzwerk

2014 startete Pi-hole als kleines Raspberry Pi Projekt. Heute ist es der meistgenutzte selbstgehostete Adblocker weltweit - mit über 50.000 GitHub Stars und Millionen von Installationen. Das Konzept ist brillant einfach: Pi-hole agiert als DNS-Sinkhole in deinem Netzwerk. Werbung verschwindet nicht nur im Browser, sondern auf allen Geräten - Smart-TVs, Smartphones, IoT-Devices. Die Ads werden gar nicht erst geladen, sie verschwinden einfach ins schwarze Loch.

Was ist Pi-hole?

Pi-hole ist der Original-Platzhirsch unter den netzwerkweiten DNS-Adblockern. Anders als Browser-Extensions blockiert Pi-hole Werbung und Tracker auf DNS-Ebene - für alle Geräte im Netzwerk gleichzeitig.

Die wichtigsten Eigenschaften:

  • DNS-Sinkhole: Blockierte Domains werden zu 0.0.0.0 aufgelöst
  • Netzwerkweiter Schutz: Alle Geräte profitieren automatisch
  • Schönes Admin-Dashboard: Detaillierte Statistiken und Live-Monitoring
  • FTL-Engine: Eigener Fork von dnsmasq, optimiert für Performance
  • Flexibel einsetzbar: Raspberry Pi, VMs, Docker, bare metal
  • Riesige Community: Ausgereiftes Blocklist-Ökosystem mit tausenden Listen
  • Open Source: Vollständig transparent und erweiterbar

Die aktuelle Version 6 bringt signifikante Verbesserungen bei Performance und Gruppenmanagement. Das Projekt wird aktiv weiterentwickelt und hat sich zum De-facto-Standard für DNS-basiertes Adblocking entwickelt.

Pi-hole wurde ursprünglich für den Raspberry Pi entwickelt, läuft aber auf praktisch jeder Linux-Plattform. Der Name ist eine Anspielung auf das “DNS black hole” Konzept.

Wie funktioniert Pi-hole?

Das Grundprinzip ist elegant: Pi-hole sitzt zwischen deinen Clients und dem Internet und filtert DNS-Anfragen.

sequenceDiagram
    participant Client
    participant Pi-hole
    participant Upstream DNS
    participant Internet

    Client->>Pi-hole: DNS-Anfrage: ads.example.com
    Pi-hole->>Pi-hole: Prüfe gegen Gravity DB
    Pi-hole-->>Client: Blockiert! → 0.0.0.0

    Client->>Pi-hole: DNS-Anfrage: example.com
    Pi-hole->>Pi-hole: Nicht blockiert
    Pi-hole->>Upstream DNS: Forwarding
    Upstream DNS->>Internet: Rekursive Auflösung
    Internet-->>Upstream DNS: IP: 93.184.216.34
    Upstream DNS-->>Pi-hole: IP: 93.184.216.34
    Pi-hole-->>Client: IP: 93.184.216.34

Der Ablauf im Detail:

  1. Client sendet DNS-Query: Dein Browser will wissen, wo ads.tracker.com zu finden ist
  2. Pi-hole prüft Gravity: Die Query wird gegen die Blocklist-Datenbank geprüft
  3. Blockiert: Domain steht auf der Blocklist → Antwort: 0.0.0.0
  4. Erlaubt: Domain ist sauber → Weiterleitung an Upstream DNS
  5. Upstream antwortet: Pi-hole gibt die echte IP zurück an den Client

Gravity - das Herzstück:

“Gravity” ist Pi-holes Begriff für seine Blocklist-Datenbank. Der Name kommt vom Update-Befehl pihole -g (für “gravity”). Bei einem Gravity-Update lädt Pi-hole alle konfigurierten Blocklisten herunter, bereinigt sie, dedupliziert die Einträge und kompiliert sie in eine hochoptimierte Datenbank.

Das Ergebnis: Blitzschnelle Lookups für Millionen von Domains. Ein typischer Gravity-Block enthält 1-3 Millionen blockierte Domains und belastet moderne Hardware kaum.

Die FTL-Engine (Faster Than Light) ist Pi-holes eigene Fork von dnsmasq. Sie ist speziell für das Handling von riesigen Blocklisten optimiert und speichert alle Queries für Statistiken.

Features im Überblick

Pi-hole hat sich über die Jahre zu einer Feature-reichen Lösung entwickelt:

Feature Beschreibung
Gravity Blocklist-Datenbank mit automatischen Updates
Admin Dashboard Übersichtliche Web-UI mit Queries, Clients, Top-Domains
Query Log Live-Tail aller DNS-Anfragen mit Filter-Optionen
Group Management Blocklisten pro Client-Gruppe (Familie, IoT, Gäste)
Local DNS Records Eigene DNS-Einträge für lokale Dienste
Conditional Forwarding Reverse DNS für lokale IPs
Regex-Filter Mächtige Pattern-basierte Blockierung
Wildcard-Blocking Blockiere *.ads.com auf einmal
API JSON-API für externe Tools und Monitoring
Teleporter Backup/Restore mit einem Klick
DHCP Server Optional: Ersetze deinen Router-DHCP
Long Term Database Historische Statistiken über Monate

Gravity Management:

1
2
3
4
5
6
7
8
9
10
11

# Gravity-Update durchführen
pihole -g

# Nur bestimmte Liste aktualisieren
pihole -g --update-lists

# Statistiken anzeigen
pihole -c

# Query Log live verfolgen
pihole -t

Die Gruppenverwaltung ist besonders praktisch: Du kannst unterschiedliche Filterebenen für verschiedene Gerätegruppen definieren. Kids bekommen strengere Filter, IoT-Devices werden komplett isoliert, und dein eigenes Gaming-Setup läuft mit minimalen Blockierungen.

Installation mit Docker

Die Docker-Installation ist die flexibelste Variante und perfekt fürs Homelab:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

version: '3.8'

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"    # Web UI (oder anderer freier Port)
    volumes:
      - ./pihole/etc:/etc/pihole
      - ./pihole/dnsmasq:/etc/dnsmasq.d
    environment:
      - TZ=Europe/Berlin
      - WEBPASSWORD=changeme              # Dashboard-Passwort
      - FTLCONF_LOCAL_IPV4=192.168.1.100  # Pi-hole's eigene IP
      - PIHOLE_DNS_=1.1.1.1;8.8.8.8       # Upstream DNS (Cloudflare, Google)
      - DNSMASQ_LISTENING=all             # Lausche auf allen Interfaces
    cap_add:
      - NET_ADMIN                         # Für DHCP (optional)
    restart: unless-stopped

Wichtige Hinweise:

  1. Port 53 Konflikt: Wie bei AdGuard Home muss Port 53 frei sein. Falls systemd-resolved läuft:
1
2
3
4
5
6
7

# systemd-resolved deaktivieren
sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved

# /etc/resolv.conf anpassen
sudo rm /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
  1. WEBPASSWORD setzen: Ohne Passwort ist das Dashboard offen zugänglich
  2. FTLCONF_LOCAL_IPV4: Die IP-Adresse, unter der Pi-hole erreichbar ist
  3. Upstream DNS: Später durch Unbound ersetzen für maximale Privacy

Container starten:

1
2
3
4
5
6
7

docker compose up -d

# Logs prüfen
docker logs -f pihole

# Status checken
docker exec pihole pihole status

Falls du bereits AdGuard Home auf Port 53 laufen hast, kannst du Pi-hole nicht gleichzeitig betreiben. Du musst dich für einen entscheiden oder Pi-hole auf einem anderen Port laufen lassen (weniger praktisch).

Ersteinrichtung

Nach dem Start ist Pi-hole sofort einsatzbereit:

1. Dashboard aufrufen:

Öffne http://192.168.1.100/admin (oder deine Pi-hole IP)

2. Einloggen:

  • Benutzername: (keiner nötig)
  • Passwort: Das in WEBPASSWORD gesetzte

3. DNS-Einstellungen prüfen:

  • Gehe zu Settings → DNS
  • Prüfe die Upstream DNS Server (1.1.1.1, 8.8.8.8)
  • Optional: Rate Limiting aktivieren (1000/60s ist ein guter Start)

4. Router-DHCP konfigurieren:

In deinem Router (z.B. Fritz!Box, UniFi):

  • Primärer DNS: 192.168.1.100 (Pi-hole)
  • Sekundärer DNS: 1.1.1.1 (Fallback)

5. Warten oder forcieren:

  • DHCP-Leases erneuern sich automatisch (kann Stunden dauern)
  • Oder forcieren: Geräte neu verbinden / DNS-Cache leeren
1
2
3
4
5
6
7
8
9

# Windows
ipconfig /flushdns

# macOS/Linux
sudo dscacheutil -flushcache  # macOS
sudo systemd-resolve --flush-caches  # Linux

# Android/iOS
Flugmodus an/aus

Erste Queries beobachten:

Im Dashboard siehst du sofort Aktivität:

  • Total Queries: Alle DNS-Anfragen
  • Queries Blocked: Wie viele geblockt wurden
  • Percent Blocked: Typisch 15-30% bei normaler Nutzung
  • Top Permitted Domains: Die am meisten genutzten erlaubten Domains
  • Top Blocked Domains: Was Pi-hole abfängt

Nach der ersten Einrichtung sieht das Dashboard oft leer aus. Sobald die DHCP-Leases erneuert sind und Clients Pi-hole nutzen, füllt es sich mit Statistiken.

Gravity: Filterlisten verwalten

Gravity ist das Herzstück von Pi-hole - die Blocklist-Datenbank, die entscheidet, was blockiert wird.

Standard-Blocklists:

Pi-hole kommt mit einer Basis-Liste:

  • Steven Black’s Unified List: ~150.000 Domains (Ads + Malware)

Das ist ein guter Start, aber für optimalen Schutz willst du mehr Listen.

Empfohlene Blocklists:

Liste Domains Beschreibung
OISD Big ~1.5M Aggressives Blocking, viele False Positives
OISD Small ~100k Konservativ, wenig False Positives
HaGeZi Multi Pro ~900k Ausgewogen, gut gepflegt
Developer Dan Ads & Tracking ~600k Fokus auf Tracking
EasyList ~70k Browser-Adblock-Liste, DNS-kompatibel
1Hosts Pro ~1.2M Sehr aggressiv

Listen hinzufügen:

  1. Group Management → Adlists
  2. Neue URL einfügen: 
    1
2
3

    https://big.oisd.nl/
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/domains/pro.txt
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  3. Save and Update
  4. Gravity-Update läuft automatisch

Manuelles Gravity-Update:

1
2
3
4
5
6
7
8
9
10
11

# Alle Listen neu laden
docker exec pihole pihole -g

# Statistik der Gravity-Datenbank
docker exec pihole pihole -g -l

# Beispiel-Output:
# [i] Number of gravity domains: 2,847,391
# [i] Number of exact blocked domains: 2,847,391
# [i] Number of regex filters: 23
# [i] Number of wildcard filters: 8

Best Practices:

  • Nicht übertreiben: 3-5 gute Listen reichen völlig
  • Duplikate sind egal: Pi-hole dedupliziert automatisch
  • Regelmäßige Updates: Wöchentlich via Cron empfohlen
  • Query Log checken: Schaue nach False Positives
1
2

# Cron-Job für wöchentliches Gravity-Update
0 3 * * 0 docker exec pihole pihole -g

OISD Small ist ein guter Start für die meisten User. OISD Big ist extrem aggressiv und kann legitime Dienste blockieren. Taste dich langsam ran.

Probleme mit Blocklists:

Falls eine Liste nicht lädt:

  • URL in Browser testen (manche sind down)
  • Format prüfen (Pi-hole braucht hosts- oder domain-Format)
  • Gravity-Log checken: /var/log/pihole/pihole.log

Gruppen-Management

Seit Version 5 bietet Pi-hole ausgereiftes Gruppen-Management. Du kannst verschiedene Filterregeln für verschiedene Clients definieren.

Use Cases:

  • Kids-Gruppe: Extra strikte Filter + Jugendschutz-Listen
  • IoT-Gruppe: Blockiere alles außer essentiellen Domains
  • Gaming-Gruppe: Minimales Blocking für beste Performance
  • Standard-Gruppe: Normale Filter für alle anderen

Gruppen erstellen:

  1. Group Management → Groups
  2. Neue Gruppe anlegen: z.B. “Kids”, “IoT”, “Default”
  3. Optional: Beschreibung hinzufügen

Clients zu Gruppen zuweisen:

  1. Group Management → Clients
  2. Client finden (wird automatisch erkannt nach ersten Queries)
  3. Gruppen-Zuordnung auswählen
  4. Speichern

Blocklists zu Gruppen zuweisen:

  1. Group Management → Adlists
  2. Bei jeder Liste: Gruppen auswählen, die diese Liste nutzen sollen
  3. Beispiel:
    • OISD Small → Default, Gaming
    • OISD Big → Kids
    • IoT Blocklists → IoT

Beispiel-Setup:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Gruppe "Default":
  - OISD Small
  - HaGeZi Multi Pro
  → Normales Blocking, wenig False Positives

Gruppe "Kids":
  - OISD Big
  - HaGeZi Multi Pro
  - 1Hosts Lite
  - Porn & Gambling Blocklists
  → Aggressives Blocking + Jugendschutz

Gruppe "IoT":
  - IoT Device Blocklists
  - Deny All + Whitelist nur essentielle Domains
  → Maximale Isolation

Gruppe "Gaming":
  - OISD Small only
  - Whitelists für Gaming-Services
  → Minimales Blocking, keine Performance-Einbußen

Regex-Filter pro Gruppe:

Du kannst auch Regex-Filter pro Gruppe definieren:

  1. Group Management → Domains
  2. Add Regex Filter
  3. Beispiel: ^(.+[-_.])?(ad|ads|advert|banner|tracking)[-_.] blockiert alle Subdomains mit diesen Keywords
  4. Gruppe zuweisen

Gruppen-Management ist besonders praktisch in Haushalten mit Kindern oder vielen IoT-Devices. Du musst nicht für jedes Gerät einzeln Whitelist-Regeln pflegen.

Local DNS Records

Pi-hole kann als lokaler DNS-Server für dein Homelab dienen:

Use Case:

Statt http://192.168.60.50:8096 für Jellyfin zu tippen, nutze einfach http://jellyfin.homelab.local

DNS-Einträge hinzufügen:

  1. Local DNS → DNS Records
  2. Neuen Eintrag erstellen:
    • Domain: jellyfin.homelab.local
    • IP: 192.168.60.50
  3. Speichern

Weitere Beispiele:

1
2
3
4
5

immich.homelab.local       → 192.168.60.80
plex.homelab.local         → 192.168.60.45
homeassistant.homelab.local → 192.168.30.85
truenas.homelab.local      → 192.168.2.10
proxmox.homelab.local      → 192.168.60.15

Limitation: Keine Wildcards:

Im Gegensatz zu AdGuard Home unterstützt Pi-hole hier keine Wildcards. Du kannst nicht einfach *.homelab.local → 192.168.60.100 definieren.

Für Wildcards brauchst du CNAME Records (siehe nächster Abschnitt).

Conditional Forwarding:

Für Reverse-DNS (IP → Hostname) aktiviere Conditional Forwarding:

  1. Settings → DNS → Advanced DNS Settings
  2. Conditional Forwarding aktivieren
  3. Lokales Netzwerk: 192.168.1.0/24
  4. Router IP: 192.168.1.1
  5. Lokale Domain: homelab.local

Jetzt zeigt Pi-hole Hostnamen statt IPs im Dashboard.

CNAME Records

Für fortgeschrittene DNS-Setups unterstützt Pi-hole CNAME Records. Das ist praktisch für Reverse Proxies.

Use Case:

Du hast einen Nginx Proxy Manager unter npm.homelab.local (192.168.60.100). Alle Dienste sollen über diesen Proxy laufen:

1
2
3

jellyfin.homelab.local  → npm.homelab.local
immich.homelab.local    → npm.homelab.local
plex.homelab.local      → npm.homelab.local

CNAME via dnsmasq:

Pi-hole nutzt dnsmasq im Hintergrund. Du kannst CNAMEs in Custom-Configs definieren:

1
2
3
4
5
6
7
8
9
10
11

# In dnsmasq-Config schreiben
docker exec pihole sh -c 'cat > /etc/dnsmasq.d/05-custom.conf << EOF
# CNAME Records für Reverse Proxy
cname=jellyfin.homelab.local,npm.homelab.local
cname=immich.homelab.local,npm.homelab.local
cname=plex.homelab.local,npm.homelab.local
cname=homeassistant.homelab.local,npm.homelab.local
EOF'

# Pi-hole DNS neu laden
docker exec pihole pihole restartdns

Persistenz:

Damit die Config nach Container-Neustart erhalten bleibt, mounte das dnsmasq-Verzeichnis als Volume (siehe docker-compose.yml oben).

Testing:

1
2
3
4
5
6

# CNAME-Auflösung testen
dig jellyfin.homelab.local @192.168.1.100

# Output sollte zeigen:
# jellyfin.homelab.local. 0 IN CNAME npm.homelab.local.
# npm.homelab.local.      0 IN A     192.168.60.100

CNAME Records sind eleganter als dutzende A-Records für jeden Dienst. Änderst du die Proxy-IP, musst du nur einen A-Record anpassen.

Pi-hole + Unbound (eigener DNS-Resolver)

Die Königsdisziplin: Pi-hole kombiniert mit Unbound für maximale Privacy.

Das Problem mit Upstream DNS:

Wenn Pi-hole an Cloudflare (1.1.1.1) oder Google (8.8.8.8) weiterleitet, sehen diese Provider alle deine DNS-Anfragen. Sie wissen genau, welche Websites du besuchst.

Die Lösung: Unbound:

Unbound ist ein rekursiver DNS-Resolver. Statt an einen Provider weiterzuleiten, fragt Unbound direkt bei den Root-Servern und autoritativen Name-Servern nach.

Vorteile:

  • Maximale Privacy: Keine Third-Party sieht deine Queries
  • Keine Zensur: Keine ISP- oder Provider-Filterung
  • Vollständige Kontrolle: Du bist dein eigener DNS-Provider

Nachteile:

  • Etwas langsamer bei der ersten Query (dann cached)
  • Minimal höherer Ressourcenverbrauch

Docker Compose mit Pi-hole + Unbound:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

version: '3.8'

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    volumes:
      - ./pihole/etc:/etc/pihole
      - ./pihole/dnsmasq:/etc/dnsmasq.d
    environment:
      - TZ=Europe/Berlin
      - WEBPASSWORD=changeme
      - FTLCONF_LOCAL_IPV4=192.168.1.100
      - PIHOLE_DNS_=unbound#5335        # Unbound als Upstream
      - DNSMASQ_LISTENING=all
    depends_on:
      - unbound
    restart: unless-stopped

  unbound:
    image: mvance/unbound:latest
    container_name: unbound
    volumes:
      - ./unbound:/opt/unbound/etc/unbound
    ports:
      - "5335:5335/tcp"
      - "5335:5335/udp"
    restart: unless-stopped

Unbound Config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

server:
    verbosity: 0
    interface: 0.0.0.0@5335
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # Privacy
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no

    # Performance
    cache-min-ttl: 3600
    cache-max-ttl: 86400
    msg-cache-size: 50m
    rrset-cache-size: 100m
    num-threads: 2

    # Security
    val-clean-additional: yes
    private-address: 192.168.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8

DNS-Flow mit Unbound:

sequenceDiagram
    participant Client
    participant Pi-hole
    participant Unbound
    participant Root-Server
    participant TLD-Server
    participant Authoritative-Server

    Client->>Pi-hole: Query: example.com
    Pi-hole->>Pi-hole: Nicht blockiert
    Pi-hole->>Unbound: Forward Query
    Unbound->>Root-Server: Wer ist für .com zuständig?
    Root-Server-->>Unbound: TLD-Server für .com
    Unbound->>TLD-Server: Wer ist für example.com zuständig?
    TLD-Server-->>Unbound: NS für example.com
    Unbound->>Authoritative-Server: A-Record für example.com?
    Authoritative-Server-->>Unbound: 93.184.216.34
    Unbound-->>Pi-hole: 93.184.216.34 (cached)
    Pi-hole-->>Client: 93.184.216.34

Setup starten:

1
2
3
4
5
6
7
8

# Beide Container starten
docker compose up -d

# Prüfen ob Unbound läuft
docker logs unbound

# Pi-hole sollte Unbound als Upstream zeigen
docker exec pihole pihole -q example.com

Testing:

1
2
3
4
5

# Query über Pi-hole
dig example.com @192.168.1.100

# Erste Query ist langsam (rekursive Auflösung)
# Zweite Query ist schnell (cached)

Mit Pi-hole + Unbound hast du die privateste DNS-Lösung, die möglich ist. Kein Provider sieht deine Queries, und du kontrollierst alles selbst.

Im Netzwerk einrichten

Jetzt müssen deine Clients Pi-hole auch nutzen. Es gibt zwei Ansätze:

Methode 1: Router-DHCP (empfohlen)

Konfiguriere deinen Router so, dass er Pi-hole als DNS-Server via DHCP verteilt.

Fritz!Box:

  1. Heimnetz → Netzwerk → Netzwerkeinstellungen
  2. IPv4-Adressen → DNSv4-Server
  3. Primärer DNS: 192.168.1.100 (Pi-hole)
  4. Sekundärer DNS: 1.1.1.1 (Fallback, falls Pi-hole ausfällt)
  5. Speichern

UniFi:

  1. Settings → Networks → Default/LAN
  2. DHCP → DHCP Name Server
  3. Manual: 192.168.1.100
  4. Apply

OPNsense/pfSense:

  1. Services → DHCPv4 → LAN
  2. DNS Servers: 192.168.1.100
  3. Save

Vorteile:

  • Alle Geräte nutzen Pi-hole automatisch
  • Neue Geräte sofort geschützt
  • Zentrale Verwaltung

Nachteile:

  • Clients müssen DHCP-Lease erneuern (kann Stunden dauern)
  • Fallback-DNS kann Pi-hole umgehen, wenn es down ist

Methode 2: Pro Gerät (nur für Tests)

Du kannst DNS auch manuell pro Gerät setzen:

Windows:

  1. Netzwerkadapter → Eigenschaften → IPv4
  2. DNS-Server: 192.168.1.100

macOS:

  1. Systemeinstellungen → Netzwerk → WLAN/LAN
  2. DNS-Server: 192.168.1.100

Android/iOS:

  1. WLAN-Verbindung → Erweitert
  2. DNS: 192.168.1.100

Vorteil: Sofort aktiv, kein Warten auf DHCP

Nachteil: Manuell für jedes Gerät, unpraktisch

Der sekundäre DNS im Router ist ein zweischneidiges Schwert. Er sorgt für Redundanz, aber Clients können ihn nutzen, um Pi-hole zu umgehen, wenn es langsam ist. Für maximale Blocklist-Coverage: Nur Pi-hole als DNS setzen.

Single Point of Failure:

Pi-hole ist jetzt der zentrale DNS-Server. Wenn es ausfällt, funktioniert keine DNS-Auflösung mehr.

Lösungen:

  1. Sekundären DNS im Router setzen (1.1.1.1) - Kompromiss bei Privacy
  2. Zweites Pi-hole mit Gravity Sync (siehe nächster Abschnitt)
  3. Monitoring & Alerting einrichten

Hochverfügbarkeit mit Gravity Sync

Für produktive Umgebungen willst du Redundanz. Die Lösung: Zwei Pi-hole Instanzen mit Gravity Sync.

Setup:

  1. Primäres Pi-hole: 192.168.1.100 (pihole-01)
  2. Sekundäres Pi-hole: 192.168.1.101 (pihole-02)
  3. Gravity Sync: Synchronisiert Config & Blocklists zwischen beiden

Router DHCP:

  • Primärer DNS: 192.168.1.100
  • Sekundärer DNS: 192.168.1.101

Clients nutzen bevorzugt die erste IP, fallen aber automatisch auf die zweite zurück.

Gravity Sync installieren:

Auf dem sekundären Pi-hole:

1
2
3
4
5
6
7
8
9
10

# Gravity Sync herunterladen
curl -sSL https://gravity.vmstan.com | bash

# Konfiguration
gravity-sync config

# Eingaben:
# Remote Host: 192.168.1.100
# Remote User: pihole (falls SSH-Key vorhanden)
# Push or Pull: PULL (sekundär zieht vom primären)

Erste Synchronisation:

1
2
3
4
5
6
7
8
9

# Manuell sync testen
gravity-sync pull

# Output:
# [✓] Pulling gravity database
# [✓] Pulling custom DNS records
# [✓] Pulling adlists
# [✓] Pulling groups
# [✓] Reloading Pi-hole

Automatischer Sync via Cron:

1
2
3
4
5
6

# Cron-Job einrichten (alle 30 Minuten)
gravity-sync auto

# Crontab prüfen
crontab -l
# */30 * * * * /usr/local/bin/gravity-sync pull

Monitoring:

1
2
3
4
5

# Status checken
gravity-sync status

# Logs anzeigen
gravity-sync logs

Was wird synchronisiert:

  • Gravity-Datenbank (alle Blocklists)
  • Custom DNS Records
  • Adlists
  • Gruppen und Zuordnungen
  • Regex-Filter
  • Whitelists/Blacklists

Was wird NICHT synchronisiert:

  • Query-History
  • Statistiken
  • DHCP-Leases (falls aktiviert)

Mit Gravity Sync hast du echte Hochverfügbarkeit. Fällt ein Pi-hole aus, läuft das andere nahtlos weiter. Änderungen auf dem primären werden automatisch synchronisiert.

Vergleich: Pi-hole vs. AdGuard Home

Beide sind exzellente DNS-Adblocker. Hier die Unterschiede:

Feature Pi-hole AdGuard Home
Web-UI Klassisch, Dashboard-fokussiert Modern, übersichtlich
DNS-over-HTTPS Via Zusatz-Software (cloudflared) Nativ eingebaut
DNS-over-TLS Via Zusatz-Software (stunnel) Nativ eingebaut
DNS-over-QUIC Nein Ja (neuestes Protokoll)
Eingebauter DHCP Ja, optional Ja, optional
Local DNS A-Records manuell A-Records + Wildcards
DNS Rewrites Via dnsmasq CNAMEs Native Wildcard-Rewrites
Client-Gruppen Ja, sehr mächtig Ja, einfacher
Regex-Filter Ja Ja
API JSON-API REST-API (umfangreicher)
Unbound-Integration Via separaten Container Via separaten Container
Community Riesig, seit 2014 Wachsend, seit 2018
Blocklist-Ökosystem Ausgereifter, mehr Listen Gut, aber kleiner
Teleporter (Backup) Ja, Ein-Klick Ja, Import/Export
Ressourcenverbrauch ~50 MB RAM ~30 MB RAM
Geschrieben in Shell/PHP/C (FTL) Go
GitHub Stars 50k+ 25k+

Pi-hole Vorteile:

  • Größere, etabliertere Community
  • Ausgereifteres Blocklist-Ökosystem
  • Gruppen-Management ist mächtiger
  • Teleporter für einfache Backups
  • Mehr Third-Party-Tools und Integrationen

AdGuard Home Vorteile:

  • Moderne, schnellere Web-UI
  • DNS-over-HTTPS/TLS/QUIC nativ
  • Wildcard-DNS-Rewrites ohne dnsmasq-Hacks
  • Geringerer Ressourcenverbrauch
  • Einfachere Installation (Single Binary)
  • Bessere parental control Features

Pi-hole hat die größere Community und das ausgereiftere Blocklist-Ökosystem. AdGuard Home bietet mehr eingebaute Features wie verschlüsselte DNS-Protokolle und Wildcard-DNS-Rewrites. Beide sind ausgezeichnete Wahl - es kommt auf deine Prioritäten an.

Meine Empfehlung:

  • Pi-hole: Wenn du maximale Community-Unterstützung, Gravity Sync, und das klassische Dashboard willst
  • AdGuard Home: Wenn du moderne UI, verschlüsselte DNS-Protokolle, und Wildcard-Rewrites brauchst

Beide lassen sich nicht gleichzeitig auf Port 53 betreiben - du musst dich entscheiden.

Dashboard und Monitoring

Das Pi-hole Dashboard ist eines der Highlights:

Haupt-Dashboard:

  • Total Queries: Alle DNS-Anfragen (heute/24h)
  • Queries Blocked: Anzahl blockierter Queries
  • Percent Blocked: Typisch 15-30% bei normaler Nutzung
  • Blocklist Size: Anzahl blockierter Domains in Gravity
  • Query Types: A, AAAA, PTR, SRV, etc.
  • Top Clients: Welche Geräte fragen am meisten
  • Top Permitted Domains: Meist genutzte erlaubte Domains
  • Top Blocked Domains: Was Pi-hole am häufigsten blockt
  • Query Timeline: Grafischer Verlauf über den Tag

Query Log:

  • Live-Tail aller DNS-Anfragen
  • Filter nach:
    • Blocked/Permitted
    • Client
    • Domain
    • Query Type
  • Whitelist/Blacklist direkt aus dem Log
  • Sehr mächtig für Troubleshooting

Long Term Database:

Pi-hole speichert alle Queries in einer SQLite-DB:

  • Historische Statistiken über Monate
  • Trendanalysen
  • Export für externe Tools

API für externe Monitoring:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Statistiken abrufen
curl "http://192.168.1.100/admin/api.php?summary"

# Output (JSON):
# {
#   "domains_being_blocked": 2847391,
#   "dns_queries_today": 12453,
#   "ads_blocked_today": 3421,
#   "ads_percentage_today": 27.46
# }

# Mit Auth-Token für mehr Details
curl "http://192.168.1.100/admin/api.php?topItems=10&auth=YOUR_TOKEN"

Homepage Dashboard Widget:

Falls du Homepage (https://github.com/gethomepage/homepage) nutzt:

1
2
3
4
5
6
7

- Pi-hole:
    icon: pi-hole.png
    href: http://192.168.1.100/admin
    widget:
      type: pihole
      url: http://192.168.1.100
      key: YOUR_API_KEY

Grafana Dashboard:

Für richtig schöne Visualisierungen:

  1. Pi-hole Exporter installieren (Prometheus-Format)
  2. Prometheus scrapen lassen
  3. Grafana Dashboard importieren: https://grafana.com/grafana/dashboards/10176

Typische Metriken:

1
2
3
4

pihole_queries_total{type="blocked"} 3421
pihole_queries_total{type="forwarded"} 9032
pihole_top_queries{domain="www.google.com"} 234
pihole_top_blocked{domain="ads.tracker.com"} 89

Das Pi-hole Dashboard ist nach wie vor eines der schönsten und informativsten unter den DNS-Adblockern. Die Query-Grafiken und Top-Listen geben sofort einen Überblick.

Troubleshooting

Die häufigsten Probleme und ihre Lösungen:

Problem: “DNS resolution is not available”

1
2
3
4
5
6
7
8
9
10
11
12
13

# Docker-Container prüfen
docker logs pihole

# Häufige Ursachen:
# 1. Port 53 ist belegt
sudo netstat -tlnp | grep :53

# 2. Upstream DNS nicht erreichbar
docker exec pihole pihole -q example.com

# 3. Firewall blockiert Port 53
sudo ufw allow 53/tcp
sudo ufw allow 53/udp

Problem: Gravity-Update schlägt fehl

1
2
3
4
5
6
7
8
9
10

# Manuell testen
docker exec pihole pihole -g

# Häufige Ursachen:
# 1. Blocklist-URL ist down
# 2. Format ist falsch (nicht hosts-Format)
# 3. Netzwerkproblem im Container

# DNS im Container prüfen
docker exec pihole nslookup google.com

Problem: Zu viele False Positives

1
2
3
4
5
6
7
8
9
10
11
12

# Query Log durchsuchen
# Dashboard → Query Log → Filter nach "Blocked"

# Häufig blockiert aber gebraucht:
# - Connectivity Checks (Windows, Android)
# - CDN-Domains (akamai, cloudfront)
# - App-Analytics die für Funktion nötig sind

# Whitelist hinzufügen
docker exec pihole pihole -w example.com

# Oder via Dashboard: Whitelist → Add

Häufig zu Unrecht blockierte Domains:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Windows/Microsoft
msftconnecttest.com
www.msftconnecttest.com

# Android
connectivitycheck.gstatic.com
clients3.google.com

# Amazon/Alexa
device-metrics-us.amazon.com

# Apple
ocsp.apple.com

Problem: DNS ist langsam

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Query-Zeit messen
docker exec pihole pihole -q example.com

# Upstream DNS testen
docker exec pihole dig @1.1.1.1 example.com

# Alternativen testen:
# Cloudflare: 1.1.1.1
# Google: 8.8.8.8
# Quad9: 9.9.9.9
# CleanBrowsing: 185.228.168.168

# Upstream DNS in Pi-hole ändern:
# Settings → DNS → Upstream DNS Servers

Problem: Pi-hole ist nicht erreichbar

1
2
3
4
5
6
7
8
9
10
11
12

# Container-Status prüfen
docker ps | grep pihole

# Logs checken
docker logs pihole --tail 50

# Neustart
docker restart pihole

# Falls komplett kaputt: Container neu erstellen
docker compose down
docker compose up -d

Problem: DHCP-Lease erneuert sich nicht

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Clients forcieren DHCP-Renewal:

# Windows
ipconfig /release
ipconfig /renew

# Linux
sudo dhclient -r
sudo dhclient

# macOS
sudo ipconfig set en0 DHCP

# Router neu starten (letztes Mittel)

Der Query Log ist dein bester Freund beim Troubleshooting. Filter nach dem betroffenen Client oder Domain und schaue, was Pi-hole damit macht.

Tipps für die Praxis

Aus jahrelanger Pi-hole-Erfahrung:

CLI-Commands:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Live-Tail des Query Logs (wie tail -f)
docker exec pihole pihole -t

# Console-Statistiken (ncurses-Interface)
docker exec pihole pihole -c

# Status anzeigen
docker exec pihole pihole status

# Version checken
docker exec pihole pihole -v

# Bestimmte Domain whitelisten
docker exec pihole pihole -w example.com

# Bestimmte Domain blacklisten
docker exec pihole pihole -b ads.example.com

# Regex-Filter hinzufügen
docker exec pihole pihole -regex "^ad[s]?[0-9]*.example.com$"

# Query-History durchsuchen
docker exec pihole pihole -q example.com

Backup & Restore:

1
2
3
4
5
6
7

# Teleporter-Backup via API
curl "http://192.168.1.100/admin/scripts/pi-hole/php/teleporter.php" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -o pihole-backup-$(date +%Y%m%d).tar.gz

# Restore via Dashboard:
# Settings → Teleporter → Restore

Cron-Jobs für Automation:

1
2
3
4
5
6
7
8

# Wöchentliches Gravity-Update (Sonntag 3 Uhr)
0 3 * * 0 docker exec pihole pihole -g

# Täglicher Backup (1 Uhr nachts)
0 1 * * * curl -s "http://192.168.1.100/admin/scripts/pi-hole/php/teleporter.php" -o /backup/pihole-$(date +\%Y\%m\%d).tar.gz

# Alte Backups löschen (älter als 30 Tage)
0 2 * * * find /backup/pihole-*.tar.gz -mtime +30 -delete

Häufige Whitelists:

Diese Domains werden oft fälschlicherweise blockiert:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Microsoft Connectivity
docker exec pihole pihole -w msftconnecttest.com
docker exec pihole pihole -w www.msftconnecttest.com

# Google Connectivity (Android)
docker exec pihole pihole -w connectivitycheck.gstatic.com

# CDNs (oft in Blocklists, aber gebraucht)
docker exec pihole pihole -w s.youtube.com
docker exec pihole pihole -w clients4.google.com

# Apple
docker exec pihole pihole -w ocsp.apple.com

Performance-Tuning:

1
2
3

# In /etc/dnsmasq.d/99-performance.conf
cache-size=10000           # Größerer Cache (default: 150)
dns-forward-max=1000       # Mehr parallele Queries

Monitoring mit Homepage:

Falls du Homepage nutzt, ist das Pi-hole Widget perfekt:

1
2
3
4
5
6
7
8
9

- DNS & Ad Blocking:
    - Pi-hole:
        icon: pi-hole.png
        href: http://192.168.1.100/admin
        description: Network-wide Ad Blocker
        widget:
          type: pihole
          url: http://192.168.1.100
          key: YOUR_API_KEY

Integration mit Unbound:

Die perfekte Kombo für maximale Privacy (siehe Abschnitt oben).

Setze dir Alerts für Pi-hole-Ausfälle. Wenn Pi-hole down ist, geht keine DNS-Auflösung mehr. Ein einfacher Uptime-Monitor (UptimeKuma, Healthchecks.io) reicht völlig.

Fazit

Pi-hole ist aus gutem Grund ein Homelab-Klassiker. Seit 2014 hat es sich zum De-facto-Standard für netzwerkweites Adblocking entwickelt - mit über 50.000 GitHub Stars und einer riesigen, aktiven Community.

Was Pi-hole auszeichnet:

  • Ausgereiftes Ökosystem: Tausende Blocklists, unzählige Guides, aktives Forum
  • Stabiles System: Jahrelang erprobt, läuft monatelang ohne Probleme
  • Gravity Sync: Echte Hochverfügbarkeit mit zwei Instanzen
  • Schönes Dashboard: Informativ und übersichtlich
  • Gruppen-Management: Flexibel für verschiedene Client-Typen
  • Unbound-Integration: Maximale Privacy mit rekursivem DNS-Resolver

Für wen ist Pi-hole geeignet?

  • Homelab-Enthusiasten, die das Original wollen
  • User, die Gravity Sync für Redundanz nutzen wollen
  • Alle, die maximale Community-Unterstützung schätzen
  • Diejenigen, die mit Unbound maximale Privacy wollen

Alternativen:

  • AdGuard Home: Modernere UI, verschlüsselte DNS-Protokolle, Wildcard-Rewrites
  • Technitium DNS: Mächtigster Feature-Set, aber komplexer
  • NextDNS: Cloud-basiert, kein Self-Hosting nötig

Kombiniert mit Unbound bietet Pi-hole die privateste DNS-Lösung, die du selbst hosten kannst. Keine Third-Party sieht deine Queries, und du hast volle Kontrolle über deine DNS-Infrastruktur.

Nächste Schritte:

  1. Pi-hole mit Docker deployen
  2. Router-DHCP konfigurieren
  3. Empfohlene Blocklists hinzufügen (OISD, HaGeZi)
  4. Query Log beobachten und False Positives whitelisten
  5. Optional: Unbound für maximale Privacy
  6. Optional: Zweites Pi-hole + Gravity Sync für HA

Pi-hole ist ein Must-Have für jedes Homelab. Setze es einmal auf, und du wirst nie wieder Werbung auf deinen Geräten sehen wollen.

Ressourcen

Offizielle Links:

  • Pi-hole GitHub: https://github.com/pi-hole/pi-hole
  • Dokumentation: https://docs.pi-hole.net/
  • Discourse Forum: https://discourse.pi-hole.net/
  • Reddit Community: https://reddit.com/r/pihole

Blocklists:

  • Firebog: https://firebog.net/ (Kuratierte Liste empfohlener Blocklists)
  • OISD: https://oisd.nl/ (Small & Big Lists)
  • HaGeZi: https://github.com/hagezi/dns-blocklists
  • StevenBlack: https://github.com/StevenBlack/hosts
  • Developer Dan: https://www.github.com/lightswitch05/hosts

Erweiterungen:

  • Gravity Sync: https://github.com/vmstan/gravity-sync
  • Unbound (Docker): https://github.com/MatthewVance/unbound-docker
  • Pi-hole Exporter: https://github.com/eko/pihole-exporter (Prometheus)
  • PADD: https://github.com/pi-hole/PADD (CLI Dashboard)

Tutorials:

  • Pi-hole + Unbound: https://docs.pi-hole.net/guides/dns/unbound/
  • Grafana Dashboard: https://grafana.com/grafana/dashboards/10176
  • Homepage Widget: https://gethomepage.dev/latest/widgets/services/pihole/

Docker Images:

  • Pi-hole Official: https://hub.docker.com/r/pihole/pihole
  • Unbound (mvance): https://hub.docker.com/r/mvance/unbound

Vergleiche:

  • Pi-hole vs AdGuard Home: https://www.reddit.com/r/selfhosted/comments/kqk8jz/pihole_vs_adguard_home/
  • DNS Adblocker Comparison: https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v3/public-resolvers.md
Homelab, Netzwerk
pihole dns ad-blocker privacy docker self-hosted homelab gravity unbound security web-ui
Dieser Eintrag ist vom Autor unter CC BY 4.0 lizensiert.