Einstellungssache: Fritzbox ipv4 & ipv6 mit pihole Container und musl C Basis

senpai · April 13, 2024, 1:29pm

Moin Freunde,
ich habe etwas Schwierigkeiten dabei meine Pihole Instanz richtig zum Laufen zu bringen und wäre für jeden Hinweis und Tipp dankbar.

Setup: Pihole läuft und das Dashboard zeigt mir auch Statistiken an. Meine PiHole Instanz läuft über Docker Compose (network mode: host) auf einem Rpi. OS ist alpine-linux (aarch64). DHCP Server ist der Router. "FRITZ!Box verwendet einen DS-Lite-Tunnel" (urgh)

Beobachtetes und erwartetes Verhalten

Probleme bis hierhin: einige, aber der Reihe nach..

Ich habe mich nach den offiziellen Pi Docs orientiert und alles so eingerichtet wie es sollte. Das klappte aber nicht. Insbesondere bin ich bei ip6 gescheitert. Wenn ich es genau so einrichte wie im FritzBox Einrichtungsguide hier verliere ich den Zugang zum Internet.
Also habe ich die Einstellungen für ipv6 rückgängig gemacht und fürs Erste den pihole nur als Upstream Server für ipv4 Anfragen gesetzt (im Reiter Heimnetz und im Reiter Internet). Unter DNSv6-Server (im Reiter Internet) habe ich Quad9's DNS Adressen genommen. (DoT habe ich wieder ausgeschaltet) Der lokale DNSv6-Server im Reiter Heimnetz/Netzwerkeinstellunge/IPv6-Adressen ist auch auf Standard (sprich die IP des Routers) gesetzt.

In der Fritzbox wird mir folglich im Online Monitor folgendes gezeigt:

Genutzte DNS-Server
192.168.178.88
2620:fe::fe (aktuell genutzt für Standardanfragen)

was soviel bedeutet wie dass die Fritze alle Anfragen an Quad9 sendet. Wenn ich dnsleaktest.com aufrufe werden mir auch immer die Server von Q9 aufgelistet. Die Anfragen werden also nicht an die Ip des Rpi und damit auch nicht an den pihole gesendet. Soweit so gut.

Nach mehreren Tagen Troubleshooting und nachdem ich auch fast alles vorgenommenen Einstellungen wieder rückgängig gemacht habe, habe ich folgende Beobachtungen gemacht:

wenn ich einnen nslookup vom PC aus mache kriege ich folgenden Output im Terminal:

communications error to 192.168.178.88#53: timed out

-> in UFW habe ich aber explitzit DNS Anfragen auf allow gesetzt und ufw status zeigt mir das auch so an.

Ich kann vom PC meinen Router mit der Gateway Adresse anpingen und habe keinerlei Paketverluste, vom Rspi aber klappt das nicht. Wenn ich hingegen fritz.box anpinge funktioniert es wiederum. Seltsam!
Alle Geräte die mit dem Heimnetz verbunden sind tauchen alles als Clients im Dashboard unter Total Queries auf haben aber unter Interface eth0 aufgelistet auch wenn sie über WLan verbunden sind.
Edith: Mir ist außerdem aufgefallen, dass die Uhrzeit zwei Stunden nachläuft. Eine Anfrage über den PC erscheint mir im Query Log anstatt um 15:00 Uhr um 13:00 Uhr. Das kann ich mir insofern nicht erklären, als dass der 'date' -Befehl die richtige Uhrzeit und Datum zurückgibt. Auch zeigt mir pihole --tail im Terminal die richtige Uhrzeit an. Der Zeitversatz erscheint nur im Dashboard.

Das ist jetzt der aktuelle Stand meines Setups. Ich habe fast alle Einstellungen die nicht ootb funktionierten wie gesagt zurückgenommen, um die Fehlerquellen besser identifizieren zu können. Dazu zählt vor allem aber ipv6. Ich dachte, dass ich ipv4 unabhängig von ipv6 zum Laufen kriegen könnte, aber da mein Router und mein Anbiete nur DS Lite anbietet, kommei ich wohl nicht drum herum gleich beides auf einmal einzurichten, kann das sein?

So oder so ich bin in ner Sackgasse, wie gehe ich jetzt vor um das Setup zum Laufen zu kriegen?

Bucking_Horn · April 13, 2024, 9:25pm

Bitte lade ein Debug Log hoch und poste hier anschließend nur die Token-URL.
Das Token generierst Du über

pihole -d

wobei Du die Frage nach dem Upload bejahst, oder Du machst das über die Weboberfläche:
Tools > Generate Debug Log

senpai · April 13, 2024, 9:51pm

Hello @Bucking_Horn

Danke für deine rasche Antwort. Der Token lautet: iyvNPAko

Bucking_Horn · April 14, 2024, 10:34am

Die Empfehlungen zur FritzBox-Konfiguration stellt keine Anleitung mit zwingend vorzunehmenden Einstellungen dar, sondern eine Sammlung von möglichen Konfigurationsoptionen, aus denen die jeweils zu den eigenen Präferenzen passenden gewählt werden sollten.

Nur über Internet > Zugangsdaten legt man die von der FritzBox verwendeten Upstream-DNS-Server fest. In Pi-hole tauchen diese DNS-Anfragen dementsprechend unter der IP der FritzBox auf.

Mit den Einstellungen unter Heimnetz > Netzwerkeinstellungen konfiguriert man hingegen den lokalen DNS-Server, die die FritzBox an ihre Clients verteilt.

Letzteres wäre die zu bevorzugende Einstellung, da so DNS-Anfragen einzelnen Client-IP-Adressen zugeordnet werden können.

Dein Debug Log deutet darauf hin, dass Deine FB aktuell immer noch sich selbst als lokalen DNS-Server verteilt:

*** [ DIAGNOSING ]: contents of /etc

-rw-r--r-- 1 root root 37 Apr 12 21:56 /etc/dnsmasq.conf
-rw-r--r-- 1 root root 42 Apr 12 21:56 /etc/resolv.conf
   search fritz.box
   nameserver 192.168.178.1

Du solltest zunächst versuchen, Deine FB für Pi-hole als lokalen DNS-Server zu konfigurieren, ohne dass Du die Upstream-DNS-Server der FB auf Pi-hole setzt.

Deine 3. ist zu erwarten, da Dein Pi-hole-Rechner über eth0 ins Netzwerk eingebunden ist und somit natürlich über diese Schnittstelle sämtliche DNS-Anfragen eintrudeln.

Deine 4. könnte auch mit den Zeiteinstellungen des Browsers zusammenhängen (bzw. mit denen der Maschine, auf dem der Browser läuft).

Deine 1. und 2. sehen nach einem Netzwerk-Verbindungsproblem aus.
Ist Dein RPi direkt mit der FritzBox verbunden, oder sitzen dazwischen eventuell noch andere Netzwerkgeräte (z.B. ein Switch)?

Für wahrscheinlicher halte ich jedoch einen Firewall- oder Portkonflikt auf dem RPi.

Ausgeführt auf Deinem Pi-hole-RPi, was gibt folgendes Kommando zurück:

sudo ss -tulpn sport = 53

senpai · April 14, 2024, 2:26pm

Jap das stimmt. Ein anderer Browser zeigt die richtige Uhrzeit wieder an.

Das hatte ich bereits vermutet. Ist das so, weil pihole nicht der DHCP Server ist? Wenn ich den pihole zusätzlich als DHCP Server nutze, werde ich dann sehe welche Clients sich mit welchem Interface im LAN anmelden?

Interessante Schlussfolgerung. Du verweist auf den Eintrag in der /etc/resolv.conf. Ich hatte hierzu gelesen, dass man dem pihole host erstmal dazu bringen soll selbst pihole als DNS Server zu nutzen. Ich hatte dazu auch die resolv.conf geändert und statt die Gateway Adresse des Routers die IP des Hosts genutzt. Auf diese Weise habe ich auf dem Host (=Raspi) gänzlich den Internetzugang verloren. Mir war klar dass ich auf dem Holzweg war, also hatte ich das auch rückgängig gemacht. Wenn ich jetzt auf dem host ein drill Befehl ausführe gibt er mit als Server wieder die ipv4-Gateway Adresse des Routers an, (wie zu erwarten) wenn ich den gleichen Drill Befehl auf dem PC ausführe gibt er mir die ipv6-Gateway Adresse des Routers an. Das ist doch ein klarer Fall von pihole wird nicht wirklich als DNS Server genutzt.

Das hatte ich tatsächlich nur gemacht, weil ich wollte dass auch die Geräte in meinem Gastnetz den pihole nutzen. siehe hier... ich habe auch hier im Forum etliche Berichte darüber gelesen, dass davon abgeraten wird unter Internet/Zugangsdaten/DNS-Server die lokale IP des Raspi einzutragen. Nun aber was kann ich denn als Alternative eintragen. Ich möchte auf keinen Fall die des ISP nutzen, denn das würde doch eigentlich die Nutzung von pihole irgendwie 'relativieren'.. Soll ich bei ipv4 und ipv6 einfach mal die DNS Server von Quad9 eintragen? Dann könnte ich eigentlich auch gleich DoT wieder aktivieren. Das würde aber bedeuten, dass meine Geräte im Gastnetz dann aber auch die hier eingetragenen DNS Server nutzen und nicht mit dem pihole kommunizieren

Das ist auch wo ich noch gedanklich hintendiere, auch wenn ich eigentlich alle meine Bases gecovert habe..

Netid     State      Recv-Q     Send-Q          Local Address:Port           Peer Address:Port     Process                                   
udp       UNCONN     0          0                     0.0.0.0:53                  0.0.0.0:*         users:(("pihole-FTL",pid=6915,fd=4))     
udp       UNCONN     0          0                           *:53                        *:*         users:(("pihole-FTL",pid=6915,fd=6))     
tcp       LISTEN     0          32                    0.0.0.0:53                  0.0.0.0:*         users:(("pihole-FTL",pid=6915,fd=5))     
tcp       LISTEN     0          32                       [::]:53                     [::]:*         users:(("pihole-FTL",pid=6915,fd=7))

Ich hoffe ich habe jetzt nicht so viel durcheinander geschrieben, habe bestmöglichst versucht deine angesprochenen Punkte zu beantworten.

senpai · April 15, 2024, 3:20pm

Also, ich bin nochmals alle Einstellungen durchgeganen und die Firewall ist es nicht. Dort habe ich alle relevanten Ports (53,80,443,853) geöffnet und die sind auch ansprechbar, sonst würde ich ja kein Traffic auf dem pihole log sehen.

Was mir allerdings aufgefallen ist und da könnte doch was nicht ganz in Ordnung sein: Docker networking. Ich hab zwar den pihole Container auf 'network mode:host' gesetzt aber vielleicht spielt es dennoch eine Rolle.

In diesem Blog bin ich über die Info gestolpert, dass Docker nativ nicht ipv6 unterstützt und in der off. Doku von Docker habe ich auch diese Anleitung dazu gesehen.

Wenn ich aber die beschriebenen Anpassungen in der daemon.json file vornehme (in dem Fall nur mal versuchsweise ipv6:true) dann startet der docker daemon partout nicht. Bzw er startet dann failed er immerzu.

Keine Ahnung warum der daemon die Einstellung nicht feiert, aber gleich die wichtigste Frage vorneweg: Brauche ich die Einstellung überhaupt wenn ich den network mod auf host gesetzt habe? Den habe ich ja bewusst so gesetzt, damit ich irgendwann auch den DHCP Server über pihole laufen lassen kann. Außerdem habe ich so auch keine Portkonflikte weil ich ja die Einstellungen 1:1 vom Raspi nutzen kann. Da kein anderer Dienst drauf läuft außer pihole sollte das eigentlich ein Nobrainer sein, aber aus irgendeinem Grund steckt noch irgendwo der Wurm.

senpai · April 17, 2024, 12:44pm

Ich muss nochmal nachhaken, ich hoffe jemand hat noch eine Idee.

Ich auf jeden Fall Traffic auf meinem Pihole und ich sehe auch dass gewisse Domains geblockt werden. Allerdings gibt es noch etliche Lücken, hier einige konkrete Beispiele:

wenn ich den dig oder drill command nutze um zu überprüfen welcher DNS Server genau angesteuert wird sieht das bei mir so aus:

$ dig pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1974
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            266     IN      A       3.18.136.52

;; Query time: 0 msec
;; SERVER: fd00::e-t-c-#53(hier steht auch die ipv6 Adresse des Routers) (UDP)
;; WHEN: Wed Apr 17 13:00:44 CEST 2024
;; MSG SIZE  rcvd: 56

Beim drill Befehl wird mir der ipv4 time out error nicht gezeigt und er geht direkt über zur ipv6 Auflösung.

Wenn ich ein nslookup mache z.b....

$ nslookup api.branch.io
Server:         192.168.178.88
Address:        192.168.178.88#53

Name:   api.branch.io
Address: 0.0.0.0
Name:   api.branch.io
Address: ::

.. dann löst er wiederum schon über mein pihole auf und blockt die Adresse auch erfolgreich. Ich kann auch sehen dass gravity die Domain blockt (pihole tail log)

Wieso verhält sich der pihole so? Gibt es einen kausalen Zusammenhang wieso meine lokale ip ein solches Verhalten zeigt..

;; communications error to 192.168.178.88#53: timed out

aber parallel trotzdem mit dem nslookup Befehl funktioniert?

Bucking_Horn · April 17, 2024, 10:20pm

Die Ausgabe von sudo ss -tulpn sport = 53 sieht in Ordnung aus.

Das DNS-Protokoll ist indifferent gegenüber dem Transportprotokoll.
Ein DNS-Server wird also DNS-Anfragen unabhängig davon beantworten, ob diese über IPv4 oder IPv6 gestellt wurden.

Es ist daher grundsätzlich vollkommen ausreichend, wenn Deine Clients Pi-hole über IPv4 erreichen.

Problematisch ist hier oft, wenn der Router neben Pi-holes IPv4 seine eigene IPv6-Adresse als lokalen DNS-Server propagiert. IPv6-fähige Clients werden Pi-hole dann über den Router umgehen.

Deine Beobachtung ("fd00::e-t-c-#53(hier steht auch die ipv6 Adresse des Routers") zeigt, dass das bei Dir Fall ist.

Der Router sollte also so konfiguriert werden, dass er gar keine IPv6-Adresse oder eine Adresse des Pi-hole-Rechners als lokalen DNS-Server anbietet.
Ersteres hat den Vorteil, dass die Zuordnung von Hostnamen zu Client-IPv4-Adressen in Pi-holes Query Log problemlos funktioniert.
FritzBoxen unterstützen eine solche Konfiguration, siehe z.B. Unresolved ipv6 adress in my top list - #4 by Bucking_Horn.

Dies würde die Umgehung von Pi-hole verhindern; auf die von Dir per dig/drill/nslookup beobachteten Verbindungsschwierigkeiten sollte das allerdings keinen Einfluss haben.

Ich vermute hier eine andere Ursache:
Alpine Linux findet sich aktuell nicht in der Matrix der von Docker offiziell unterstützen Betriebssystem-Plattformen, und entsprechend stammt das in Alpine Linux verfügbare Docker-Paket aus dem community repository.

Wenn ich mich richtig erinnere, zeigte Dein (inzwischen abgelaufenes) Debug Log ein merkwürdiges Verhalten beim DHCP-Rundruf (Operation not permitted), dass ich bislang noch in keinem Docker Debug Log gesehen habe.

Zusammen mit Deiner fehlgeschlagenen IPv6-Konfiguration des Docker-Daemons könnte das auf Probleme bei der Docker-Umsetzung für Alpine hindeuten.

Hinzu kommt, dass Alpine musl statt glibc zur Namensauflösung verwendet, und sich mit musl zumindest bis kürzlich Probleme bei der DNS-Auflösung über TCP zeigen können (siehe z.B. Why I Will Never Use Alpine Linux Ever Again | Martin Heinz | Personal Website & Blog).

Um zu überprüfen, ob Deine Beobachtungen tatsächlich spezifisch für die Alpine Docker-Implementierung sind:
Hättest Du die Möglichkeit, Deinen Pi-hole Container testweise statt unter Alpine auf einem von Docker unterstützen BS laufen zu lassen?

senpai · April 18, 2024, 12:03pm

Das war nun auch mein letzter Ausweg raus aus der Misere. Ich bin schon beim Lesen über den verlinkten Thread gestolpert, und wollte es wenn wirklich gar nichts mehr geht auch umsetzen

..was auch der Hauptgrund für meine Frustration bei diesem Setup ist.

Nun zum Eingemachten:
Das habe ich dann gestern Nacht noch in der Tat versucht, nachdem ich dein Post noch gelesen habe.
Ich bin dabei genau wie in deinem Post hier vorgegangen:

Weitere Einstellungen die ich habe:
Der DNS Resolver im Browser (FF) ist ausgeschaltet. Ich bin über WLAN mit dem Heimnetz verbunden.

Ergebnis: Wenn ich DNSv6 und DHCP_v6 vollends ausschalte, funktioniert bei mir aber gar nichts mehr. Sprich, meine aufgerufenen Websiten werden nicht mehr aufgelöst. Mein Network Manager zeigt mir wie erwartet auch nicht mehr den primären IPv6-Namensserver des Routers an; der Eintrag verschwindet. Kurioserweise funktioniert auf dem Handy aber noch der Chat wie z.b. bei Whatsapp, Netflix auf dem TV(mit LAN Kabel verbunden) funktioniert ebenfalls, selbst nachdem ich dann den Raspi komplett stromlos gemacht habe und vom Netz genommen habe!!

Hier habe ich noch ein paar prompts:

auf dem Raspi:
$ doas ss -tulpn sport = 53
Netid     State      Recv-Q     Send-Q         Local Address:Port         Peer Address:Port    Process                                   
udp       UNCONN     0          0                    0.0.0.0:53                0.0.0.0:*        users:(("pihole-FTL",pid=3601,fd=4))     
udp       UNCONN     0          0                          *:53                      *:*        users:(("pihole-FTL",pid=3601,fd=6))     
tcp       LISTEN     0          32                   0.0.0.0:53                0.0.0.0:*        users:(("pihole-FTL",pid=3601,fd=5))     
tcp       LISTEN     0          32                      [::]:53                   [::]:*        users:(("pihole-FTL",pid=3601,fd=7))  

auf dem PC:

$ nslookup pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; no servers could be reached


$ host pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; no servers could be reached


$ dig pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> pi-hole.net
;; global options: +cmd
;; no servers could be reached


$ dig google.com @8.8.8.8 +short
142.250.186.78


$ nslookup api.branch.io
Server:         192.168.178.88
Address:        192.168.178.88#53

Name:   api.branch.io
Address: 0.0.0.0
Name:   api.branch.io
Address: ::

Gerade der letzte Befehl beweist, das er ja immer noch blockieren tut, nur fehlt mir jetzt der Zugang zum Internet...An dieser Stelle könnte ich noch versuchen entweder a. noch weiter in der FB herumspielen oder b. vielleicht mal versuchen den pihole als DHCP Server einzustellen. Ich weiss aber im Moment nicht wo ich in der FB ein Haken zuviel ist oder zu wenig habe...von daher bewege ich mich immer noch im Kreis.
.
.
.
.

Ja das war schon extrem seltsam, du meinst sicherlich das hier:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   Error: Could not send DHCPDISCOVER to 255.255.255.255@eth0: Operation not permitted
   Error: Could not send DHCPDISCOVER to 255.255.255.255@cw-5vh13968e5w4: Operation not permitted
   Error: Could not send DHCPDISCOVER to 255.255.255.255@docker0: Operation not permitted

In dem Zusammenhang habe ich auf meinem PC ein weiteres bisher noch ungeklärtes Verhalten meines Routers beobacht, wo der Router fortlaufend ein mutlicast Signal verschickt (broadcastet). Ein Blick auf die Firewall Logs bestätigt mir, dass es nur im Heimnetz passiert. Das war nicht immer so, vielleicht ein Bug seitdem letzten FritzOS Update. Auch wenn das jetzt OT ist, vielleicht könnte es den DHCP Rundruf in den richtigen Kontext setzen? In dem Fall wäre es ja ein Router Problem und kein Docker-spezifisches Problem.

Das stimmt, es ist tatsächlich wie du beschrieben hast ein Community Package, das an und für sich sehr gut implementiert ist. Insgesamt ist ja Alpine auch ein sehr niches Projekt, weshalb ich da jetzt auch ernsthaft drüber nachdenke zurück zu einem gewöhnlichen Raspi OS zu wechseln. Die verlinkten Blogartikel zum Umgang von musl mit DNS hat mir das auch nochmal vor Augen geführt. Ich nutze natürlich kein Kubernetes und brauch es auch nicht. Es zeigt aber dass gerade in diesem Bereich des Internets und der Linux Entwicklung sehr viel Bewegung herrscht und damit gestern noch funktionierende Workarounds mit den neuesten Updates schon wieder überholt sind. Das ist sehr ernüchternd. Das Fazit aus dem Ganzen hier ist schließlich auch der dass die Kombination aus Dual Stack LITE, FritzBox, musl libraries und Docker Networking nicht sehr gut miteinander harmoniert! (und schon etliche Stunden Troubleshooting dabei drauf gegangen sind.) Deswegen tendiere ich bei der Frage...

..eher zu einem verhaltenen Nein, weil ich Docker nur in der alpinen Umgebung laufen habe und ich wenn ip4_only nicht vernünfitig zum Laufen bekomm, ein komplett neues Setup mit RaspiOS ohne Docker re-installieren werde. Wenn ich etwas mehr von Netzwerktechnik und ihre Fallstricke (v.a.m.B.a. ipv6) verstehen würde, könnte ich das sogar mal als side project angehen, aber im Moment fehlt mir die Geduld und Zeit dafür. Ich bin gerade nur darauf fokussiert eine stabile Pi-Hole Instanz aufzustellen..egal mit welchem Setup. Ich hoffe du hast dafür Verständnis.

Bucking_Horn · April 19, 2024, 8:44am

Auf welche Firewall bezieht sich das?
Auf die auf dem Pi-hole-Host, die auf dem PC, oder verwendest Du einen dedizierten Firewall-Rechner?

Um einzugrenzen, wo es bei IPv4 hakt, teste zunächst mal nur mit dig.

dig -4 flurry.com @192.168.178.88

dig -4 pi-hole.net @192.168.178.88

Wenn Du diese jeweils auf dem PC und auf dem Pi-hole-Rechner ausführst, tauchen die DNS-Anfragen dazu in Pi-holes Query Log auf?

senpai · April 19, 2024, 11:54pm

Das bezog sich auf UFW, die auf dem raspi läuft, der den pihole container hostet.

Ja beide Queries tauchen im Log auf, sowohl auf dem PC als auch auf dem raspi. Beachte bitte dass die folgenden Angaben auf einem (halb-)funktionieren Setup funktionieren, also wo ich in der FritzBox DNSv6 wieder aktivierert habe.

Der Output auf dem PC:

$ dig -4 flurry.com @192.168.178.88

; <<>> DiG 9.18.24-1-Debian <<>> -4 flurry.com @192.168.178.88
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21173
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 3 msec
;; SERVER: 192.168.178.88#53(192.168.178.88) (UDP)
;; WHEN: Sat Apr 20 01:29:03 CEST 2024
;; MSG SIZE  rcvd: 55

$ dig -4 pi-hole.net @192.168.178.88
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> -4 pi-hole.net @192.168.178.88
;; global options: +cmd
;; no servers could be reached

Hier ein Screenshot vom Log:
digitalcourage ist mein im pihole eingetragener Upstream DNS Server (custom DNS) !

.
.
.

Der Output auf dem Raspi:

$ dig -4 flurry.com @192.168.178.88

; <<>> DiG 9.18.24 <<>> -4 flurry.com @192.168.178.88
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19101
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 192.168.178.88#53(192.168.178.88) (UDP)
;; WHEN: Sat Apr 20 01:16:27 CEST 2024
;; MSG SIZE  rcvd: 55

$ dig -4 pi-hole.net @192.168.178.88
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out

; <<>> DiG 9.18.24 <<>> -4 pi-hole.net @192.168.178.88
;; global options: +cmd
;; no servers could be reached

So sieht es im Log aus:

Mir ist auch schon voher aufgefallen, dass der Raspi selbst noch nicht seinen eigenen pihole nutzt, sondern immer noch die unter /etc/resolve.conf gespeicherte Gateway Adresse des routers. Wenn man nämlich die @IP Adresse weglässt nimmt er ja bekanntlich die Standard DNS Adresse des hosts:

$ dig -4 pi-hole.net

; <<>> DiG 9.18.24 <<>> -4 pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60966
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            276     IN      A       3.18.136.52

;; Query time: 803 msec
;; SERVER: 192.168.178.1#53(192.168.178.1) (UDP)
;; WHEN: Sat Apr 20 01:20:26 CEST 2024
;; MSG SIZE  rcvd: 56

cat /etc/resolv.conf
search fritz.box
nameserver 192.168.178.1

Meine bisherigen Versuche die Datei umzuschreiben und dort die loopback Adresse zu ergänzen sind gescheitert, so dass ich wieder und immer wieder den Zugang zum Internet verloren habe. Keine Ahnung welchen Denkfehler ich da hatte, ich hab das letztlich vertagt, weil es ja dann trotzdem irgendwie geklappt hat. Ingesamt eher ein unbefriedigendes Ergebnis, aber seis nun drum. Meinst du, dass es dennoch damit zusammenhängen könnte?

In Summe ist es doch eine recht verzwickte Sache, das Setup ist zu komplex, das Troubleshooting darf nicht so dermaßen zeitaufwändig sein. Irgendwie funktioniert es, aber irgendwie auch nicht, ich weiss nicht wie man den Terminal Output korrekt interpretieren soll. Meine HTTPS Anfragen über den Broser werden, auch wenn sehr lahm, trotzdem aufgelöst, landern auch im Query Log, aber ich kann nicht ganz sicher ermitteln welchen Weg (ipv4/6) sie gehen.. Die Ergebnisse aus dem Terminal und dem Query Log scheinen sich zu widersprechen..so oder so werde ich wohl doch mal ein anderes Setup ausprobieren mit weniger Fallstricken. Siehe Alpine Diskussion weiter oben.

Wenn du noch ne Idee hast, gerne, ich lass den Raspi im Moment fürs Erste so weiter laufen, werde aber den klassichen non-Docker Weg ausprobieren und das mal ganz geschmeidig neu und clean draufbügeln.

Bucking_Horn · April 20, 2024, 7:20am

Gut, dass sie auftauchen.
Damit sind Firewall- und Container-Probleme schon auszuschließen.

Das hat keinen EInfluss auf die abgesetzten dig-Kommandos, da über -4 die ausschließliche Verwendung von IPv4 erzwungen wird.

Die Information zu N/A wäre schon eingangs nützlich gewesen.

N/A bedeutet, dass Pi-hole bislang keine Antwort des Upstreams erhalten hat, in diesem Fall sowohl für die ursprüngliche als auch für die wiederholte Anfrage.
Die fehlenden Antworten führen letztlich zum Time-Out (und dieser wiederum dazu, dass ein normales dig die Anfrage über IPv6 wiederholen würde).

Die DNS-Server von DigitalCourage sind leider bisweilen überlastet, so dass hier DNS-Anfragen unbeantwortet bleiben können.

Deine Beobachtungen wären durch diese Überlastung des Upstreams erklärbar.
Wiederholte Anfragen führen früher oder später zum Erfolg, wobei es Zufall war, dass die Anfragen manchmal über IPv6 (dig nach IPv4-time-out) und manchmal über IPv4 (späteres nslookup) funktioniert haben.

Du solltest einen anderen Upstream-DNS-Server konfigurieren.

senpai · April 20, 2024, 3:00pm

Tatsächlich, ist mir das selbst erst gestern so richtig aufgefallen, als ich die Screenshots gemacht habe. Davor hatte ich das not available wirklich übersehen bzw nicht richtig eingeordnet, dabei hast du Recht, ganz unerheblich ist die Spalte Reply ja nicht.

Ja, stimmt! Sieh mal an, der Time Out lag ja echt am nicht antwortenden Upstream DNS Server. Wenn ich den ändere, funktioniert die Domain Auflösung wieder wunderbar und auch der Lag ist verschwunden! Ein bisschen verzögert ist es immer noch, aber nicht so extrem wie vorher.

Auch das stimmt wohl, die -4 Option habe ich übersehen.

Ich hab nun in der Folge DNSv6 in der FB wieder ausgeschaltet (genauso wie im anderen Thread) und es funktioniert bis hierhin. Das ist schonmal ein erstes positives Feedback. Zum Test habe ich den Raspi vom Netz genommen und mal festgestellt, dass er sich auf keins der Geräte mit dem Internet verbinden kann. D.h. es erfolgt auch kein ipv6 Sideloading mehr. Das ist perfekt für jetzt. Damit kann ich arbeiten

Was mich aber jetzt natürlich schon etwas wundert ist der Umstand, dass die DNS Server von Digital Courage (DC) nicht erreichbar sind, denn in ihrer Statusseite ist der DNS Server scheinbar up wie war das gleich nochmal pihole unterstützt DoT aber kein DoH..?

Wenn ich jetzt z.b. DNS Forge oder DNS Watch als custom Upstream Server wähle und dann dnsleaktest.com aufrufe, dann erscheinen mir alle DNS Server die ich im pihole ausgewählt habe, bis auf dem von DC..

In meinem Heimnetz wird aber immer der DNS Server genommen, der als erstes antwortet, sprich der am responsivsten.