Pi-hole mit Unbound auf Pi 4 mit Manjaro

[Jo]

Stand: 2024-02-03

Vorbemerkung: Ursprünglich betrieb ich Pi-hole 5.x unter Manjaro-arm mit Nginx, jedoch traten zahlreiche PHP-Fehler und Warnungen auf, insbesondere unter PHP 8.2. Seltsamerweise traten sogar Apache2-Warnungen auf, obwohl dieser nicht genutzt wurde! Aufgrund dieser Probleme habe ich mich entschieden, zu Lighttpd zurückzukehren, um Pi-hole zu betreiben. Es scheint, dass die Integration von Pi-hole mit Lighttpd besser funktioniert.

Gleiche Warnung wie mein Thread ioBroker mit Pi 4 und Manjaro : Ich möchte betonen, dass Debian als LTS ein äußerst solides und stabiles System ist. Bitte nehmt meinen Thread daher nicht falsch auf. Manjaro-ARM ist ebenfalls ein sehr solides und stabiles System, jedoch muss dieses in der Regel nur einmal installiert werden. Es ist wichtig zu beachten, dass Pi-hole Manjaro nicht unterstützt. Wenn dies ein Problem darstellt, sollte man auf jeden Fall bei Debian bleiben.

Abgesehen von Unbound war die Installation relativ einfach. Wer Pi-hole in Kombination mit Unbound nutzen möchte, sollte dafür allerdings etwas mehr Zeit einplanen. Möglicherweise findet ihr nützliche Unterstützung und Anleitungen in diesem Blog, die euch bei der Einrichtung helfen können.

Pi-hole ist eine freie Open Source Software, die als DNS-basierter Tracking- und Werbeblocker für das gesamte Heimnetzwerk fungiert. Es lädt unerwünschte Inhalte wie Werbebanner, bösartige Webseiten oder Telemetriedaten von IoT-Geräten und Smart TVs nicht, da es diese schon auf DNS-Ebene blockiert. Im Gegensatz zu herkömmlichen Blockern, die auf spezifische Programme oder Geräte beschränkt sind, wirkt Pi-hole netzwerkweit.

Die Einrichtung und Anpassung von Pi-hole auf einem Raspberry Pi und in einer FritzBox sowie die Konfiguration von Whitelist oder Blacklist, auch mit regulären Ausdrücken, sind einfach. Pi-hole funktioniert als DNS-Server, kann jedoch keine Werbung oder Cookie-Meldungen von der gleichen Domain blockieren, wofür weiterhin uBlock verwendet werden kann.

Mit der Kombination aus Pi-hole und Unbound, einem alternativen DNS-Resolver mit DNSSEC, wird das Netzwerk sicherer und schneller.
Unbound ist ein validierender, rekursiver und zwischenspeichernder DNS-Resolver. Er sendet Anfragen direkt an die Root-DNS-Server, was anfänglich etwas langsamer sein kann, aber durch den Cache werden nachfolgende Anfragen schneller beantwortet. Diese Methode verbessert die Sicherheit, da Anfragen von außen nicht einfach mitgelesen werden können. Unbound übernimmt außerdem die DNSSEC-Funktion, sodass eine separate Aktivierung in Pi-hole nicht erforderlich ist. Die QNAME-Minimierung sorgt zusätzlich dafür, dass DNS-Abfragen nur die für den jeweiligen Schritt des Auflösungsprozesses notwendigen Details enthalten, also nur die TLD, die Domain oder die Subdomain.

Im Gegensatz zu einem rekursiven Unbound-Server erhält ein Forwarder wie Google, Cloudflare oder Quad9 stets die komplette DNS-Anfrage. Daher halte ich die QNAME-Minimierung für eine wichtige zusätzliche Funktion, um besseren Datenschutz zu gewährleisten. Nur die Root-DNS-Server erhalten tatsächlich die komplette DNS-Anfrage, wenn diese an sie gerichtet wird. Die Root-DNS-Server sind die oberste Stufe im DNS-Hierarchiebaum und bestehen aus 13 Hauptservern, die durch Buchstaben von A bis M bezeichnet werden (siehe unten Überprüfe die Root Hints).

Wer bereits Erfahrungen mit einer solchen Umsetzung hat oder ebenfalls Interesse an diesem Vorhaben zeigt, ist herzlich eingeladen, sich hier zu melden und seine Gedanken oder Tipps zu teilen. Ich freue mich auf einen regen Austausch via Matrix: #RPI-Manjaro-arm:tchncs.de



INHALT

• Pi-hole auf Manjaro ARM installieren
• Optimierung für SSD-Laufwerke und Anpassung der EDNS-Paketgröße
• Unbound installieren und testen
• FritzBox mit Pi-Hole
• IPv4/IPv6-Adressen statisch zuweisen
• Automatisierung der Aktualisierung von root.hints
• Aktualisieren, Überprüfen und Diagnose

Versuchsaufbau: Raspberry Pi 4, der mit Manjaro-ARM (headless) installiert ist und zusätzlich Pi-hole mit Unbound, sowie ioBroker mit einem Z-Wave-Modul betreibt, angeschlossen an einer 12-Volt USV.


Die angezeigte Auslastung und Temperatur entsprechen einem normalen Betrieb mit ioBroker und Pi-Hole. Beachte, dass ich die Netzwerktabelle zurückgesetzt habe. Der Raspberry Pi 4 ist mit einem groß dimensionierten passiven Kühlkörper ausgestattet.


Hier ist eine mögliche Methode zur Umsetzung. Ich verwende eine FritzBox als Router, falls du einen anderen Router verwendest, musst du diese Einstellungen entsprechend anpassen. Ich gehe davon aus, dass Manjaro ARM installiert ist und du die IP-Adresse deines Pi 4 mit Manjaro-arm kennst, und dich per SSH verbindest, z.B.:

Code Auswählen Erweitern

ssh pi4m@192.168.1.42
Aktualisiere deine Paketlisten und installiere die erforderliche Pakete:

Code Auswählen Erweitern

sudo pacman -Syu
sudo pacman -Sy --needed yay base-devel git php-fpm php-sqlite inetutils curl lighttpd php-cgi gnu-netcat xxd-standalone unbound(für netcat wähle ich "gnu-netcat" und für xxd "xxd-standalone")

Kontrolliere die installierte PHP-Version:

Code Auswählen Erweitern

php -v(zu dem Zeitpunkt war das PHP 8.2.12)

PHP-Leseberechtigungen festlegen. Bei der Verwendung von PHP v7.0 oder neuer ist die PHP-Direktive open_basedir standardmäßig leer. Das bedeutet, dass PHP auf alle Verzeichnisse und Dateien zugreifen kann, die von der Benutzerkennung des Webservers gelesen werden können. Aus Gründen der Sicherheit wird die open_basedir-Direktive absichtlich für die administrative Pi-hole-Weboberfläche gesetzt.

Code Auswählen Erweitern

sudo nano /etc/php/php.ini

open_basedir = /srv/http/pihole:/run/pihole-ftl/pihole-FTL.port:/run/log/pihole/pihole.log:/run/log/pihole-ftl/pihole-FTL.log:/etc/pihole:/etc/hosts:/etc/hostname:/etc/dnsmasq.d/02-pihole-dhcp.conf:/etc/dnsmasq.d/03-pihole-wildcard.conf:/etc/dnsmasq.d/04-pihole-static-dhcp.conf:/var/log/lighttpd/error-pihole.log:/proc/loadavg:/proc/meminfo:/proc/cpuinfo:/sys/class/thermal/thermal_zone0/temp:/tmp

Code Auswählen Erweitern

yay -S pi-hole-serverDer AUR-Helfer-Prompt (ohne sudo!) zeigt dann Optionen zum installieren an, hier wähle ich [A]lle. Dadurch werden sowohl die expliziten AUR-Pakete (wie pi-hole-server und pi-hole-ftl) als auch alle notwendigen Abhängigkeiten (sowohl aus dem AUR als auch aus den offiziellen Repositories) installiert.
Die Wahl von "I" ist nur dann sinnvoll, wenn du sicher bist, dass alle benötigten Pakete bereits auf deinem System installiert sind und keine neuen Installationen oder Updates erforderlich sind. Im nächsten Schritt wird gefragt, ob du die Unterschiede (Diffs) zwischen den aktuellen Build-Dateien und den neuen Versionen der Pakete, die du installieren möchtest, anzeigen lassen möchtest, hier wähle ich [N] Keine.

Lege das Administrator-Passwort für die Pi-hole-Webinterface fest:

Code Auswählen Erweitern

pihole -a -p(du kannst das auch leer lassen)

Erforderliche PHP-Erweiterungen aktivieren:

Code Auswählen Erweitern

sudo nano /etc/php/php.iniPrüfe und aktiviere diese Einstellungen:

extension=curl
extension=pdo_sqlite
extension=sockets
extension=sqlite3

Kopieren die im Paket enthaltene Standardkonfiguration für Pi-hole:

Code Auswählen Erweitern

sudo cp /usr/share/pihole/configs/lighttpd.example.conf /etc/lighttpd/lighttpd.conf
Aktiviere den lighttpd.service und starte es:

Code Auswählen Erweitern

sudo systemctl enable lighttpd.service
sudo systemctl start lighttpd.serviceStelle sicher, dass Lighttpd auf deinem Raspberry Pi läuft. Du kannst dies mit dem folgenden Befehl überprüfen:

Code Auswählen Erweitern

sudo systemctl status lighttpd
Richte die System-Hosts-Datei korrekt ein:

Code Auswählen Erweitern

sudo nano /etc/hosts

127.0.0.1    localhost
192.168.1.42    pi.hole manjaro-arm
192.168.1.1    fritz.box

Ersetze 192.168.1.42 mit der IP-Adresse deines Pi-hole-Servers und manjaro-arm mit dem tatsächlichen Hostnamen dieses Servers. Diese Einstellung sorgt dafür, dass Anfragen an "pi.hole" und "manjaro-arm" korrekt an deinen Pi-hole-Server weitergeleitet werden.

Wenn du in deinen Netzwerk-Logs "_gateway" als Client siehst, ist das normal und zeigt an, dass dein Netzwerk wie erwartet funktioniert. Dies kannst du im Terminal mit dem Befehl route überprüfen. Um stattdessen den Namen deines Routers anzuzeigen, füge die tatsächliche IP-Adresse deines Routers, zum Beispiel 192.168.1.1, zusammen mit dem gewünschten Hostnamen, wie "fritz.box", hinzu (Zeile 3).

Netzwerk neu starten:

Code Auswählen Erweitern

sudo systemctl restart systemd-networkDNS-Resolver von Pi-hole neu starten:

Code Auswählen Erweitern

pihole restartdns
Aktualisiere die Blockierliste von Pi-hole:

Code Auswählen Erweitern

pihole -g
Das Pi-hole Webinterface sollte nun erreichbar sein: http://192.168.1.42/admin/login.php

Die Nutzung der Standard Pi-hole Sperrliste (Adlists) "StevenBlack/hosts" ist in der Regel ausreichend:

Code Auswählen Erweitern

https://raw.githubusercontent.com/StevenBlack/hosts/master/hostsund evtl. eine Sperrliste die Malware verbreiten:

Code Auswählen Erweitern

https://urlhaus.abuse.ch/downloads/hostfile
Während es möglich ist, weitere Sperrlisten hinzuzufügen, bevorzuge ich die Verwendung einer eigenen Blacklist mit regulären Ausdrücken, um potenzielle Probleme zu vermeiden. Für Nutzer, die beispielsweise eine YT-History benötigen oder die obersten gesponserten Links in einer bekannten Suchmaschinen verwenden möchten, bietet sich die Erstellung einer Whitelist an. Eine solche Whitelist und Blacklist, auch mit regulären Ausdrücken, könnte dann folgendermaßen aussehen (Domains):

• EU Cookie Meldung (blacklist): (^|\.)usercentrics\.eu$
• google-Tracking (whitelist): (\.|^)googleadservices\.com$
• Adobe trackingServer (blacklist):  (^|\.)omtrdc\.net$
• youtube video history (whitelist): s.youtube.com
• Domains der TLD .zip (blacklist): \.zip$
• Apple icloud (whitelist): (\.|^)icloud\.com$
• need for add card in wallet app (whitelist): supportmetrics.apple.com
• Brave Server, um Nutzern Feldversuche für neue Funktionen zu liefern (blacklist): variations.brave.com

Optimierung für SSD-Laufwerke

Code Auswählen Erweitern

sudo nano /etc/pihole/pihole-FTL.conf

### This file contains parameters for FTL behavior.
### At install, all parameters are commented out. The user can select desired options.
### Options shown are the default configuration. No modification is needed for most
### installations.
### Visit https://docs.pi-hole.net/ftldns/configfile/ for more detailed parameter explanations

## Max Database Days
## How long should queries be stored in the database -days-?
## Setting this to 0 disables the database
## See: https://docs.pi-hole.net/ftldns/database/
## Options: number of days
MAXDBDAYS=90

## Database Interval
## How often do we store queries in FTL's database -minutes-?
## See: https://docs.pi-hole.net/ftldns/database/
## Options: number of minutes
DBINTERVAL=60.0

## Privacy Level
## Which privacy level is used?
## See: https://docs.pi-hole.net/ftldns/privacylevels/
## Options: 0, 1, 2, 3
PRIVACYLEVEL=0

# This setting limits the number of requests that Pi-hole accepts from a single IP address per minute
RATE_LIMIT=2000/60

Wenn gewünscht kann die Abfrageprotokollierung mit "PRIVACYLEVEL=3" deaktiviert werden. Die Einstellung RATE_LIMIT=2000/60 in der pihole-FTL.conf begrenzt die Anzahl der Anfragen, die Pi-hole von einer einzelnen IP-Adresse akzeptiert, auf maximal 2000 Anfragen pro Minute.

Pi-hole-FTL neu starten:

Code Auswählen Erweitern

sudo systemctl restart pihole-FTL.service
Verbesserung der DNS-Stabilität durch Anpassung der EDNS-Paketgröße und die maximale Anzahl gleichzeitiger DNS-Anfragen in Pi-hole
Überprüfe, ob das Verzeichnis '/etc/dnsmasq.d' existiert, indem du 'ls /etc/dnsmasq.d' eingibst. Falls das Verzeichnis nicht vorhanden ist, erstelle es mit 'sudo mkdir /etc/dnsmasq.d'. In meinem Fall war dies jedoch nicht erforderlich, da das Verzeichnis bereits existierte.

Erstelle eine neue Konfigurationsdatei (Quelle):

Code Auswählen Erweitern

sudo nano /etc/dnsmasq.d/99-edns.confFüge die folgende Zeile in die Datei ein:

edns-packet-max=1232
dns-forward-max=300

Der Wert für "dns-forward-max" sollte an die Bedürfnisse und die Kapazitäten deines Netzwerks angepasst werden. Ein Wert von mehr als 300 könnte in manchen Fällen übertrieben hoch sein, aber es hängt von der Größe und dem Nutzungsverhalten deines Netzwerks ab. Wenn dein Netzwerk viele gleichzeitige DNS-Anfragen verarbeiten muss, könnte ein höherer Wert sinnvoll sein, um solche Warnungen zu vermeiden: Maximum number of concurrent DNS queries reached (max: 300)

Um dies zu verdeutlichen: Wenn der Wert "max: 300" erreicht wird, bedeutet das, dass der Server zu diesem Zeitpunkt 300 DNS-Anfragen gleichzeitig in Bearbeitung hat. Dies kann passieren, wenn viele Geräte im Netzwerk gleichzeitig DNS-Anfragen stellen, wodurch das Limit erreicht wird. Es ist definitiv ratsam, dies weiter zu untersuchen. Analysiere das Query Log und überprüfe die Top Clients im Pi-hole Admin Interface. Die Nutzung vieler IoT-Geräte (WiFi) könnte eine Erklärung für die hohe Anzahl gleichzeitiger Anfragen sein.

Oder wie in meinem Fall: Der DSL-Router wurde getrennt und musste sich neu verbinden (Synchronisierung), siehe Router Log-Eintrag, z.B.: "DSL antwortet nicht (keine DSL-Synchronisierung)". Wenn der Router getrennt ist, kann Pi-hole diese Anfragen nicht weiterleiten und es kommt zu einem Rückstau an Anfragen, was dazu führen kann, dass das Limit von 300 gleichzeitigen Anfragen erreicht wird.

DNS-Dienst neu starten:

Code Auswählen Erweitern

pihole restartdns
Für die Zeitserver-Synchronisation verwende ich NTP und stelle den Zeitserver auf den meiner FritzBox ein. Hier ist ein Beispiel, wie du dies in deiner Konfiguration vornehmen kannst. Öffne die Konfigurationsdatei mit dem Befehl:

Code Auswählen Erweitern

sudo nano /etc/systemd/timesyncd.confSetze den NTP-Server auf die IP-Adresse deiner FritzBox. Zum Beispiel: NTP=192.168.1.1
Ich habe bereits diese Anpassung in meiner ioBroker-Installation vorgenommen, die auf demselben Raspberry Pi läuft.

Ebenso habe ich meine /etc/fstab für die SSD angepasst, siehe ioBroker mit Pi 4 und Manjaro.



Bevor du Unbound einrichtest, überprüfe, ob alles funktioniert, indem du in den Einstellungen -> DNS zum Beispiel die Checkboxen 'Quad9 (gefiltert, DNSSEC)' als Upstream DNS Server und 'Use DNSSEC' aktivierst. Beachte jedoch: Sobald du Unbound aktiviert hast, solltest du DNSSEC in den Pi-Hole-Einstellungen deaktivieren, da es in den Unbound-Einstellungen aktiviert wird.

Unbound kann wie folgt installiert werden, sobald Pi-hole einwandfrei funktioniert:

Code Auswählen Erweitern

sudo pacman -Sy --needed unbound
Lege ein Unbound Log-Verzeichniss an und setze die korrekten Berechtigungen:

Code Auswählen Erweitern

sudo mkdir -p /var/log/unbound/
sudo chown -R unbound:unbound /var/log/unbound/
Es wird empfohlen, die Hauptkonfigurationsdatei von Unbound nicht direkt zu bearbeiten. Stattdessen solltest du eine separate Konfigurationsdatei, beispielsweise pi-hole.conf, im Verzeichnis /etc/unbound/unbound.conf.d/ anlegen, um dort deine spezifischen Einstellungen vorzunehmen. Dies bietet auch den Vorteil, dass mehrere Konfigurationsdateien in diesem Verzeichnis erstellt werden können. Falls das Verzeichnis unbound.conf.d noch nicht existiert, erstelle es mit dem erforderlichen Befehl:

Code Auswählen Erweitern

sudo mkdir -p /etc/unbound/unbound.conf.d/
Erstelle eine neue Unbound-Konfigurationdatei:

Code Auswählen Erweitern

sudo nano /etc/unbound/unbound.conf.d/pi-hole.confFüge diese Daten ein und passe evtl. die "forward-zone" an:

server:
    # If no logfile is specified, syslog is used
    # (e.g.: 'journalctl -u unbound' or 'journalctl -u unbound -p err')
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    directory: "/etc/unbound"
    username: unbound  # root ->only for testing!

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you 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: yes

    # 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: "/etc/unbound/root.hints"

    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor
    auto-trust-anchor-file: "/etc/unbound/trusted-key.key"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Additional safety measures
    hide-identity: yes
    hide-version: yes
    qname-minimisation: 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>
    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

    # ADD
    # maximum number of simultaneous DNS requests (default: 150)
    num-queries-per-thread: 300
    #
    # "forward-zone" directs specific domain queries to designated upstream DNS servers
    # Adjust your IP addresses!
    forward-zone:
      name: "fritz.box"
      forward-addr: 192.168.1.1@53

Nach dem Speichern sollten die Berechtigungen angepasst werden (optional, aber empfohlen):

Code Auswählen Erweitern

sudo chmod 644 /etc/unbound/unbound.conf.d/pi-hole.conf
Dieser Befehl lädt und aktualisiert die Root-Trust-Anchors für DNSSEC, die Unbound zur Validierung der Authentizität von DNS-Antworten benötigt, und speichert sie in der angegebenen Datei:

Code Auswählen Erweitern

sudo unbound-anchor -a /etc/unbound/trusted-key.keyTesten:

Code Auswählen Erweitern

sudo unbound-anchor -vErgebnis:

/etc/trusted-key.key has content
success: the anchor is ok

WICHTIG: Berechtigungen für den Ordner sowie alle Dateien und Unterverzeichnisse (rekursiv) für den Unbound-Benutzer festlegen:

Code Auswählen Erweitern

sudo chown -R unbound:unbound /etc/unbound
Öffne die Unbound-Hauptkonfigurationsdatei:

Code Auswählen Erweitern

sudo nano /etc/unbound/unbound.confErsetze den Inhalt der Hauptkonfigurationsdatei von Unbound mit den folgenden Zeilen, um sicherzustellen, dass alle zusätzlichen Konfigurationsdateien aus dem Verzeichnis "/etc/unbound/unbound.conf.d/" automatisch eingebunden werden:

# Unbound configuration file
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

Die Konfiguration pi-hole.conf unterstützt sowohl IPv4 als auch IPv6. Unbound wird IPv6 bevorzugen (prefer-ip6: yes), aber auch IPv4 verwenden, falls notwendig. Einige der anderen Optionen in der Konfigurationsdatei stellen sicher, dass Unbound sicher und effizient arbeitet. Zum Beispiel werden private Adressbereiche aus Datenschutzgründen blockiert. Die Option 'control-enable: yes' in der Unbound-Konfiguration, wie im unten angegebenen Link zur Unbound-Dokumentation näher erläutert, ist für die grundlegende Einrichtung von Unbound als rekursiven DNS-Server in Verbindung mit Pi-hole nicht notwendig. Sie ist vielmehr für erweiterte Verwaltungsaufgaben gedacht, die über die typischen Anforderungen einer Pi-hole-Installation hinausgehen.

Gut zu wissen: 127.0.0.1 ist derselbe Localhost wie ::1. AAAA-Datensätze funktionieren über IPv4 genauso gut wie über IPv6. Der Client kann Pi-hole nach wie vor über IPv6 befragen. Ob Pi-hole die Anfrage über IPv4 oder IPv6 weiterleitet, ist unerheblich und ein "interface: ::1" nicht notwendig.

Daher wird nur die IPv4-Adresse mit Port des Unbound-DNS-Servers (127.0.0.1#5335) in das Feld "Custom 1 (IPv4)" in den Einstellungen von Pi-hole eingetragen.

"do-ip6: yes" in unbound's Konfiguration steuert, ob unbound IPv6 für das Stellen von DNS- Anfragen an seine Upstream-Servern verwenden soll, und ob unbound über IPv6 eingehende DNS-Anfragen beantwortet.

Verwende den Befehl curl, um die Root-Hints-Datei von der IANA-Website herunterzuladen und in das Unbound-Konfigurationsverzeichnis zu speichern:

Code Auswählen Erweitern

sudo curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache
Es gibt zwei Dateien, named.root und named.cache, die Informationen über die Stamm-DNS-Server bereitstellen, wobei named.root direkt von IANA stammt und weniger häufig aktualisiert wird, während named.cache von ICANN bereitgestellt wird und häufiger aktualisiert werden kann.
Am Ende beschreibe ich, wie du den Download mithilfe von systemd und einem Timer automatisieren kannst.

Überprüfe die spezifische Pi-hole-Konfiguration auf Syntaxfehler:

Code Auswählen Erweitern

sudo unbound-checkconf /etc/unbound/unbound.conf.d/pi-hole.confDas Ergebnis sollte "no errors in /etc/unbound/unbound.conf.d/pi-hole.conf" sein.

Unbound aktivieren und starten:

Code Auswählen Erweitern

sudo systemctl enable unbound
sudo systemctl start unboundUnbound Status prüfen:

Code Auswählen Erweitern

sudo systemctl status unbound
Nachdem du diese Schritte ausgeführt hast, sollte der Unbound-Dienst auf Port 5335 verfügbar sein, und du kannst versuchen, die DNS-Auflösung zu testen:

Code Auswählen Erweitern

dig pi-hole.net @127.0.0.1 -p 5335Mit "dig" kannst du verschiedene Arten von DNS-Abfragen durchführen, um Informationen über DNS-Einträge zu erhalten und die Funktionsweise von DNS-Servern zu testen. "dig" steht für "Domain Information Groper", auf spaßige Weise auch "Domain Information Grabscher" genannt.

Überprüfe ob DNSSEC funktioniert:

Code Auswählen Erweitern

dig fail01.dnssec.works @127.0.0.1 -p 5335
dig dnssec.works @127.0.0.1 -p 5335Der erste Befehl sollte einen Statusbericht von SERVFAIL und keine IP-Adresse liefern. Der zweite sollte NOERROR plus eine IP-Adresse liefern.

Außerdem könnt Ihr den Resolver mit Drill wie folgt testen:

Code Auswählen Erweitern

drill badsig.go.dnscheck.tools
drill go.dnscheck.toolsDer erste Befehl sollte einen rcode von SERVFAIL liefern. Der zweite Befehl sollte einen rcode von NOERROR liefern.

Obwohl DANE (DNS-based Authentication of Named Entities) eine wertvolle Sicherheitstechnologie darstellt, ist sie derzeit nicht so weit verbreitet oder unterstützt wie andere Sicherheitsmechanismen. So testest du DNSSEC-Validierung für eine bestimmte Domain:

Code Auswählen Erweitern

dig @127.0.0.1 -p 5335 +dnssec +cd internet.nlHierbei fordert +dnssec die Authentifizierung von DNS-Daten unter Verwendung von DNSSEC an. +cd (Checking Disabled) deaktiviert die DNSSEC-Validierung und gibt jede Antwort zurück, auch wenn sie nicht authentifiziert wurde. Das erwartete Ergebnis ist eine DNS-Antwort, die zeigt, dass die Domain internet.nl erfolgreich mit DNSSEC signiert wurde. Achte besonders auf den "ad" (Authenticated Data) Flag in den Flags der Antwort:

...
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...

Ich habe einen Test auf meinem Hauptrechner durchgeführt, um die DNSSEC-Konfiguration des Mail-Providers Posteo.de zu überprüfen. Hierfür habe ich den folgenden Befehl verwendet:

Code Auswählen Erweitern

dig posteo.de SOA +dnssecDieser Befehl fragt den SOA (Start of Authority)-Eintrag für posteo.de ab und fordert DNSSEC-Informationen an. Die Ausgabe des Befehls zeigt folgende wichtige Informationen:

Code Auswählen Erweitern

...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...Das Vorhandensein des "ad"-Flags in der Antwort zeigt an, dass die DNS-Antwort für die SOA-Abfrage von posteo.de von DNSSEC validiert wurde und als sicher und authentisch gilt. Dies ist ein gutes Zeichen dafür, dass die Domain korrekt mit DNSSEC konfiguriert ist.

Um TLS-Verbindungen (HTTPS) zu verifizieren, nutze das Tool ldns:

Code Auswählen Erweitern

ldns-dane -d verify posteo.de 443Das Ergebnis zeigt, ob die TLS-Verbindung zu posteo.de über Port 443 erfolgreich mit DANE validiert wurde:

185.67.36.168 dane-validated successfully
185.67.36.169 dane-validated successfully
2a05:bc0:1000::168:1 dane-validated successfully
2a05:bc0:1000::169:1 dane-validated successfully
2a05:bc0:1000:80::168:1 dane-validated successfully
2a05:bc0:1000:80::169:1 dane-validated successfully

Zusätzlich bietet die Webseite internet.nl eine einfache Möglichkeit, eine 'Domain signature validation' (DNSSEC) für eine beliebige Domain zu testen.

Fazit: Obwohl DANE eine zusätzliche Sicherheitsebene bieten kann, indem es TLS-Zertifikate direkt im DNS validiert, bleibt es eine weniger genutzte Technologie im Vergleich zu etablierten PKI-basierten Ansätzen. Dennoch ist es ein wichtiges Werkzeug im Arsenal zur Verbesserung der Internet-Sicherheit, insbesondere in Bereichen, wo ein hohes Maß an Kontrolle und Authentizität erforderlich ist.

Schließlich konfigurierst du Pi-hole so, dass es deinen rekursiven DNS-Server verwendet, indem du 127.0.0.1#5335 als Custom DNS (IPv4) angibst und alle anderen Upstream DNS Server deaktivierst.

Im Tab "DNS" der Pi-hole-Einstellungen aktiviere alle Kontrollkästchen außer DNSSEC:

• Never forward non-FQDN A and AAAA queries -> an
• Never forward reverse lookups for private IP ranges -> an
• Use DNSSEC -> aus, Unbound übernimmt die DNSSEC-Funktion!
• Verwende "Use Conditional Forwarding" nur, wenn Unbound nicht verwendet wird (siehe pi-hole.conf), z.B.:

• Local network in CIDR notation: 192.168.1.0/24
• IP address of your DHCP server (router): 192.168.1.1
• Local domain name (optional): fritz.box

Überprüfe ob die Namensauflösung für "fritz.box" korrekt funktioniert:

Code Auswählen Erweitern

ping fritz.box


FritzBox mit Pi-Hole

Dieser Befehl auf deinem Manjaro-arm zeigt die IP-Adressen aller Netzwerkschnittstellen auf deinem System an:

Code Auswählen Erweitern

ip addr show | grep inet | awk '{print $2}'Dieser Befehl zeigt nur die IP-Adresse der spezifischen Netzwerkschnittstelle "end0" von manjaro-arm an (kann auch in der FritzBox geprüft werden):

Code Auswählen Erweitern

ip addr show dev end0 | grep inet | awk '{print $2}'Es scheint, dass die Bezeichnung "end0" anstatt "eth0" unter Manjaro-ARM für die Netzwerkschnittstelle verwendet wird. Dieser Befehl listet alle Netzwerkschnittstellen auf und zeigt ihre aktuellen Bezeichnungen an:

Code Auswählen Erweitern

ip link show
Teste die IPv4- und IPv6-ULA-Adresse, indem du von einem anderen Rechner im selben Netzwerk aus einen Ping durchführst, z.B. so:

Code Auswählen Erweitern

ping 192.168.1.42
ping -6 fd00::1111:5555:9cba:def1
Diese IPs trage ich in der FritzBox ein "Internet ->Zugangsdaten -> DNS-Server":
DNSv4-Server: 192.168.1.42
DNSv6-Server: fd00::1111:5555:9cba:def1
Bei DNS-Störungen auf öffentliche DNS-Server zurückgreifen: An



Vorteil: Funktioniert mit VPN Clients und Clients im Gastnetz und als Fallback. Kleiner Nachteil: Im Pi-hole Log seht ihr nur die FritzBox und nicht, welche Clients welche Anfragen stellen.

Überprüfe den genutzten DNS-Server im Fritz Online-Monitor (IP's habe ich entfernt):


Wer Clients sehen möchte, kann das unter "Heimnetz -> Netzwerk -> Netzwerkeinstellungen - IPv4-Einstellungen und IPv6-Einstellungen" einstellen.
Vorteil: Clients im Log anstatt der FritzBox. Nachteil: Damit ist leider nur ein DNS-Server möglich, also kein Fallback. Wenn der dann weg fällt, haben die Clients keinen DNS-Server mehr. VPN Clients und Clients im Gastnetz fragen die FritzBox als DNS und nicht das Pi-hole.

Unter Netzwerk lege ich die IP vom Raspberry Pi (z.B. 192.168.1.42) fest -> Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen. Daher muss ich keine feste IP-Adresse über systemd-networkd einrichten. Das ist eine gängige Praxis und wird oft als "DHCP-Reservierung" oder "Statische DHCP-Zuweisung" bezeichnet. Dabei wird im Router für die MAC-Adresse des Raspberry Pi eine feste IP-Adresse hinterlegt. Jedes Mal, wenn der Pi eine DHCP-Anfrage sendet, antwortet der Router mit derselben IP-Adresse.

Nachtrag: Da die FritzBox nur IPv4-Adressen statisch zuweisen kann und keine integrierte Möglichkeit bietet, DHCP-Reservierungen für IPv6-Adressen, einschließlich ULAs, vorzunehmen, habe ich eine feste IPv4-Adresse und eine IPv6-Adresse als Unique Local Address (ULA) speziell für das lokale Netzwerk konfiguriert. ULAs sind innerhalb des Netzwerks eindeutig und werden nicht im Internet geroutet. In meiner FritzBox habe ich das ULA-Präfix für IPv6-Adressen manuell auf 'fd00::/64' festgelegt.

Code Auswählen Erweitern

sudo nano /etc/systemd/network/10-static.network

[Match]
Name=end0

[Network]
Address=192.168.1.42/24  # Ersetze mit deiner festen IPv4-Adresse
Gateway=192.168.1.1      # Ersetze mit dem IPv4-Gateway, normalerweise die IP-Adresse deines Routers
DNS=192.168.1.1          # Ersetze mit der IP-Adresse deines bevorzugten DNS-Servers

Address=fd00::1111:5555:9cba:def1/64    # Ersetze mit deiner festen ULA-Adresse
DHCP=no
IPv6AcceptRA=no

Hierbei ist es wichtig zu beachten:

• Eine ULA ist spezifisch für IPv6. IPv4 verwendet stattdessen private Adressbereiche (wie 192.168.x.x).
• Das festgelegte ULA-Präfix in deiner FritzBox (fd00::/64) definiert den Bereich, aus dem du deine lokalen IPv6-Adressen auswählen kannst.
• Stelle sicher, dass deine Endgeräte IPv6-Adressen innerhalb dieses Präfixes verwenden, um im lokalen Netzwerk korrekt zu funktionieren.
• Die letzten beiden Zeilen sind nicht unbedingt erforderlich, aber sie sorgen dafür, dass keine automatische Konfiguration für IPv6 auf der Netzwerkschnittstelle stattfindet, wenn du bereits statische IPv6-Adressen manuell konfiguriert hast.

Starte dann systemd-networkd neu:

Code Auswählen Erweitern

sudo systemctl restart systemd-networkdÜberprüfe nach dem Neustart des Dienstes, ob die IP-Adressen korrekt zugewiesen wurden:

Code Auswählen Erweitern

ip addr show end0Teste die IPv4- und IPv6-ULA-Adresse, indem du von einem anderen Rechner im selben Netzwerk aus einen Ping durchführst, z.B. so:

Code Auswählen Erweitern

ping 192.168.1.42
ping -6 fd00::1111:5555:9cba:def1

Konfiguration von sudoers und Erstellung von systemd-Services zur Automatisierung der Aktualisierung von root.hints in Unbound

Durch die Verwendung von systemd für die Aufgabenplanung wird der veraltete Cron-Job ersetzt. Stattdessen wird eine systemd "service" Einheit erstellt, die den Download der root.hints-Datei und die Aktualisierung im Verzeichnis /etc/unbound gemäß einem festgelegten Zeitplan durchführt. Wenn der Download erfolgreich ist, wird die alte root.hints-Datei durch die neue ersetzt. Wenn der Download fehlschlägt, bleibt die alte Datei unverändert.

Erstelle eine neue Datei im /etc/sudoers.d/ Verzeichnis:

Code Auswählen Erweitern

sudo nano /etc/sudoers.d/unboundIn der neuen Datei fügst du die Regel ein, die dem unbound-Benutzer erlaubt, den reload-unbound.service ohne Passwort zu starten:

unbound ALL=(ALL) NOPASSWD: /bin/systemctl start reload-unbound.service

Es ist wichtig, dass die Pfade in der sudoers-Konfiguration genau mit den tatsächlichen Installationspfaden der Befehle auf deinem System übereinstimmen. Diese Datei sollte mit chmod 440 gesichert werden:

Code Auswählen Erweitern

sudo chmod 0440 /etc/sudoers.d/unbound
Erstelle eine 'reload-unbound.service' Datei als separate systemd-Einheit, indem diese speziell für das Neuladen des Unbound-Dienstes verantwortlich ist. Für diese Aktion sind root-Berechtigungen erforderlich. Dies ermöglicht eine saubere Trennung und verbessert die Wartbarkeit deines Systems:

Code Auswählen Erweitern

sudo nano /etc/systemd/system/reload-unbound.serviceFüge den folgenden Inhalt in die Datei ein:

[Unit]
Description=Reload Unbound service (need sudo)

[Service]
Type=oneshot
ExecStart=/bin/systemctl reload unbound.service

[Install]
WantedBy=multi-user.target

Erstelle ein 'update-root-hints.service' (ausgeführt als Benutzer unbound), der die root.hints Datei herunterlädt und aktualisiert, und dann den 'reload-unbound.service' startet:

Code Auswählen Erweitern

sudo nano /etc/systemd/system/update-root-hints.serviceFüge den folgenden Inhalt in die Datei ein:

[Unit]
Description=Update root hints file and reload Unbound
After=network.target

[Service]
User=unbound
Group=unbound
ExecStart=/bin/sh -c 'rm -f /etc/unbound/root.hints.new; /usr/bin/curl --output /etc/unbound/root.hints.new https://www.internic.net/domain/named.cache && mv /etc/unbound/root.hints.new /etc/unbound/root.hints'
ExecStartPost=/bin/sudo /bin/systemctl start reload-unbound.service

[Install]
WantedBy=multi-user.target

In systemd wird standardmäßig davon ausgegangen, dass ein .timer-File den zugehörigen .service mit dem gleichen Namen startet. Erstelle eine .timer-Datei, die den Zeitplan für die Ausführung der Aufgabe festlegt:

Code Auswählen Erweitern

sudo nano /etc/systemd/system/update-root-hints.timerFüge den folgenden Inhalt in die Datei ein:

[Unit]
Description=Run the update-root-hints.service monthly

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

Es wird allgemein empfohlen, die Root-Hints-Datei alle 3 bis 6 Monate zu aktualisieren. Der 'update-root-hints.service', der monatlich durch diesen Timer ausgelöst wird – eine konservative und sichere Herangehensweise –, führt nach erfolgreichem Update der root.hints Datei automatisch den 'reload-unbound.service' aus, um den Unbound-Dienst neu zu laden.

Aktiviere den systemd Timer, damit er bei jedem Systemstart automatisch ausgeführt wird:

Code Auswählen Erweitern

sudo systemctl enable update-root-hints.timerStarte den Timer und den Service:

Code Auswählen Erweitern

sudo systemctl start update-root-hints.timer
sudo systemctl start update-root-hints.service
Überprüfe den Status des "timer": Du kannst den Status des "timer" überprüfen, um sicherzustellen, dass er aktiv ist und ordnungsgemäß funktioniert:

Code Auswählen Erweitern

sudo systemctl status update-root-hints.timer
Oder die Liste aller aktiven Timer-Einheiten von Systemd anzeigen:

Code Auswählen Erweitern

sudo systemctl list-timers
Jetzt sollte der Timer den Service entsprechend dem definierten Zeitplan ausführen, und die Aufgabe zur Aktualisierung der root.hints-Datei wird von systemd verwaltet.

Bei einem Problem lässt sich 'update-root-hints.service' manuell so testen:

Code Auswählen Erweitern

sudo systemctl start update-root-hints.serviceÜberprüfen auf mögliche Fehler:

Code Auswählen Erweitern

journalctl -u update-root-hints.service
Wenn du Änderungen an systemd-Konfigurationsdateien vornimmst, solltest du die systemd-Konfiguration neu laden. Dies erreichst du mit dem Befehl 'sudo systemctl daemon-reload'. Anschließend solltest du den betroffenen Timer mit 'sudo systemctl restart update-root-hints.timer' neu starten.



Aktualisiere regelmäßig deine Paketlisten

Die Stable-Updates von Manjaro ARM sind moderat und laut forum.manjaro.org ungefähr alle 2 Monate. Die AUR-Quellen (Arch User Repository) werden von der Community gepflegt und sollten daher regelmäßig überprüft werden. Mindestens alle 6 Monate, idealerweise jedoch monatlich, solltest du deine Paketlisten prüfen/aktualisieren. Verwende dazu die folgenden Befehle:

Für die Grundaktualisierung

Code Auswählen Erweitern

sudo pacman -Syu
yay -Syu  # Achtung: 'sudo' wird hier nicht benötigt!
Nach erfolgreichen Abschluss der Aktualisierung und Kernel Update, ist ein Neustart des Raspberry Pi wichtig:

Code Auswählen Erweitern

reboot
Optional: Aktualisiere die Blockierliste von Pi-hole:

Code Auswählen Erweitern

pihole -g
Entferne nicht benötigte Pakete:

Code Auswählen Erweitern

sudo pacman -Rsn $(pacman -Qdtq)
Optional, dieser Befehl reicht aus, um sowohl den pacman- als auch den yay-Cache zu bereinigen:

Code Auswählen Erweitern

yay -v -Scc
Überprüfe trusted-key.key
Diese Datei enthält einen Zeitstempel, wann sie zuletzt aktualisiert wurde:

Code Auswählen Erweitern

cat /etc/unbound/trusted-key.keyDie Ausgabe der Datei enthält Einträge wie last_queried und last_success, die anzeigen, wann die Datei zuletzt abgefragt und erfolgreich aktualisiert wurde. Diese Informationen helfen zu bestimmen, wie aktuell die Trust-Anchor-Informationen in deinem Unbound-DNS-Resolver sind.

Überprüfe die Root Hints
Aktuellen Status überprüfen:

Code Auswählen Erweitern

ls -l /etc/unbound/root.hintsInhalt der Root Hints Liste mit den 13 Servern (A-M) überprüfen:

Code Auswählen Erweitern

cat /etc/unbound/root.hints
Manuelles Update, falls erforderlich:

Code Auswählen Erweitern

sudo curl --output /etc/unbound/root.hints https://www.internic.net/domain/named.cache
Hinweis: Dies sollte nicht notwendig sein, wenn du eine .timer-Datei dafür eingerichtet hast.

Überprüfe Liste aller aktiven Timer-Einheiten von Systemd

Code Auswählen Erweitern

sudo systemctl list-timers
Um die Berechtigungen für den Ordner /etc/unbound, einschließlich aller darin enthaltenen Dateien und Unterverzeichnisse, rekursiv auf den Benutzer und die Gruppe unbound zu setzen (falls die Berechtigungen geändert wurden), verwende den folgenden Befehl:

Code Auswählen Erweitern

sudo chown -R unbound:unbound /etc/unbound
Systemdiagnose
Überprüfe den verfügbaren Speicherplatz:

Code Auswählen Erweitern

df -hÜberwache die Systemressourcen:

Code Auswählen Erweitern

htopDieses Tool zeigt eine kontinuierliche Liste der Netzwerkverbindungen und deren Bandbreitennutzung auf "end0" an:

Code Auswählen Erweitern

sudo iftop -i end0Neustart deines Systems, z.B. nach einem Kernel-Update mit:

Code Auswählen Erweitern

reboot
Oder schalte es aus, um beispielsweise die SSD durch ein Backup zu ersetzen. Falls du zwei SSDs verwendest:

Code Auswählen Erweitern

shutdown -h 0(seit systemd, kannst du auch einfach "poweroff" nutzen)



Testseiten:

• Pi-hole Testseite
• internet.nl/connection/
• rootcanary.org/test.html

Quellen:

• wiki.archlinux.org/title/Pi-hole
• aur.archlinux.org/packages/pi-hole-server
• wiki.archlinux.org/title/Unbound
• Pi-hole mit FritzBox
• CC2.tv: Weg mit dem Dreck!
• Dennis Schröder: Pi-hole Unbound
• Wiki: Domain Name System
• Mike Kuketz: Pi-hole: Einrichtung und Konfiguration mit Fritz!Box – AdBlocker Teil1
• Mike Kuketz: Pi-hole: Einrichtung und Konfiguration mit unbound – AdBlocker Teil2
• digitalcourage.de und Digitale Selbstverteidigung

Achtung: Die Links sind teilweise auf Linux Debian fixiert, dennoch können diese hilfreich sein.