Pi-hole mit unbound - Werbeblocker und Kontrolle über die DNS-Anfragen erhalten
Was macht unbound?
unbound holt für von einem Root-Nameserver die Informationen welcher Top-Level-Domain-Server (TPL) für eine Anfrage zuständig ist. Anschließend wird der zuständige autoritative Nameserver nach der IP-Adresse der Domain gefragt, damit die Seite überhaupt aufgerufen werden kann.
Wo ist aber nun der Unterschied zu dem Pi-hole und zu Pi-hole mit unbound?
Was macht euer Pi-hole ohne unbound?
- Im Webbrowser wird die Adresse strobelstefan.de eingegeben.
- Pi-hole überprüft, ob er die Anfrage bereits aus seinem Cache auflösen kann. Das ist dann der Fall, wenn die Seite bereits einmal zuvor erfolgreich aufgerufen wurde.
- Pi-hole prüft die Adresse strobelstefan.de gegen die Blocking-Listen. Ist der Aufruf der Seite überhaupt erlaubt?
- Pi-hole verweist die Anfrage an einen externen DNS-Server, z.B. des Internet Service Providers (ISP) oder des eingestellten DNS-Servers, in der Pi-hole-Konfiguration (
Einstellungen --> DNS). - Die Anfrage kommt vom externen DNS zurück und der Pi-hole gibt die Informationen an den Webbrowser weiter.
- Die Seite wird aufgerufen.
- Pi-hole speichert die Anfrage in seinem Cache für später.
Was macht euer Pi-hole mit unbound?
Die Anfrage läuft für die Punkte 1 bis 3 gleich ab. Erst ab Punkt 4 gibt es eine Änderung
- Im Webbrowser wird die Adresse strobelstefan.de eingegeben.
- Pi-hole überprüft, ob er die Anfrage bereits aus seinem Cache auflösen kann. Das ist dann der Fall, wenn die Seite bereits einmal zuvor erfolgreich aufgerufen wurde.
- Pi-hole prüft die Adresse strobelstefan.de gegen die Blocking-Listen. Ist der Aufruf der Seite überhaupt erlaubt?
- Es wird eine Anfrage von Pi-hole an den Root-Nameserver gesendet. Dort wird angefragt, welche Top-Level-Domain (TLD) für .de zuständig ist.
- Pi-hole sendet dann eine Anfrage an den zuständigen Server der TLD und fragt, wo er strobelstefan.de findet.
- Der TLD Server sendet die Informationen über den zuständigen autoritativen Nameserver zurück.
- Pi-hole wendet sich an den autoritativen Nameserver und fragt nach strobelstefan.de.. Der autoritativen Nameserver kennt die korrekte IP-Adresse von strobelstefan.de und stellt diese Information dem Pi-hole zur Verfügung.
- Der autoritativen Nameserver antwortet nun mit der IP-Adresse der Domain strobelstefan.de.
- Der Pi-hole gibt die Informationen an den Webbrowser weiter und die Seite kann aufgerufen werden.
- Pi-hole speichert die Informationen im Cache. Wird die Seite erneut aufgerufen, wird die Anfrage direkt aus dem Cache beantwortet.
Was ist nun der Unterschied?
Der wesentliche Unterschied zwischen den beiden Abläufen, mit unbound fragt der Pi-hole nicht bei irgendeinem externen DNS-Server an.
Die Anfragen werden zielgerichtet an den Root-Nameserver, dann an den TLS und dann an den autoritativen Nameserver versendet.
Es gibt also keine Dritten die euer Surfverhalten aufgrund der abgesendeten DNS-Anfragen nachvollziehen können.
Wenn euer Pi-hole / unbound die Informationen bereits im Cache gespeichert hat, findet er die richtigen Webserver und damit die Adresse strobelstefan.de direkt.
Wenn ihr mal euren Query Log auf dem Pi-hole angeschaut habt, dann wisst ihr was die DNS-Anfragen beinhalten und was für Informationen und Schlüsse man daraus ziehen kann.
Ein installierter unbound in Verbindung mit Pi-hole.
- hilft bei der digitalen Selbstverteidigung
- blockt zuverlässig Werbung
- ermöglicht eine schnelleres Surfen im Internet, wenn die Daten bereits im Cache gespeichert sind.
unbound-Installation
Die Installation von unbound funktioniert sehr einfach aus den Repositories
sudo apt install unbound
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libunbound8 unbound-anchor
Suggested packages:
apparmor
The following NEW packages will be installed:
libunbound8 unbound unbound-anchor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 1219 kB of archives.
After this operation, 4787 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Nach der erfolgreichen Installation ist eine neue Datei im entsprechenden Verzeichnis anzulegen.
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
Der Inhalt der Datei wird aus der offiziellen Dokumentation übernommen https://docs.pi-hole.net/guides/dns/unbound/#configure-unbound .
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
OPTIONAL
Wird unbound aus den Paketquellen installiert, wird die root.hints mitgeliefert. Es sollte nicht erforderlich sein diese im Verzeichnis /var/lib/unbound manuelle anzulegen.
Manuell kann die Datei geholt werden mit dem folgenden Befehl.1
sudo mkdir /var/lib/unbound/
sudo touch /var/lib/unbound/root.hints
wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints
Danach ist der Dienst neu zu starten
benutzer@pihole:~ $ sudo service unbound restart
Ein Test kann durchgeführt werden.2
➜ dig fail01.dnssec.works @127.0.0.1 -p 5335
; <<>> DiG 9.16.50-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58914
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works. IN A
;; Query time: 1340 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Dec 16 19:00:20 CET 2025
;; MSG SIZE rcvd: 48
➜ dig fail01.dnssec.works @127.0.0.1 -p 5335
; <<>> DiG 9.16.50-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45761
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works. IN A
;; ANSWER SECTION:
fail01.dnssec.works. 2269 IN A 5.45.109.212
;; Query time: 10 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Dec 16 19:22:30 CET 2025
;; MSG SIZE rcvd: 64
Pi-hole konfigurieren
In Pi-hole ist lediglich ein neuer DNS-Server einzutragen.
Pi-hole Konfiguration
resolvconf.conf deaktivieren
Verwendet man Debian Bullseye auf seinem Raspberry Pi ist entsprechend der Anleitung der Dienst unbound-resolvconf.service zu deaktivieren.3
Die Abfrage des Betriebssystems erfolgt mit dem Befehl:
cat /etc/os-release
Der Status des Dienstes unbound-resolvconf.service wird mit abgefragt:
sudo systemctl is-active unbound-resolvconf.service
inactive
In diesem Beispiel ist er bereits inactive.
Logging zu unbound umstellen
Dieser Schritt ist erforderlich, dass der Query Log von Pi-hole in der Weboberfläche ausgelesen und dargestellt werden kann. Dafür wird in der Konfigurationsdatei eine neue Logdatei /var/log/unbound/unbound.log konfiguriert und anschließend werden die Zugriffsrechte vergeben.
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
Im Abschnitt server: sind die Zeilen 3 und 4 zu ergänzen.
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
log-time-ascii: yes
verbosity: 1
Die Datei unbound.log ist anzulegen und die Zugriffsrechte sind zu setzen:
sudo mkdir -p /var/log/unbound
sudo touch /var/log/unbound/unbound.log
sudo chown unbound /var/log/unbound/unbound.log
Zum Abschluss ist unbound neu zu starten:
sudo service unbound restart
Firewall
Läuft auf dem Raspberry Pi eine Firewall, wie ufw, ist unbedingt der Pot 5335 zu öffnen.
sudo ufw allow 5335/tcp
sudo ufw allow 5335/udp
Nachdem die beiden Regeln hinzugefügt wurden, ist die Konfiguration neu einzulesen.
sudo ufw reload
sudo ufw status
Status: active
To Action From
-- ------ ----
...
5335/tcp ALLOW Anywhere
5335/udp ALLOW Anywhere
unbound Fehlermeldungen
sudo systemctl restart unbound
Job for unbound.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status unbound.service" and "journalctl -xe" for details.
Es gibt einige Beschreibungen, um den Fehler zu lösen. Es hat keine funktioniert. Um unbound zum Laufen zu bekommen, wurden die folgenden Schritte durchlaufen:
sudo apt remove unboundsudo rm -r /etc/unboundsudo rebootsudo apt install unboundsudo nano /etc/unbound/unbound.conf.d/pi-hole.conf- Den Inhalt von der offiziellen Anleitung in die
pi-hole.confkopieren 👉 https://docs.pi-hole.net/guides/dns/unbound/#configure-unbound . sudo service unbound restart
Gib mir gerne einen Kaffee ☕ aus 😀
Gib mir gerne einen Kaffee ☕ aus !
Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕️ ausgeben.
• 
Bitcoin Address:
bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj
Weitere Möglichkeiten mich zu unterstützen findest du 👉 hier
Follow Me