Ursprünglich veröffentlicht: https://www.kuketz-blog.de/pi-hole-einrichtung-und-konfiguration-mit-unbound-adblocker-teil2/
1. unbound Im ersten Teil der Artikelserie »AdBlocker« wurde gezeigt, wie man ein Pi-hole in das (Heim-)Netzwerk einer Fritz!Box integriert. Nach der Umsetzung werden Werbung, Tracker, Affiliates, Telemetrie, Malware, Scam etc. zuverlässig herausgefiltert – das Internet wird für Clients im Netzwerk ein Stück sauberer. Der vorliegende Artikel beschreibt, wie man den rekursiven DNS-Server unbound auf einem Pi-hole konfiguriert. Dadurch wird nicht nur die Abhängigkeit von öffentlichen DNS-Servern aufgehoben, sondern auch die DNS-Abfragen werden schneller beantwortet. Die Konfiguration richtet sich an fortgeschrittene Benutzer – Anfängern empfehle ich, das Setup aus dem ersten Teil zu verwenden. Dieser Beitrag ist Teil einer Artikelserie:…
Möchte noch als Info mitteilen das seit wenigen Tagen offiziell Raspberry Pi OS Bookworm verfügbar ist.
Okay danke. Sollte sich aber nichts ändern an der Anleitung.
Wenn ich das richtig verstehe, ist der Vorteil von externen DNS-Providern wie dnsforge.de, dass man „in der Masse“ der Anfragen untertaucht. Denn die letzte Meile ist ja auch dort nicht mehr verschlüsselt. Richtig?
Was meinst Du mit „letzte Meile“ in dem Zusammenhang ?
Ich glaube openresolv ist nicht mehr per Default dabei.
Soll heißen, dass wenn wir DoT- oder DoH-Server nutzen, die Verbindung/Anfrage auch bis zu diesen verschlüsselt ist. Der Server entschlüsselt aber die Anfrage. Er schickt sie dann im Klartext an die Root-Server. Der ISP sieht die Anfrage nur verschlüsselt, während bei Unbound-Nutzung der ISP die Anfrage unverschlüsselt sieht. Im letzteren Fall sieht der ISP, welche Seiten ich aufrufe, im ersten Fall der DNS-Provider. So verstehe ich das.
Die letzte Meile ist die Anfrage an den Root-Server.
Sofern keine weiteren Vorkehrungen getroffen werden, sieht der ISP ja sowieso immer zumindest welche Hosts man aufruft. Ob der das dann schon bei der DNS-Anfrage mitbekommt oder später, ist auch egal.
Was ich etwas kritischer bei der unbound-Variante sehe ist, dass alle Abfragen unterhalb der root-Ebene an zufällige, von mir nicht beeinflussbare Serverbetreiber gehen, die diese Anfragen mit meiner IP verknüpfen können.
Mein DNS-Fingerprint auf allen besuchten Seiten ist ebenfalls nicht wirklich „massentauglich“.
Im Falle von DNS-Providern ist die unverschlüsselte Abfrage von root abwärts ja egal. Dabei kommt ja auf der Seite keine Verknüpfung zu mir zustande. Meine IP sieht nur der DNS-Provider.
Ja deine Punkte treiben mich auch immer wieder um. Nutze AdGuard Home mit Unbound auf nem Raspi, aber frage mich oft, ob das Abfragen über mehrere vertrauenswürdige DNS-Server nicht sinniger/anonymer ist. Muss halt jeder für sich selbst beantworten.
Den ewig langen Kommentarblock in der Unbound-Konfigurationsdatei kann man sich übrigens schenken, das ist sowieso der Default.
Wie lange unbound Informationen aus dem Cache ausliefert, wird mit dem Parameter serve-expired-reply-ttl beeinflusst.
Mit serve-expired-reply-ttl wird beeinflusst, welche TTL abgelaufene bekommen, die trotzdem ausgeliefert werden. Wie lange solche Einträge ausgeliefert werden, wird mit serve-expired-ttl eingestellt.
Nach der Konfiguration nach dieser Anleitung enthalten die meisten Einträge im log von pi-hole unter „Status“ „INSECURE“. Bei einigen Einträgen steht wunderbar „SECURE“.
Ist das etwas, worüber ich mir Sorgen machen sollte?
Was bedeutet das im Ergebnis nach Maßgabe der Anleitungen Teil 1 und Teil 2?
a) auf unbound ist zu verzichten?
b) Teil 2 der Anleitung verlangt eine weitere Anpassung?
@kuketzblog
Die Anleitungen schrittweise in Teile aufzuteilen finde ich genial. Ich denke, in dieser Modularität trauen sich das immer mehr User zu solchen Anleitungen zu folgen.
Gibt es iwann einen Teil 3 mit einem Wireguard-Setup?
Das bedeutet, dass jeder basierend auf den eigenen Schutzbedürfnissen die Dinge umsetzen sollte, die am meisten Sinn ergeben. Die Entscheidung kann einem keiner abnehmen, es werden hier ja nur Informationen und Argumente zur Entscheidungsfindung bereitgestellt. Diese sollte man auch immer kritisch für den eigenen Anwendungsfall hinterfragen.
Beispielsweise, wenn es keine grundlegenden Kopfschmerzen bereitet, den ISP mit Daten zu versorgen, dann sehe ich aus rein datenschutztechnischer Sicht keine Vorteile für unbound - ganz im Gegenteil wie oben beschrieben. Dann könnte man auch besser einfach den ISP-DNS benutzen, hätte somit keine unvermeidbaren Unbekannten und einen weniger individuellen Fingerprint. Andere durchaus valide Gründe für unbound wie Performance oder „Zensur“ sind da mal aussen vor.
Persönlich fahre ich eh eine ganz andere Schiene, da aus meiner Sicht insbesondere der ISP (der ja üblicherweise der einzige Player in der ganzen Konstellation ist, der meine tatsächliche Identität kennt) möglichst wenig über mein Nutzungsverhalten erfahren soll.
Danke, ich nehme an Deine individuelle Konfiguration ist so unüblich, dass Du sie nicht einmal hier dauerhaft veröffentlicht sehen willst - sonst hättest Du sie erwähnt statt sie nur anzudeuten.
Klar, nach dem Film über den Gründer von silk road geht man mit dem Tor Browser in einem 2nd-Hand-Laptop von der Straße in ein öffentliches WLAN.
Ich hab mal den Tor Browser ausprobiert - das ist eine unerträgliche Verzögerung.
Ich suche eine Lösung, die community-weit anerkannt ist.
Weder unüblich noch „geheim“: einfach nur VPN + DoT. Das gehört jetzt aber alles nicht mehr in das Thema des Threads.
ok, wo finde ich „Deine“ Anleitung? wenn es keine gibt, gehört es durchaus hier rein
@kuketzblog Danke für die aktualisierte Anleitung! Bisher habe ich die (gut funktionierende alte) Anleitung von tschaeggar im Einsatz gehabt, war dennoch interessiert an dieser Version der Anleitung.
Frage/Fehler in der Anleitung?:
Muss eigentlich in der Fritzbox unter Fritzbox-Zugangsdaten-DNSServer-andere DNSv4/v6 Server nicht auch die ip-Adresse des piholes eingetragen werden, wenn man unbound installiert hat?
(DIe letzte Anleitung von Dir:
https://www.kuketz-blog.de/pi-hole-unbound-hyperlocal-keine-werbung-groesstmoegliche-unabhaengigkeit/
unter dem Punkt 4:
" In einer Fritz!Box z. B. muss man dies an zwei Stellen tun: Einmal unter »Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4-Adressen → Lokaler DNS-Server«, dort die IP-Adresse des Pi eintragen (192.168.1.5). Zudem tragen wir die IP-Adresse zweimal unter »Internet → Zugangsart → DNS-Server« ein und wählen Andere DNSv4-Server verwenden ." )
VG vsa
EDIT: Ich habe übrigens das Ganze auf einem Pi3 mit dem aktuellen Bookworm (64,lite) installiert.
Ich hab das zwar schon alles am laufen (altes Tutorial hier) aber wollte es noch mal frisch auf Bookworm aufsetzen.
Hab ich 1zu1 an die Anleitung gehalten, allerdings ergeben die Befehle
sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
no such directory or file (oder so ähnlich)
Scheint aber trotzdem alles zu laufen. Was seltsamer Weise aber nicht funktioniert ist der DNSSEC Test auf dieser Seite:
https://wander.science/projects/dns/dnssec-resolver-test/
Hier kommt der Test zu keinem Abschluss. Mit meiner alten Installation aber schon.
Wenn alle Gerätschaften im eigenen Netz pi-hole als DNS verwenden, wird die Fritzbox nicht nach IPs gefragt werden. Wichtig ist dann aber, sicher zu stellen, dass das wirklich so ist. Also z.B. per DHCP versorgte Geräte den DHCP-Server von pi-hole bzw. dnsmasq verwenden zu lassen und den in der Fritzbox lahmzulegen.
hat sich irgendwie von selbst erledigt, geht nun.
Noch eine andere Sache:
dig @192.168.50.5 example.com +udp
wirft aus: „Invalid option: +udp“