Pi-hole: Einrichtung und Konfiguration mit unbound – AdBlocker Teil2

Hallo,
wie ist eure Meinung zum Cloudflared Setup?
Ich nutze es in Verbindung mit Quad9.

https://docs.pi-hole.net/guides/dns/cloudflared/
https://docs.quad9.net/Setup_Guides/Miscellaneous/Cloudflared_and_Quad9/

Ich glaube ich habe hier Unsinn geschrieben oder? Wenn ich Unbound nutze, sieht mein ISP dann doch gar nicht, welche Seite ich aufrufe? Ich kann ja in Deutschland gesperrte Seiten mit Unbound-Nutzung einfach aufrufen, währenddessen die gesperrt sind, wenn ich Unbound nicht nutze. Dann aber sieht doch mein ISP nicht, welche Seite ich aufrufe, wenn ich Unbound nutze oder? Man berichtige mich bitte. :smiley:

JEIN - die Begrifflichkeiten sind hier ggfs. irreführend. :wink:

Wenn Du mit „welche Seiten ich aufrufe“ rein den DNS-Verkehr meinst, wäre Deine Aussage ja richtig:
(a) Geht man per DOT/DOH zum DNS-Provider, sieht der ISP nur, dass der besagte DNS-Server angefragt wird, nicht aber was angefragt wird.
(b) Per Unbound laufen alle Anfragen zu den diversen Servern unverschlüsselt über den ISP, der diese auswerten könnte.

Falls mit „welche Seiten ich aufrufe“ allerdings auch der der DNS-Anfrage folgende tatsächliche Datenverkehr gemeint ist, dann ist der ISP auch bei (a) wieder im Boot. Selbst bei verschlüsselter Verbindung sieht dieser ja die IP (bzw. Host), welche angesteuert wird. Die konkret abgerufene Ressource allerdings nicht. Ohne Verschlüsselung auch das.

Beim Thema „in Deutschland gesperrte Seiten“ kommt es auch wieder drauf an:
(1) Gibt es eine Sperre beim DNS-Anbieter, kommt halt keine IP als Antwort zurück und man kann keine Verbindung herstellen. Gegen solch eine Sperre könnte unbound helfen.
(2) Liegt die Sperre aber zugriffsseitig beim ISP, hilft auch das nicht. Unbound liefert zwar die IP, der ISP läßt aber keine Verbindung zu.

Ohne weitere Maßnahmen sieht der ISP letztlich immer, wohin Du willst, nur nicht zwangsläufig was Du da machst.

1 „Gefällt mir“

Danke vielmals. Nun habe ich noch AdGuard Home, und dort Unbound konfiguriert. AGH verschlüsselt die DNS-Anfragen ja per DoH, DoT etc. Das ändert, wenn ich dich richtig verstehe, aber nichts an den von dir beschriebenen Punkten?

Verstehe ich leider nicht so ganz: Pi-Hole + AdGuard Home + unbound zusammen ?
Wer macht denn da jetzt die tatsächliche DNS-Anfrage „nach draußen“ ?

Danke schon mal für die Antwort.

jedoch… wenn ich strikt nach Anleitung Mike vorgehe, also Pi-hole und unbound auf einem Rpi3 (unter bookworm) laufen lasse und der FritzBox, genau wie in der Anleitung, das DHCP machen lasse, dann bekommen alle Clients im Netzwerk eine IP Adresse, die dann auf den PiHole als DNS Server zugreifen. Daher meine Frage, ob der fehlende Eintrag in der FritzBox nicht noch ein zu erledigender Punkt sein müsste?! Auch in Taschaeggars Anleit7ng war das eben so beschrieben.

Viele Grüße Vsa

Hihi, nein in meinem Fall kein Pi-Hole. :smile:
In AGH habe ich als Upstream-DNS Unbound.

Ja, OK … also AGH statt Pi-Hole. Bei vergleichbarer Konfiguration sind wir dann wieder bei der oben beschriebenen Konstellation - es ändert sich nichts. AGH wird aber mit unbound nicht per DoT/DoH kommunizieren. Selbst wenn - hilft auch nix, wenn es nach extern unverschlüsselt weiter geht.

ich denke ja. Ich habe für bevorzugten und alternativen DNS Server jeweils die IPv4 sowie die IPv6 dort eingetragen.

jedoch… wenn ich strikt nach Anleitung Mike vorgehe, also Pi-hole und unbound auf einem Rpi3 (unter bookworm) laufen lasse und der FritzBox, genau wie in der Anleitung, das DHCP machen lasse, dann bekommen alle Clients im Netzwerk eine IP Adresse, die dann auf den PiHole als DNS Server zugreifen.

Ach so. Ich lasse pi-hole bzw. das darunter liegende dnsmasq auch DHCP machen, den im Router habe ich abgeschaltet. So steht thematisch Verwandtes an der selben Stelle. Ist aber sicherlich Geschmacksache.

@kuketzblog Hältst Du es nicht für sinnvoll die Anleitung um den Punkt bzw. Abschnitt „Upstream DNS Server mit DNS-over-TLS“ im Privacy-Handbuch zu erweitern?

Nein. Ziel des Setups ist die Unabhängigkeit von einem Upstream-DNS-Server.

1 „Gefällt mir“

Wenn ich Teil 2 (unbound) umsetzen will, muss ich in der Fritz-Box DoT deaktivieren, oder? Zumindest bekommt meine Fritz-Box ansonsten keine DoT-Verschlüsselung zum Pi-Hole hin und fällt auf einen anderen DNS-Server zurück.

Vielen Dank für die schöne Anleitung.

Ich komme an einem Punkt nicht weiter: ich versuche, Anfragen von einem anderen lokalen Client zu erlauben, da der Pi-Hole und unbound nicht auf der gleichen Maschine laufen.

Ich hatte gehofft, man müsste hierzu nur den Interface-Part ändern

interface: 192.168.x.y

Dies führt jedoch leider dazu, dass sich unbound nicht erneut starten läßt:

● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2024-01-06 15:03:42 CET; 53s ago
       Docs: man:unbound(8)
    Process: 5624 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 5627 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
    Process: 5630 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE)
    Process: 5631 ExecStopPost=/usr/lib/unbound/package-helper chroot_teardown (code=exited, status=0/SUCCESS)
   Main PID: 5630 (code=exited, status=1/FAILURE)
        CPU: 445ms

Jan 06 15:03:42 raspberrypi systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Jan 06 15:03:42 raspberrypi systemd[1]: Stopped Unbound DNS server.
Jan 06 15:03:42 raspberrypi systemd[1]: unbound.service: Start request repeated too quickly.
Jan 06 15:03:42 raspberrypi systemd[1]: unbound.service: Failed with result 'exit-code'.
Jan 06 15:03:42 raspberrypi systemd[1]: Failed to start Unbound DNS server.

Kann mir jemand helfen, was hier schiefläuft? Muß ich hier Parameter zur access control verwenden?

Der Raspberry ist frisch aufgesetzt, es ist allerdings ein älteres Modell auf dem das aktuelle Raspberry Pi OS Legacy läuft.

Vielen Dank!

Du hast nicht ernsthaft den Wert da oben mit .x.y eingetragen? :face_with_peeking_eye:

Danke der Nachfrage, aber nein. :wink:

Ich habe es hinbekommen dank der Dokumentation zu unbound im Web, nachdem ich zuvor nur die man-Page bemüht hatte:

https://unbound.docs.nlnetlabs.nl/en/latest/use-cases/home-resolver.html#setting-up-for-the-rest-of-the-network

interface: 0.0.0.0
access-control: 192.168.0.0/16 allow
2 „Gefällt mir“

Ich habe „Teil 2“ kürzlich durchgespielt und bin auf ein paar Stolpersteine gestoßen, die hier teilweise schon angesprochen wurden.

  • Raspberry Pi OS basiert jetzt auf Bookworm statt Bullseye
  • Der ‚Debian Fix‘ unter Punkt 5 scheint nicht mehr notwendig zu sein. In meiner /etc/resolvconf.conf gibt es keine Zeile, die mit unbound_conf= beginnt. Eine Datei namens resolvconf_resolvers.conf exisitiert ebenfalls nicht.
  • Der Befehl dig @192.168.50.5 example.com +udp in Kapitel 6 liefert eine Fehlermeldung: Invalid option: +udp
  • Die Datei /var/log/syslog existiert unter Debian12 (bookworm) nicht mehr, da Rsyslog nicht mehr standardmäßig mitinstalliert wird.

Mir ist klar, dass Blogartikel keinen Anspruch auf Aktualisierung haben, aber es wäre trotzdem schön, wenn dieser „Datenschutz“-Baustein auf einem aktuellen Stand wäre, damit Interessierte nicht frustriert aufgeben.

1 „Gefällt mir“

Vor wenigen Tagen auf der aktuellen Bookworm Distribution meinen bestehenden Pihole (mit Unbound) auf einen neuen Pi4 umgezogen. Die Anleitungen (Teil 1 und 2) lassen sich auch immer noch problemlos anwenden.

Habe allerdings das Problem, dass 2 meiner Geräte im Netzwerk (das Panel meiner Heizung und ein AVR) nicht damit zurecht kamen, wenn der Pihole als DNS hinterlegt ist. Diese Geräte waren in Pihole dann auch nicht als Clients hinterlegt, auch ein manuelles hinterlegen löste das Problem nicht. Nach längerer Recherche kam ich auf die Idee, das die Probleme ggf. daher kommen könnten, dass diese Geräte kein IPv6-Protokoll unterstützen. Das habe ich am PC dann getestet das IPv6-Protokoll zu deaktivieren und auch hier funktionierte nach der Umstellung auf IPv4 keine Namensauflösung mehr (Ping zu bekannten IPv4-Adressen im Netz funktioniert weiterhin).

Woran kann es liegen, wenn eine Namensauflösung bei Geräten, die nur das IPv4 Protokoll unterstützen, nicht erfolgt?

Was sagen denn die Logs dazu genau?