@brezel20 wegen der root.hints schau dir einmal im Pihole Forum das Thema an. Da ging es um die root.hints und deren Update…
1 „Gefällt mir“
Danke für den Hinweis!
Hi, ich stolpere auch noch darüber, dass zwar unter
Zugangsdaten > DNS-Server nach wie vor die Einstellung von Teil 1 bestehen bleibt, andererseits die Geräte über Netzwerkeinstellungen den pihole und damit unbound als DNS-Server zugewiesen bekommen (vgl. hier). Ich glaube schon, dass ich grundsätzlich verstehe, warum man das nicht braucht (steht ja auch in der zitierten Antwort).
Kann ich das irgendwie prüfen, dass das auch wirklich funktioniert?
Und gibt es dennoch Anfragen, die dann nicht über unbound laufen? Z. B. die von der FritzBox an den NTP-Server?
Ich habe z. B. Anfragen in meiner Query List:
Ich interpretiere das so, dass die Anfrage vom pi.hole an deepl.com nicht über unbound läuft, also über den DNS-Server (in meinem Fall von Digitalcourage), die Anfrage von notebook aber schon?
Ich gehe davon aus, dass es um eine fritzbox geht. Die Einstellung dort bewirkt, dass die Fritzbox selbst den dns server nutzt. Auch ein Gastnetz nutzt indirekt diesen, da das Gastnetz immer die Box als DNS Server mittels DHCP gibt. Das ist auch richtig, da dein Heimnetz ja physisch getrennt sein soll.
In IPv4 und IPv6 IP Einstellungen werden die DHCP Optionen für das private heimnetz gesetzt.
Damit die neuen Einstellungen über DHCP auch erfolgreich verteilt werden, müssen Geräte sich neu verbinden. Ich mach das einfach mittels WLAN aus, paar Sekunden warten und wieder anschalten. Bei lan Verbindungen sollte es reichen kurz das Netzwerkkabel zu ziehen.
Oder man nimmt die Holzhammermethode und macht einen Router Neustart
Pihole wiederum nimmt das, was du in den Settings dort eingestellt hast. Wenn du einen lokalen Dienst wie einbound nutzt, dann steht da nur „localhost“ und der Port drin. Es wird dir mitgeteilt, wohin die Anfrage weitergeleitet wurde.
Aber könnte man nicht trotzdem in der Fritzbox auch den PiHole als DNS Server einstellen und damit alles, auch die Anfragen der Box über unbound leiten? (wie in der anderen zitierten Einstellung auch schon).
Wie gesagt, das tust du über die zugangsdaten. Das habe ich auch so geschrieben
Verstehe, aber ist das möglich oder macht das Probleme? Das verstehe ich noch nciht 
Natürlich ist das möglich.
Das einzige, was man vermeiden sollte, ist ein Loop, ergo fritzbox verweist dort die anfragen auf pihole und pihole hat die fritzbox hinterlegt.
Aber dann würde auch gar nichts mehr klappen mit dem Internet 
Danke, ich schau mal ob ich das hinbekomme
Edit: ist umgestellt und funktioniert noch… Mal sehen 
Wie sähe das denn aus, wenn man von unterwegs mittels VPN oder Wireguard über die FRITZ!Box surfen möchte und dabei unbound mit Pi-Hole als DNS-Server nutzen möchte (und das private Netzwerk von Pi-Hole verwaltet wird, mit der FRITZ!Box nur als Router)?
Nach meinem Verständnis müsste man dann ebenfalls die IP-Adresse von Pi-Hole/unbound unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv4 (bzw. IPv6)-Einstellungen hinterlegt werden.
Hat man dann schon so eine Schleife und birgt das Risiken, weil DNS-Anfragen von der FRITZ!Box zum Pi-Hole laufen, der auch das von der ISP-FRITZ!Box abgetrennte private Netz verwaltet?
Wenn man wireguard einrichtet auf der FRITZ!Box generiert ist die generierte DNS Einstellung abhängig von den DHCP Optionen.
Im Standard steht da „192.168.178.1, fritz.box“. Wenn man die dchp Optionen modifiziert hat, steht beim generieren dort „192.168.178., 192.168.178.1, fritz.box„. Dann laufen die requests direkt über den pi. Die erste Option wäre nur fürs surfen jetzt auch kein Zackenbruch.
Edit: habe es missverstanden. Du nutzt den pi als dchp. Müsste dennoch klappen, wenn du die Einstellungen in der FRITZ!Box richtig setzt.
Und nein, wirklich Risiken birgt es nicht. Klar öffnest du einen Port nach außen. Aber du kannst dich ja nur mit wireguard verbinden. Wenn du verbunden bist, ist jeder traffic verschlüsselt durch das VPN, also von der box zum Handy. Egal welche Art von traffic.
Für dein Gerät ist das dann so, als wäre es im heimnetz
Sorry, ich muss nochmal etwas fragen… Ich habe soweit alles nach Anleitung gemacht und nun die Einstellungen auf Teil 1 der Anleitung zurückgestellt, gehe also nicht mehr über unbound, habe das Tool aber noch auf dem Raspi in der Config von Teil 2 installiert.
Die Anfragen werden also wieder über die Fritzbox und über DNS-Server geleitet.
Nun kann ich ein Phänomen beobachten: Als ich das das erste Mal nach Teil 1 eingerichtet habe (vor unbound), war bei jeder Anfrage im Pihole unter Status: OK noch gestanden: SECURE.
Das Secure ist jetzt weg. Jetzt steht dort nur OK (cache) oder OK (answered by fritz.box#53)
In der Fritzbox ist DoT (wieder) aktiviert.
Kann es sein, dass durch die unbound-Installation / Konfig, die es noch gibt, etwas durcheinander kommt?
(Grund für die Umstellung zurück war: Mir kam der Seitenaufbau danach mit unbound langsamer vor. Gefühlt gehts ohne tatsächlich etwas schneller…)
Hi,
ich bekomme timeout Fehler, aber nur bei diesen Domain-Abfragen:
$ dig fail01.dnssec.works @127.0.0.1 -p 5335
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
; <<>> DiG 9.18.24-1-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached
$ dig dnssec.works @127.0.0.1 -p 5335
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
; <<>> DiG 9.18.24-1-Raspbian <<>> dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached
Andere Domain-Abfragen funktionieren:
$ dig tagesschau.de @127.0.0.1 -p 5335
; <<>> DiG 9.18.24-1-Raspbian <<>> tagesschau.de @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37804
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tagesschau.de. IN A
;; ANSWER SECTION:
tagesschau.de. 86400 IN A 34.110.152.241
;; Query time: 60 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Fri Jul 26 21:35:19 CEST 2024
;; MSG SIZE rcvd: 58
Wie kann man vorgehen um dieses Problem zu analysieren?
Ich würde erst mal das Timeout von dig hochsetzen und schauen, was passiert:
$ dig fail01.dnssec.works @127.0.0.1 -p 5335 +timeout=60
Moin,
einige berichten, dass sie die Anfragen aus dem Gastnetz im PiHole sehen können, nur als Quelle die Fritzbox angegeben wird.
Ich habe das gerade getestet, wenn ich mit meinem Handy ins Gastnetz gehe, kann ich die Anfrage nicht sehen.
Bei mir läuft Pihole mit Unbound, im Pihole ist also der Upstream DNS mit 127.0.0.1#5353 angegeben. In der FritzBox ist als Upstream der PiHole eingetragen, also eigentlich müsste das so passen nach allem was ich gelesen habe. Könnte etwas fehlen?
Update: Eher durch Zufall bin ich heute auf die Lösung des Rätsels gekommen: Ich hatte die Verbindungen des Handys (damit habe ich getestet) über einen VPN geroutet… Wenn ich das deaktiviere sehe ich auch die Anfragen des Gastnetzes im PiHole, aber als Client eben die FritzBox (wie erwartet).
Für alle, die im Thema sind:
ist das hier der aktuelle Stand oder gibt es neuere Threads/Anleitungen?
Wieso hast du meinen Beitrag verlinkt?
Afaik ist Mikes Anleitung aktuell und noch genau so anwendbar.
Hallo, gleich bei der unbound Installation bekomme ich einen Fehler:
androidin@raspberrypi:~ $ sudo apt install unbound
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
unbound
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 884 kB of archives.
After this operation, 4,929 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bookworm/main arm64 unbound arm64 1.17.1-2+deb12u2 [884 kB]
Fetched 884 kB in 1s (1,057 kB/s)
Selecting previously unselected package unbound.
(Reading database ... 163546 files and directories currently installed.)
Preparing to unpack .../unbound_1.17.1-2+deb12u2_arm64.deb ...
Unpacking unbound (1.17.1-2+deb12u2) ...
Setting up unbound (1.17.1-2+deb12u2) ...
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145.
Processing triggers for man-db (2.11.2-2) ...
OS: Bookworm, 64 bit. Die Anleitung 1 hab ich komplett durchmachen können. Es scheint wohl an dieser Zeile hier zu liegen:
if (@start_units) {
system('systemctl', '--quiet', @instance_args, $action, @start_units) == 0 or die("Could not execute systemctl: $!");
}
Wie kriege ich denn das hin?
OK, ich habe folgendes gemacht, dann lief die Installation durch:
sudo nano /etc/resolv.conf
hier temporär eintragen:
nameserver 8.8.8.8 # Google Public DNS
nameserver 1.1.1.1 # Cloudflare DNS
search fritz.box
# nameserver 192.168.178.19
# nameserver fd00::5ae5:15b3:47b9:7cd5
Dann den Service stoppen:
sudo systemctl stop pihole-FTL.service
Dann die unbound Installation:
sudo apt install unbound
Und dann die Änderungen wieder rückgängig in der resolv.conf
Leider ist der Port 53 immer noch belegt, den bräuchte ich für meine nextcloud-Installation. Wie kann ich den stoppen?
Hat sich schon jmd. getraut auf pi-hole Version 6 zu gehen und kann berichten ob das Zusammenspiel mit unbound läuft? Unter der Haube gibts massive Änderungen (weg von lighttpd etc.) und wohl auch konfigurationstechnisch ist einiges neu.
Upgrading to Pi-hole v6 should be straightforward.
Ich kann berichten, dass das nicht der Fall ist. Im Verlauf des Updates wird pihole-FTL neugestartet. Anschließend wurde endlos (sprich erfolglos) gewartet, bis die DNS-Auflösung wieder funktioniert. Ich habe daraufhin das Update abgebrochen.
During the upgrade operation, you will be presented with a dialog box asking if you wish to disable
lighttpd.
Dies ist daher nie eingetreten. Ein erneutes Update meinte dann, alles wäre auf dem neuesten Stand und hat nichts verändert. Ein Webserver läuft nun zwar, jedoch kann ich keine Seite zur Steuerung des Pi-holes aufrufen. Eine Reparatur (pihole -r) rettet den Web-Inhalt leider auch nicht mehr.
Lösung: lighttpd musste manuell deaktiviert werden:
$ systemctl disable --now lighttpd
Die Frage ist nur: Habe ich beim Abbruch des Updates noch etwas anderes Wichtiges übersprungen?
Vielleicht könnte das Problem vermieden werden, wenn vor dem Update temporär in der /etc/resolv.conf ein externer Nameserver eingetragen wird, z. B. einer vom Internetanbieter oder 9.9.9.9. Mag das mal jemand ausprobieren?