pihole (hostnamen) und unbound probleme (laden von websites)

[Chris88]

liebe community,
ich weiß, dass dieses Thema hier schon oft diskutiert wurde, aber nach dem Lesen unzähliger Threads habe ich das Problem noch nicht lösen können.

Ich hoffe, dass ich hier alle relevanten Informationen aufgeführt habe, damit ihr euch ein möglichst gutes Bild machen könnt.

Pihole wurde als Container über Portainer installiert und anschließend mit traefik verbunden (statisch)
router:
to-pihole:
Regel: „Host(pihole.xxxx.XXXX.eu)“
tls:
certResolver: cloudflare
dienst: pihole
Dienste:
pihole:
loadBalancer:
server:
- url: http://10.75.0.100

über mein Setup:
Netzwerk 10.75.0.0/23
Fritzbox: 10.75.0.1
Synology NAS: 10.75.0.2 (mit Synology DNS-Server)
PiHole (im Portainer): 10.75.0.100
Ungebunden (im Container): 10.75.0.101
DHCP-Server (über Fritzbox) 10.75.1.1 - 10.75.1.254

Die DNS-Anfrage läuft derzeit wie folgt ab:

Client -> Pihole -> Synology DNS Server -> Ungebunden

Die Clients erhalten das Pihole als DNS-Server von der FritzBox über DHCP
In Pihole ist eine bedingte Weiterleitung eingerichtet (Lokales Netz: 10.75.0.0/23 ; IP-Adresse Ihres DHCP-Servers: 10.75.0.1 ; Lokaler Domainname: fritz.box)
Upstream in Pihole ist die Synology 10.75.0.2
Der Upstream in der Fritzbox ist die Synology 10.75.0.2
Synology DNS Server Limit Quell-IP-Dienst: 10.75.0.100 und 10.75.0.2
Synology DNS Server Upstream 10.75.0.101 (Ungebunden)
Es gibt auch kein ipv6 in meinem gesamten Netzwerk. Es ist in der Fritzbox und in der Synology ausgeschaltet.

Probleme:

• Es werden keine Hostnamen in meinem Pihole angezeigt.

• als kleine Zusatzfrage (auch wenn sie hier nicht ganz reinpasst): hat jemand eine Idee, warum es immer wieder vorkommt, dass einige Webseiten nicht richtig geladen werden können (müssen mehrmals neu geladen werden, dauert oft bis zu 30 sec, werden beim ersten Mal nicht richtig angezeigt/aufgebaut), wenn ich unbound als Upstream verwende. wenn ich einen öffentlichen DNS wie cloudflare als zweiten Upstream einstelle, gibt es dieses Problem nicht.

Debug-Token:
https://tricorder.pi-hole.net/aWkYqQj3/

 

[the other]

Moinsen,
Bei den Angaben zu dhcp ist dir sicherlich nur hier der Fehler unterlaufen...?
Da sind einem ein Netzwerk mit 10.75.0.xxx und einmal mit 10.75.1.xxx in der Beschreibung.

Warum soviel DNS treibende Geräte (pihole, Synology, Fritzbox)?
Sind die hostname denn in pihole angelegt?
Wird denn auch pihole befragt (oder einer der anderen stattdessen)?

 

[Chris88]

Moinsen,
Bei den Angaben zu dhcp ist dir sicherlich nur hier der Fehler unterlaufen...?
Da sind einem ein Netzwerk mit 10.75.0.xxx und einmal mit 10.75.1.xxx in der Beschreibung.

Warum soviel DNS treibende Geräte (pihole, Synology, Fritzbox)?
Sind die hostname denn in pihole angelegt?
Wird denn auch pihole befragt (oder einer der anderen stattdessen)?

Hey "the other"

nein da ist kein Fehler. ist ja ein 10.75.0.0/23 (255.255.254.0) Netzwerk.

Ja das ist eine gute Frage mit den DNS treibenden Geräten. einerseits hat es sich so ergeben (Fritzbox brauch ich ja. Synology DNS Server brauch ich wegen den ganzen CNAME einrägen für meine Container und Programme auf der Syno. Pihole als werbefilter - so zumindest die idee).

Bin aber für alle alternativen offen

Hostnamen sind in pihole nicht angelegt. deshalb ja das conditional forwarding. die soll er sich doch von der fritzbox holen. tut er aber nicht.

 

[blurrrr]

Hostnamen sind in pihole nicht angelegt. deshalb ja das conditional forwarding. die soll er sich doch von der fritzbox holen. tut er aber nicht.

Warum ist dann die Syno noch im Spiel? Also wenn ich das richtig verstanden habe:

Primärer DNS im Netzwerk ist die Pi-Hole-Installation, welche an die Clients via DHCP vergeben wird. Soweit so gut. Pi-Hole sollte dann entweder a) als Upstream die Fritz!Box nutzen, oder b) etwas anderes (z.B. öffentliche DNS-Server), dann aber mit einem conditional forwarding auf die Fritz!Box für die Domain "fritz.box".

Die Syno kann auch als DNS dienen (habe ich z.B. privat laufen) und auch eigene Zonen bedienen. Je nach dort angelegten Zonen, bräuchte es auf dem Pi-Hole wieder entsprechende bedingte Weiterleitungen. Wenn die Syno sowieso als authoritativer Server für div. interne Zonen genutzt wird, könnte man allerdings auch auf die Fritz!Box als DNS verzichten.

Dieser Aufbau hier...

Client -> Pihole -> Synology DNS Server -> Ungebunden

... macht so eher weniger Sinn. Richte lieber entsprechende "bedingte" Weiterleitungen für die entsprechenden Domains auf dem Pi-Hole ein. Du kannst ja alles nutzen, aber verkette nicht alles miteinander (davon ab, erhöht sowas auch die Antwortzeiten der DNS-Anfragen).

Also kurzum:

Client -> Pi-Hole -> Upstream -> public DNS
                  -> CF -> fritz.box -> <Fritz!Box>
                  -> CF -> domainA -> DNS X
                  -> CF -> domainB -> DNS Y
                  -> CF -> domainC -> DNS Z

Wenn Pi-Hole und Unbound im Container auf der Syno laufen... ich bin mir da grade nicht 100%ig sicher, aber ich "meine", dass die Container nicht auf den Host zugreifen können, auf welchem sie laufen.

Davon ab... 1) Pi-Hole (Resolver mit Cache), 2) Syno-DNS (Bind, Nameserver), 3) Fritz!Box (Resolver mit Cache), 4) Unbound (Resolver mit Cache). Einmal kurz lesen: Nameserver + Resolver.

Nochmal kurz als Abriss: Resolver kümmern sich um die Auflösung (und fragen woanders nach, oder haben ihren Cache manipuliert und liefern daraus einfach Antworten), Nameserver verwalten komplette DNS-Zonen und sind die "eigentlichen" Ansprechpartner, wenn es um die konkrete Auflösung von DNS-Records geht.

Unbound macht da für mich erstmal so gar keinen Sinn, da Du mit Pi-Hole schon einen Resolver hast (welcher in der Lage ist, seinen Cache zu manipulieren und daher auch "Hostnamen" im Cache überschreiben/anlegen kann). Unbound macht derweil irgendwo das gleiche (nur ohne Werbefilter). Der Resolver auf der Fritz!Box ist halt einfach da und da kann man auch nix gegen machen. Die Syno hingegen stellt mit Bind9 als einziger Host einen vollwertigen Nameserver zur Verfügung. Also ich würde erstmal a) rausschmeissen was nicht benötigt wird und b) die Abfrage-Struktur entsprechend optimieren bzw. auf die tatsächlichen Gegebenheiten anpassen.

Für Dich würde das aus meiner Sicht (kann man natürlich halten wie man möchte) folgendes bedeuten:

Client -> Pi-Hole -> Upstream -> public DNS
                  -> CF -> fritz.box -> <Fritz!Box>
                  -> CF -> domainA -> <Syno>
                  -> CF -> domainB -> <Syno>
                  -> CF -> domainC -> <Syno>

Damit wäre das Thema für mich durch... ausser natürlich, Du hast noch irgendwelche Sonderlocken, von denen hier niemand etwas weiss

P.S.: Was das hier angeht...

Fritzbox brauch ich ja.

... je nachdem, ich nutze meine Fritz!Box in diesem Konstrukt garnicht. Die Fritz!Box stellt hier lediglich den Internetzugang bereit und dient - für nicht anderweitig angegebene Zonen - lediglich als Resolver in Richtung Aussenwelt.

 

[Chris88]

Hallo blurrrr
erstmal vielen Dank für deine ausführliche Reaktion auf mein Problem
ein paar Nachfragen und Antworten auf deine Fragen

Die Syno kann auch als DNS dienen (habe ich z.B. privat laufen) und auch eigene Zonen bedienen. Je nach dort angelegten Zonen, bräuchte es auf dem Pi-Hole wieder entsprechende bedingte Weiterleitungen. Wenn die Syno sowieso als authoritativer Server für div. interne Zonen genutzt wird, könnte man allerdings auch auf die Fritz!Box als DNS verzichten.

wenn ich dich richtig verstanden habe, dan hab ich das ja so. in der fritzbox ist als DNS Server (unter DHCP -> lokaler DNS Server) der pihole eingetragen Also die Clients bekommen den Pihole als DNS. dieser gibt alles an die Syno weiter die dann (aktuell noch über unbound... aber das kann ich ja auch mal weglassen...) in die große weite welt hinaus geht.
was meinst du aber mit:

Je nach dort angelegten Zonen, bräuchte es auf dem Pi-Hole wieder entsprechende bedingte Weiterleitungen.

zonen der Syno im Anhang.

kannst du mir das eventuell näher erklären wie ich das mache?

Richte lieber entsprechende "bedingte" Weiterleitungen für die entsprechenden Domains auf dem Pi-Hole ein. Du kannst ja alles nutzen, aber verkette nicht alles miteinander

Davon ab... 1) Pi-Hole (Resolver mit Cache), 2) Syno-DNS (Bind, Nameserver), 3) Fritz!Box (Resolver mit Cache), 4) Unbound (Resolver mit Cache).

das leuchtet mir absolut ein. klingt als ob ich da nen echten mist zusammengebaut hab, der nur alles unnötig verlangsamt.


um die idee hinter meinen Gedanken zu verstehen (vielleicht hab ich aber auch was falsch verstanden) kannst du vielleicht mal nen kurzen blick in diese youtube videos machen. danach hab ich mich gerichtet. kann nur leider keinen link posten aber du findest die wichtigsten 3 (die vielleicht erklären was ich da versucht hab zu bauen) ganz easy mit:

• Synology DNS Server einrichten - Teil 1 von Navigio
• Synology DNS Server einrichten - Teil 2 von Navigio
• Pi-Hole auf Synology - die beste Methode 2023 von Navigio
• Traefik Reverse Proxy - Version 3.0 von Navigio
• CrowdSec + Traefik von Navigio

sorry dass ich dich damit quäle... aber ich denke das erklärt das vielleicht am besten. hab mittlerweile das Gefühl, dass ich da vielleicht etwas ganz falsch verstanden habe... denn das
Client -> Pi-Hole -> Upstream -> public DNS
-> CF -> fritz.box -> <Fritz!Box>
-> CF -> domainA -> <Syno>
-> CF -> domainB -> <Syno>
-> CF -> domainC -> <Syno>
klingt für mich sehr logisch. aber glaub ich hab da noch nen knoten im kopf.


Danke die au jeden Fall schon mal für deine Hilfe.

 

[blurrrr]

Sorry, aber ich schaue mir keine Youtube-Videos an... Mich nerven auch Anfragen in Richtung "Ich hab das wie in Video XY gemacht, nu geht nix, was nun?" inkl. Verlinkung eines Videos, welches ellenlang ist... sorry, mit sowas braucht man mir echt nicht kommen. Ich bin eher ein Freund von "lesen, lernen, verstehen, machen" anstatt einfach nur blind irgendwelchen Videos zu folgen (die mitunter auch schlichtweg mal "outdated" sein können). Also nix für ungut, aber... keine Videos für mich

Wenn wir uns mal abwenden () vom typischen "Video 1 geguckt... HABEN WILL!... Video 2 geguckt... AUCH HABEN WILL!!.... Video 3 geguckt... HABEN HABEN HABEN!!!".... vergiss das erstmal ALLES und fang nochmal ganz frisch von vorne an:

Was "genau" willst Du eigentlich?

Gemeint ist damit jetzt nicht der Einsatz von Produkt X oder Produkt Y. Gemeint ist damit eine Funktionalität, welche Dir einen "Mehrwert" in Deinem heimischen Netz (oder auch anderswo, wie auch immer...) bringt. So wie ich das von Dir bisher gelesen und verstanden habe, wären das 2 Dinge:

1) Werbefilter
2) Authoritativer Nameserver (zwecks eigenen internen DNS-Zonen)

Den ersten Punkt hast Du schon direkt mit z.B. Pi-Hole erledigt (oder einen der vielen anderen Werbeblocker wie Adguard, etc.). Dieser wird als DNS-Resolver an die Clients verteilt. Kannste einen Haken hinter machen, ist erledigt.

Was nun noch bleibt ist ein Nameserver für die eigenen DNS-Zonen. Da hast Du eh schon den Nameserver der Syno laufen, kannst Du also auch einen Haken hinter machen. Der Umstand mit der Fritz!Box ist halt wie er ist, ebenfalls Resolver mit manipulierendem Cache für die Domain "fritz.box". Die anderen internen Zonen liegen auf dem Syno-DNS. Somit bleiben wir den primären Resolver (Pi-Hole) genau 3 Richtungen über:

1) fritz.box -> Fritz!Box
2) andere interne DNS-Zonen -> Syno
3) alles andere -> public DNS

Beim 3. Punkt könntest Du aber auch alternativ die Syno, oder die Fritz!Box nutzen, welche beide dann wiederum an irgendwas weiterleiten. Je nach Provider und genutzten Provider-Diensten kann es aber auch gut sein, dass nur die internen DNS-Server der Provider in der Lage sind, bestimmte (benötigte!) Dinge aufzulösen.

So kann es z.B. sein, dass dann einfach div. Dinge (VoIP, IPTV, etc.) nicht mehr funktionieren, wenn man einen DNS-Server ausserhalb des Providernetzes nach Dingen befragt, weil mitunter schlichtweg andere Antworten kommen würden, als von den internen DNS-Servern des Providers. Auf der anderen Seite sperren Provider mitunter aber auch auf Anordnung div. Dinge. Möchte man sowas nicht, muss man zwangsläufig einen öffentlichen DNS-Server nutzen, welcher diesen Einschränkungen nicht unterliegt.

Hier bei mir geht es schlussendlich einfach zur Fritz!Box, die fragt bei den DNS-Servern von meinem Provider nach und gut ist. Syno-DNS habe ich hier auch laufen mit DNS-Zonentransfers von div. Stellen, die Syno ist für einen Teil der Clients der primäre DNS. Weiss die Syno nicht weiter, geht es direkt an die Fritz!Box und "interessiert mich nicht mehr". Clients aus anderen Netzen dürfen maximal die Firewall (hinter der Fritz!Box) befragen und haben auch keinerlei Zugriff auf das Fritz!Box-Netzwerk. Das sieht in Summe ungefähr so aus:

Client -> Syno --Firewall--> Fritz!Box
+
Client -> Firewall -> Fritz!Box

Letzteres halt, weil die sonstigen Clients halt nicht direkt auf die Fritz!Box zugreifen dürfen (von der Firewall unterbunden). Bei Dir ist keine Firewall im Spiel, also auch kein Problem diesbezüglich. Es sei nur gesagt - und das auch für die Zukunft - "mehr" ist nicht zwingend "besser".

Zum Schluss nochmal jener welcher hier:

Es werden keine Hostnamen in meinem Pihole angezeigt.

DNS funktioniert nicht nur vorwärts, sondern auch rückwärts (Reverse-DNS). Dazu benötigt ein - zugeordneter "Nameserver" (nicht Resolver!) - auch eine entsprechende Reverse-Zone (in-addr.arpa) inkl. entsprechenden PTR-Records. Dazu kannst Du mal hier reinschauen: Wikipedia - Reverse DNS. So ein Client rückt nämlich nicht mit seinem Hostnamen beim Pi-Hole an, sondern mit seiner IP-Adresse. Der Pi-Hole kann natürlich versuchen (wird ggf. auch versuchen), diese IP-Adresse in einen Hostnamen umzuwandeln. Die entscheidene Frage ist allerdings: "Wer" - in Deinem Konstrukt - weiss über die Zuordnung zwischen IP und Hostname Bescheid und ist in der Lage, bei Anfrage auch eine entsprechende Antwort zu liefern? Dazu die Frage: Wen fragt denn Dein Pi-Hole, wenn er selbst etwas auflösen möchte?

Vielleicht ist es nur bei mir so, aber wenn ich die Fritz!Box nach einer IP frage, z.B. so...

nslookup fritz.box <Fritz!Box-IP>

...antwortet mir die Fritz!Box halt mit a) dem Namen und b) der dazugehörigen IP. Frage ich die Fritz!Box nach ihrer IP via...

nslookup <Fritz!Box-IP> <Fritz!Box-IP>

...antwortet mir die Fritz!Box wieder mit a) dem Namen und b) der entsprechenden IP. Bis hierhin, alles tutti... Was die Fritz!Box (bei mir jedenfalls) nicht macht ist folgendes: Ich habe ja nun hinter der Fritz!Box eine Firewall, welche WAN-seitig auch eine IP im Fritz!Box-Netz hat (übrigens das einzige Gerät, welches sonst noch im Fritz!Box-Netz ist). Dieses Gerät hat die IP mit der Endung .2. Frage ich die Fritz!Box nun nach dieser IP via...

nslookup <IP von einem anderen Gerät> <Fritz!Box-IP>

... kann mir die Fritz!Box diese Frage nicht beantworten. Insofern solltest Du einmal testen, ob Deine Fritz!Box Dir für...

nslookup <Hostname eines Gerätes im Fritz!Box-Netz>.fritz.box

....auch eine entsprechende Antwort liefern kann. Falls das nicht der Fall sein sollte, kann man also direkt vergessen, dass man die Fritz!Box zwecks Reverse-Lookup nutzen kann. Da hilft dann nur noch, eine entsprechende Reverse-Zone auf der Syno anzulegen und die gewünschten Einträge händisch vorzunehmen.

Alternativ müsste man den DHCP-Dienst umziehen, denn es gibt auch die Möglichkeit, dass man DHCP und DNS miteinander verbinden kann, so dass die Kombi Hostname <-> IP direkt im DNS registriert (und aktualisiert) werden kann. Das ist aber ein weitaus weniger triviales Thema und bedingt auch den Einsatz eines anderweitigen DHCP-Dienstes. Es sei hier nur zumindestens mal "erwähnt". Kann man dann entweder alles selber bauen, oder ggf. ein anderweitiges "fertiges" Produkt nutzen (so eine OPNsense-Firewall kann sowas z.B. auch). Für "ein bisschen" Zuhause wäre das - meiner Meinung nach - aber schon ziemlich mit Kanonen auf Spatzen geschossen, ich habe hier sowas auch nicht laufen und vermisse sowas auch nicht

 

[Chris88]

jetzt bin ich echt etwas verwirrt.... alles was du oben schreibst, hab ich doch so konfiguriert und zu beginn so beschrieben (lässt man jetzt mal den unbound als finalen upstream der syno raus).

fritzbox ist dhcp server und verteilt als dns server den pihole (10.75.0.100). und die syno macht interne auflösung der syno/container dienst.

also: client -> pihole -> syno -> unbound (den könnte ich aber ersetzen durch die fritzbox wenn das schaluer ist!?).

In der Fitzbox hab ich als upstream DNS jetzt die Syno eingetragen (also wenn jemand die firtzbox als dns angibt: fritzbox -> syno -> weite welt), kann ich aber auch mit den öffentlichen bestücken. dann wird halt nur nicht aufgelöst wenn im client die fritbox als dns (fäschlicherweise) eingetragen ist und interne adressen aufgelöst werden sollen. oder hab ich nen denkfehler?

anyway... also theoretisch sollte ja alles so verknüpft sein wie von dir oben beschrieben.

aber wie schon gesagt im pihole zeigt es keine hostnamen an.

hab jetzt all deine beschriebenen lookups gemacht.
resultat:

nslookup fritz.box <Fritz!Box-IP>

funktioniert

nslookup <Fritz!Box-IP> <Fritz!Box-IP>

funktioniert

nslookup <IP von einem anderen Gerät> <Fritz!Box-IP>

funktioniert nicht

nslookup <Hostname eines Gerätes im Fritz!Box-Netz>.fritz.box

funkioniert

 

[the other]

Moinsen,
jau, da habe ich die /23 wohl überlesen und mich gewundert...danke für die Klarstellung.

Ich hatte das (damals) bei mir ganz einfach gemacht:
1. Pihole auf Raspi (plus unbound!) für
a) Werbeblock auf DNS Basis und
b) DNS Resolver (unbound dann als Weiterleitung zu den auth DNS Servern).
2. Alle hosts in Pihole mit ihren Angaben (IP / hostname) eingetragen.
3. Fertig.

Somit fragten die Clients dann alle beim Pihole nach DNS Infos. Diese beantwortete die lokalen bekannten Dinge (waren dort ja fürs LAN hinterlegt). Alles andere (im Internet) an DNS Fragen wurde dann entweder via Cache erledigt oder aber weitergeleitet an unbound und von dort...ins Netz gefragt.
Die Fritzbox machte da dann nix mehr mit DNS...

 

[Chris88]

ja aber laut unzähligen anleitungen (auch der offiziellen pihole dokumentation) sollte es ja möglich sein, dass pihole automatisch die client hostnamen anzeigt, ohne dass ich extra alle host angaben eintragen muss.
Hostnamen in Pi-hole statt IP-Addressen - Conditional forwardin

das mit unbound klingt logisch. mein problem bei unbound ist nur, dass manche seiten sehr langsam laden (muss ise 3, 4 mal neu aktualisieren (dauert bis zu 30sec) bis sie überhaupt laden, oder muss sie ein zweites mal aktualisieren bis sie korrekt die Seite aufbauen. Wie gesagt, nicht bei allen aufrufen.... aber nervt halt.

Die syno brauche ich für interne zonen aufzulösen.

 

[Stationary]

Ich hatte mit pihole im Container und unbound im Container nie Glück. Ich habe das zwar damals auf Raspi4 bzw. Raspi5 versucht und nicht auf der Diskstation, habe es aber nie hinbekommen. Pihole im Container kein Problem, aber sowie auch unbound containerisiert war und pihole darauf zugreifen sollte - habe ich nicht zum Laufen gekriegt. Deshalb läuft pihole/unbound bei mir direkt im RasPiOS und nur der Rest der da läuft ist in Containern verpackt. Vielleicht wäre ein RasPi für Dich eine Alternative?

 

[the other]

Moinsen,
ja, sollte durchaus möglich sein nach Anleitung, dass Pihole dann (Zitat aus der Anleitung!) "versucht" die Fritzbox / den DNS Resolver zu befragen.
Und wie wir alle wissen: versuchen ist nicht erledigen...
Das von dir geschilderte Problem mit unbound hatte ich Anfangs auch immer mal, allerdings normalisierte sich das dann auch mit der Zeit (Cache).
Heute nutze ich kein pihole mehr. Alles zum Thema DHCP, DNS Resolver und Werbeblocker läuft zentral über die bereits von @blurrrr erwähnte pfsense, die im LAN als Router arbeitet. Daher kann ich es nicht nachstellen aktuell.
Auch hier gibt es Tage, an denen vereinzelt ein Seitenaufbau etwas dauert. Andere Seiten zur selben Zeit aber fluppig laden...daher kann die Ursache ja auch durchaus mal ganz jenseits von unbound und DNS Auflösung liegen...
Die (wenigen) Container, die hier auf der Synology laufen sind wie folgt zu erreichen:
Container haben die IP des NAS mit ihren jeweiligen Ports. Auf dem NAS läuft nix für DNS, dafür aber dort der Reverse Proxy. Damit habe ich dann das aus dem Weg. Im DNS Resolver steht dann eben "paperless" = IPv4 des NAS. Gebe ich dann im Browser paperless.domain ein, löst der Resolver auf, es erfolgt die Verbindung zum NAS (Proxy), dort die Zuordnung zum richtigen Port (für paperless)...Houston, we have contact!

edit: ich selber würde Dienste, die für das gesamte Netzwerk (LAN) supderduper wichtig sind, niemals nicht in einen Container auf der Syno packen...geht da irgendwas in deren komplexen System über die Reling, dann fällt mir ggf. alles im Netzwerk aus. Doof das! Aber auch das ist immer eine persönliche Entscheidung.

 

[blurrrr]

Das Problem wird bei den Container-Dingen schon sein, dass der Container in einem eigenen Netz läuft und so garnicht die Chance hat, andere Hosts im "lokalen" Netz via z.B. NetBIOS, mDNS, etc. aufzulösen. Das "lokale" Netz des Containers ist dann ein Docker-Netzwerk und darin befindet sich die regulären LAN-Clients eben nicht. Ist vermutlich theoretisch machbar mit ordentlich Gefummel, Bock hätte ich da allerdings nicht drauf.

Aus Deinem Link:

Wenn die Fritz!Box im Netzwerk als DHCP Server fungiert, werden die Hostnamen der Clients nur dort registriert. Pi-hole versucht standardmäßig, die IP-Adressen der Clients wieder in Hostnamen aufzulösen. Daher müssen die Anfragen zur Fritz!Box gelangen.

Bei dem o.g. Text handelt es sich "ausschliesslich" um eine normale Forward-Zone (Hostname zu IP). Entweder als Upstream-Server, oder als bedingte Weiterleitung. Das gilt aber "nur" für Anfragen bzgl. "fritz.box" (zu IP-Adressen). In Bezug auf die Reverse-Auflösung: Wenn Dir die Fritz!Box auf die Nachfrage mit einer IP keinen Hostnamen zurück gibt, wird sie das auch für andere nicht tun. Unter'm Strich ist es egal, ob "Du" die Fritz!Box fragst, oder der Pi-Hole. Nur der Vollständigkeit halber: Wenn es so laufen "sollte", bräuchte der Pi-Hole auch noch eine weitere bedingte Weiterleitung: Die Reverse-Zone (s.o. #6 Link "Reverse-Zone").

Wenn Pi-Hole in der Lage ist, lokale Hosts auf anderweitigen Wegen zu erkennen, mag das mit den Hostnamen in der Anzeige ggf. noch funktionieren, alternativ halt über die Reverse-Zone. "Einfach so" wird es nicht funktionieren und wenn die Fritz!Box diesbezüglich nichts von sich gibt, wird Dir wohl nichts anderes bleiben, als die Einträge eben händisch vorzunehmen. Alternativ halt das komplette Konstrukt so umbauen, dass die DHCP-Informationen dynamisch im DNS registriert werden, ist aber - wie bereits gesagt - nochmal ein ganz anderes Brett. In der von Dir verlinkten Anleitung ist von Deinem "Problem" bzw. einer "Lösung" für Dein Problem jedenfalls "nichts" zu lesen, da es sich da - soweit ich das jetzt gesehen habe - lediglich um die Forward-Auflösung handelt, was Du aber willst (bzw. das was Dir fehlt), ist die Reverse-Auflösung.

Es ist halt ein Unterschied, ob ich frage: "Wo wohnt Herr Meier?" -> "In Haus 1", oder ob ich frage "Wer wohnt in Haus 1?"

 

[Chris88]

ok. also wird das dann wohl so bleiben denk ich. ich versteh nicht, warum das überall so angeprisen wird, aber bei mir (nach eurer beschreibung auch logisch) nicht geht.
ich weiß ihr hasst videos, aber hier wird "live" ganz kurz gezeigt wie das (in Variante 3) funktioniert. wo ist da der unterschied zu mir?

• Pi-Hole - Hostnames bei Clients anzeigen - von Hoerlis Tutorials

kann mir nur vorstellen, dass es wirkoich an dem macvlan im docker container liegt.

was sagt ihr noch zu unbound? nutzen? oder rausschmeißen und öffentliche server fragen?

Danke euch für euer kopfzerbrechen

 

[the other]

Moinsen,

ich weiß ihr hasst videos,

kein aber.

kann mir nur vorstellen, dass es wirkoich an dem macvlan im docker container liegt.

Durchaus möglich, denn es ist ja machbar, dass container miteinander kommunizieren...wenn alles passend konfiguriert ist.

was sagt ihr noch zu unbound? nutzen? oder rausschmeißen und öffentliche server fragen?

Ich selber (bzw die pfsense hier) nutzt als resolver auch unbound. Spricht also nix gegen. Es spricht aber auch nix dagegen, andere DNS Server zu nutzen (möglichst datenschutzfreundliche gibt es ja durchaus...) zur Not den vom ISP genutzten (Forwarding pihole > fritzbox (mit Option ISP eigenen DNS) oder eben (wer es immer noch will) google oder cloudflare DNS.
Öffentlich gibt es viele, die du da nutzen kannst, dann eben als DNS forwarding. Unterschied zu unbound ist ja nur, dass dieser alles "dazwischen" ignoriert und direkt an die obersten DNS Instanzen geht...
Am Ende eigentlich wie so oft im Leben immer eine sehr individuelle Sache: was will ich? Was ist mir wichtig? Muss das so sein?

Danke euch für euer kopfzerbrechen

Dafür ist das Forum ja da...also von daher: gern!

 

[blurrrr]

Also erstmal: Du schuldest mir min. 1 Bier dafür, dass ich nun kurz durch dieses Video zappen musste... (Dazu gibt es noch nichtmals vernünftige Sprungmarken... )

Zweitens: Es wird "ganz klar" gesagt, dass der DHCP-Dienst auf dem Pi-Hole laufen muss (Option 2). Das kommt in etwa dem gleich, was ich oben schon beschrieben hatte (DHCP <-> DNS).

Bei Option 3 macht es für mich mal so gar keinen Sinn, denn dort wird lediglich vom DHCP der Fritz!Box der Pi-Hole als DNS an die Clients verteilt und ändert somit nichts an der Gesamtsituation. Was etwas an der Gesamtsituation ändern "würde", wäre der Punkt, dass die Fritz!Box (DHCP) die dynamische DNS-Registrierung der Hostnamen im entsprechenden DNS vornimmt (Syno, oder ggf. halt Pi-Hole (Cache-Manipulation)). Mag sein, dass das bei dem Video-Ersteller funktioniert, dazu müsste man aber zu 100% wissen, "wie" Pi-Hole dort läuft (direkt auf Blech/eigenständige VM, oder ggf. doch via Docker mit eigenem Docker-Netzwerk).

Die grundlegende Frage wäre also erstmal (bevor wieder so ein "mimimi aber hier im Video..."-Zeugs kommt (Sorry! )...: Hast Du das "eigentliche" Problem verstanden?

Ich versuch es nochmal in Kurzform: Ein Client (in diesem Fall ist auch der Pi-Hole ein Client) hat grob nur 2 Möglichkeiten zur Namensauflösung (alles andere lasse ich einfach mal aussen vor). Diese beschränken sich auf:

1) rumbrüllen (Broadcast/Multicast)
2) jemanden bestimmte fragen (DNS)

Das geht Dir ja ebenso... Wenn Du eine Adresse von wem haben willst, brüllst Du entweder in die Menge, ob jemand die Adresse kennt, oder es gibt eine bestimmte Stelle, bei welcher Du nachfragen kannst. Das "Problem" ist nun folgendes:

1) Du hast kein Reverse-DNS, somit fällt o.g. Option 2 für Dich schon mal flach
2) Wenn der Container in seinem eigenen Netz sitzt, wird er - ganz allein in seinem Netz - soviel rumbrüllen können wie er möchte, niemand wird ihn hören (und somit kann ihm auch niemand antworten)

Vielleicht schaust Du Dir diesbezüglich einfach mal folgendes an: https://docs.pi-hole.net/docker/dhcp/. Hier handelt es sich zwar um DHCP, allerdings arbeitet DHCP auch mit Broadcasts (die Clients kommen ins Netz und brüllen nach IP-Informationen, der DHCP-Server kann diesbezüglich behilflich sein, allerdings nur, wenn er diese Broadcasts von den Clients auch mitbekommt).

 

[blurrrr]

Kleiner Nachtrag: Wenn Du eh eine Syno laufen hast... Kann die ggf. auch direkt virtualisieren? Falls ja, erstell Dir mal eine kleine VM, pack irgendein Linux drauf und installier Pi-Hole mal "nicht" als Docker-Variante. Danach mal Deinem Rechner kurz die VM-IP als DNS eintragen und dann schauste mal, ob die Hostnamen im Pi-Hole auch korrekt dargestellt werden.