Skip to main content

🌐 IPv4- und IPv6-Unterstützung

Die Konfiguration pi-hole.conf unterstützt sowohl IPv4 als auch IPv6.
Unbound kann IPv6 bevorzugen (prefer-ip6: yes), verwendet aber auch IPv4, falls nötig.

Einige Optionen sorgen für Sicherheit und Effizienz – z.B. blockiert private-address
interne IP-Bereiche aus Datenschutzgründen.

💡 Hinweis:
Die Option control-enable: yes ist für die Grundinstallation nicht erforderlich.
Sie wird nur für erweiterte Verwaltungsfunktionen benötigt,
die über die normale Nutzung mit Pi-hole hinausgehen.

Wenn du native IPv6-Konnektivität hast, kannst du zusätzlich setzen:

prefer-ip6: yes

💡 Info:
127.0.0.1 und ::1 sind beide Loopback-Adressen (IPv4 bzw. IPv6).
AAAA-Einträge lassen sich auch über IPv4 korrekt auflösen.
Der Client kann Pi-hole weiterhin über IPv6 ansprechen –
intern spielt es keine Rolle, ob die Weiterleitung über IPv4 oder IPv6 erfolgt.

Daher genügt es, in den Pi-hole-DNS-Einstellungen
nur die IPv4-Adresse des Unbound-Servers einzutragen:
127.0.0.1#5335 unter Custom 1 (IPv4).

Ein zusätzliches interface: ::1 ist nicht zwingend notwendig,
solange Pi-hole über 127.0.0.1#5335 kommuniziert.

🧪 IPv6-Test

Die Option do-ip6: yes steuert, ob Unbound DNS-Anfragen über IPv6 sendet oder empfängt.

💡 Hinweis zu IPv6-Tests:
Wenn do-ip6: no gesetzt ist, zeigt die Seite
https://test-ipv6.com meist 9 / 10 Tests als OK.
Mit do-ip6: yes werden alle 10 / 10 Tests erfolgreich abgeschlossen.

Damit ist die Kette vollständig:
Client → Pi-hole → Unbound → Root-Server (IPv4 + IPv6)

📥 Root-Hints herunterladen

Lade die Root-Hints-Datei von der IANA-Website herunter
und speichere sie im Unbound-Konfigurationsverzeichnis:

sudo curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache

💡 Hinweis:
Es existieren zwei Varianten: named.root und named.cache.
Beide enthalten Informationen über die DNS-Root-Server.
named.root stammt direkt von IANA und wird seltener aktualisiert,
während named.cache von ICANN bereitgestellt wird
und häufiger Updates erhält.

Der Download kann später per systemd-Timer automatisiert werden.

🔍 Syntax-Prüfung der Konfiguration

Überprüfe die Konfiguration von Pi-hole / Unbound auf Fehler:

sudo unbound-checkconf /etc/unbound/unbound.conf.d/pi-hole.conf

Erwartete Ausgabe:

unbound-checkconf: no errors in /etc/unbound/unbound.conf.d/pi-hole.conf

🚀 Unbound aktivieren und starten

sudo systemctl enable unbound
sudo systemctl start unbound
# oder neu starten:
sudo systemctl restart unbound

Status prüfen:

sudo systemctl status unbound

🧠 Funktionstest mit dig

Wenn alle Schritte abgeschlossen sind, sollte der Dienst auf Port 5335 aktiv sein.
Teste die DNS-Auflösung:

dig pi-hole.net @127.0.0.1 -p 5335
# oder
dig example.com

💡 Erklärung:
dig steht für Domain Information Groper
(auf Deutsch scherzhaft „Domain-Informations-Grabscher“).
Es zeigt detailliert, wie DNS-Anfragen verarbeitet werden.

Achte auf die Zeile SERVER:

SERVER: 127.0.0.1#53

Das bedeutet, die Anfrage wurde direkt an den lokalen Pi-hole gesendet.
Wenn dort z. B. SERVER: <DEINE-IP>#53 steht, wird die Anfrage über den Router geleitet –
das ist korrekt, wenn die Fritz!Box den Pi-hole als DNS-Server nutzt.

sudo reboot

🔐 DNSSEC-Funktion prüfen

dig fail01.dnssec.works @127.0.0.1 -p 5335
dig dnssec.works @127.0.0.1 -p 5335

💡 Erwartung:

  • Der erste Befehl (fail01) sollte SERVFAIL zurückgeben
    und keine IP-Adresse enthalten.
  • Der zweite (dnssec.works) sollte NOERROR liefern
    plus eine IP-Adresse – das zeigt erfolgreiche DNSSEC-Validierung.

🔧 Test mit drill

drill badsig.go.dnscheck.tools
drill go.dnscheck.tools

💡 Erwartung:

  • badsig... → rcode = SERVFAIL
  • go... → rcode = NOERROR
Back to top