@Bucking_Horn Danke für deine ausführlichen Ergänzungen und Erklärungen. Die ULA-Adressen werde ich noch ändern.
Wie du geschrieben hast, sind die Ausführungen weiter oben teilweise überholt (hatte ich ja auch einleitend geschrieben).
Das noch immer neue Beiträge kommen, liegt wohl daran, dass immer mehr Menschen so wie ich ein Pi-Hole aufsetzen wollen und dann erst mal Probleme haben 
@Bucking_Horn
Stimmt schon, dass die Einträge irgendwann veraltet sind, aber solange es hilfsbereite Leute wie Dich und Gert gibt, bleibt auch ein vermeintlich alter Thread aktuell und hilfreich für Anfänger wie mich 
@Gert_Chlupaty
Hier mal die Top Clients als Beispiel:
Wie Du sehen kannst werden manche IPv6 Einträge nicht korrekt aufgelöst, vor Allem aber kommen sie mit der aus meiner Sicht "öffentlich sichtbaren" Adresse rein, wie Bucket es bezeichnet. Da ich aber auch ULA Adressen in der Fritzbox aktiviert habe, hatte ich erwartet, dass die Geräte untereinander damit kommunizieren.
Oder liegt es daran, dass die öffentlichen Adressen immer benutzt werden, wenn bekanntermaßen öffentliche Domains adressiert werden sollen?
Und mein zweiter Punkt bezieht sich darauf, dass die IPv4 und IPv6 Adressen ein und desselben Gerätes in den Statistiken jeweils einzeln mit eigenen Werten aufgeführt werden. Beispielsweise gehört eine der IPv6 Adressen im Screenshot dem iPad, dass unter seine IPv4 Adresse mit aufgelöstem Hostnamen auch an vierter Stelle auftaucht. Hier fände ich es einfach praktisch zu einem Gerät gehörende Adressen in einem Eintrag aggregiert dargestellt zu bekommen.
1 Like
Das habe ich auch. Allerdings kommen bei mir nur die fe80-(ULA)-Adressen. Da mit kann / muss ich Leben
In der FritzBox habe ich unter
Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv6-Adressen
die dritte Option eingestellt: ULA immer zuweisen.
Das Zusammenführen der Einträge für IPv4 und IPv6 unter der IP oder dem Gerätenamen, wie du es wohl meinst, müßte pihole machen. Ob das so einfach möglich ist, kann ich nicht abschätzen
Nachdem ich gestern das "Conditional forwarding" rausgenommen hatte, erschienen auch keine Namen mehr, nur noch die IP-Adressen. Also habe ich "Conditional forwading" wieder aktiviert und siehe da 
Den Eintrag in meinem Beitrag oben werde ich wieder ändern.....
ich habe AVM angeschrieben, da ich denke, dass die FritzBox anstatt der vergebenen Namen nur die ULA-Adresse zurückgibt. Die tauchen dann im pihole auf.....
Die Antwort von AVM ist schon da und inhaltlich bekannt:
+++
vielen Dank für Ihr freundliches Feedback. Ihre Anfrage habe ich alsVerbesserungsvorschlag an den zuständigen Produktmanager im Hause
AVM weitergeleitet. Ob und ggf. wann eine Umsetzung erfolgen wird, steht zum jetzigen Zeitpunkt allerdings noch nicht fest. Generell gilt aber natürlich,dass unsere Produkte von der Nachfrage und den Verbesserungsvorschlägen/Wünschen der Kunden "leben", so wurden auch in der Vergangenheit bereits unzählige Verbesserungsvorschläge in die Tat umgesetzt (nicht selten schon direkt in der nächsten Version).
+++
Aber immerhin
Da sie mit fe80: beginnt, ist das eine link-lokale Adresse.
Das von Dir gesetzte ULA-Präfix war ja fd00: (das entspricht auch dem Standard).
Das könnte Pi-hole zum Abfragezeitpunkt selbst dann nicht zuverlässig leisten, wenn es als DHCP-Server läuft. Der Grund dafür liegt den Eigenheiten von Netzwerkadressierungen und IPv6.
Die dahinter liegenden Mechanismen sind etwas komplexer.
Ich versuche mich mal an einer einfachen Darstellung, aber kurz wird das trotzdem nicht (wer Zeit hat, klickt für Details)
IPv6 setzt zu einem großen Teil auf Auto-Konfiguration der Netzwerkknoten, ohne Beteiligung weiterer Komponenten.
Die link-lokale fe80:-Adresse wird von einem Netzwerkgerät autark erstellt.
Ein wesentlicher Bestandteil ist dabei die MAC-Adresse. Da MAC-Adressen (zumindest vom Anspruch her) weltweit eindeutig sind, sollte man link-lokale IP-Adressen genau wie die MAC-Adressen nicht öffentlich posten, aber das nur am Rande.
Vereinfacht gesagt, ist es einem Gerät mit Hilfe dieser link-lokalen Adresse immerhin möglich, mit anderen Geräten zu sprechen, die an demselben Kabel hängen. Da die Adressen nur an genau diesem Kabelstrang sichtbar sind, dürfen auch ruhig alle link-lokalen Adressen mit fe80: beginnen, ohne dass sie mit link-lokalen Adressen im nächsten Strang oder beim Nachbarn oder sonst irgendwo kollidieren könnten.
In einem Netz kann es aber durchaus auch mehrere separate Segmente (und durchaus nicht nur Kabel) geben, die dann über dedizierte Übergabepunkte miteinander verbunden sind (z.B. einen Switch oder einen WLAN-Access-Point).
Eine übergreifende Kommunikation ist dann nur mit einer globalen IP-Adresse möglich.
Im Gegensatz zu den völlig autark berechneten link-lokalen Adressen müssen diese Adressen sich aber in das jeweils übergeordnete Netz einordnen.
Zu diesem Zweck versucht ein Netzwerk-Gerät, sich ein IPv6-Präfix zu besorgen. Aus dem vom Netzwerkbetreiber (hier der ISP) bereitgestellten Präfix und der immer noch autark berechneten Geräte-Adresse setzt das Netzwerkgerät dann seine globale IP-Adresse zusammen. Global gültige Präfixe müssen dementsprechend auch global bei der IANA bzw einer der lokalen RIRs registriert werden.
Wenn aber der Zugang ins Internet nicht möglich oder überhaupt nicht gewollt ist und Geräte trotzdem segment-übergreifend via IPv6 kommunizieren sollen, muss irgendjemand dieses Präfix vorgeben - z.B. der lokale Netzbetreiber (also Du bzw. Deine Fritzbox). Das ist dann das ULA(Unique Local Address)-Präfix, das im Adressbereich fc00::/7 ohne Registrierung frei vergeben werden kann, wobei die Vergabe aus historischen Gründen meist im Bereich fd00::/8 gewählt wird.
Damit wären wir dann schon bei drei möglichen IPv6-Adressen für ein und dasselbe Gerät.
Weil aber die Verwendung der MAC-Adresse datenschutztechnisch (aufgrund ihrer Eindeutigkeit) zur Konstruktion von IPv6-Adressen bedenklich ist, wurde mit den IPv6-Privacy-Extensions eine aus der MAC-Addresse nur abgeleitete Konstruktion der Geräteadresse eingeführt.
In einem Netzwerk mit ULA-Präfix-Vergabe und (jeweils clientseitig!) aktivierten Privacy-Extensions kann es daher in einem Standard-Heimnetz durchaus vier IPv6-Adressen für ein Gerät geben:
| Präfix | Bezeichnung | Sichtbarkeit | Anmerkung Geräteadresse |
|---|---|---|---|
| fe80: | link-lokal | Segment | mit erkennbaren MAC-Adressanteilen |
| fd00: | ULA | Heimnetz | mit erkennbaren MAC-Adressanteilen |
| fd00: | ULA | Heimnetz | mit per Privacy-Extension erzeugter Geräte-Adresse |
<ISP> |
global | weltweit | mit per Privacy-Extension erzeugter Geräte-Adresse |
Grundsätzlich versucht ein Gerät dabei immer, seine IPv6-Adresse selbst zu konstruieren und sich nur bezüglich des Präfixes ergänzende Informationen zu besorgen.
Zwar sieht Stateful DHCPv6 analog zu DHCP (für IPv4) auch die Vorgabe einer kompletten Adresse vor. Es ist neben SLAAC (der vollkommen autarken Vergabe) und Stateless DHCPv6 (nur Vorgabe von Präfix und anderen Paramatern) allerdings nur eines von drei Verfahren, die z.T. auch gemischt verwendet werden können.
Und: Es liegt allein im Ermessen des Clients (also des Netzwerkgeräts), mit welchem Verfahren die Eingliederung ins Netzwerk erfolgt.
Klassischerweise machen Windows-Clients (zumal Versionen <Win10) das eher über DHCPv6, während Android-Geräte sich ausschließlich über SLAAC konfigurieren.
Es entscheidet damit auch, ob und wie es seinen Namen im Netz registriert.
Apple-Geräte setzen daneben mit mDNS (Bonjour) auch noch auf ein weiteres alternatives Verfahren zur (allerdings rein lokalen) Namensauflösung in Netzwerken.
Darüber hinaus können sich Präfixe und Geräteadresse aufgrund von Neuberechnung im Laufe der Zeit auch ändern (wobei es dieses Problem in ähnlicher Form bei IPv4 auch gibt).
Damit lässt sich aber bei IPv6 nicht mehr sicherstellen, dass zu einer IP-Adresse auch an zentraler Stelle ein Name assoziiert ist.
Jetzt könnte man auf die Idee kommen: Na gut, aber über die MAC-Adresse sollte das doch gehen.
In einem flachen Netzwerk (ein Strang) würde das auch funktionieren, aber wenn ein Übergabepunkt ein Datenpaket in einen anderen Strang weiterreicht, ersetzt er die MAC-Adresse des Absenders durch seine eigene. Im Gegensatz dazu bleibt die IP-Adresse unver#ndert, sofern kein NAT erfolgt (was im lokalen Netz selten nötig ist).
Bei Verwendung von MAC-Adressen würde Pi-hole dann fälschlicherweise den Übergabepunkt (also z.B. den WLAN-AC) als Absender identifizieren. Hinzu kommt, dass MAC-Adressen nur im Data-Link-Layer auftauchen, also einer niedrigeren Netwerkschicht, während DNS sich auf dem Netzwerk-Layer (UDP:53) oder dem Transport-Layer(TCP:53 abspielt. Als DNS-Proxy bekommt Pi-hole die MAC-Adressen bei einer Anfrage also gar nicht direkt mit. Und das DNS-Protokoll selbst sieht keine Angaben zur Identifikation des Anfragerstellers vor.
Pi-hole muss also versuchen, aus den zum Abfragezeitpunkt verfügbaren Informationen das beste zu machen, ohne dabei seine eigene Latenz (also die Verabeitungszeit bis zum Weiterreichen oder Antworten einer DNS-Anfrage) unnötig aufzublähen.
Wer jetzt nur noch Bahnhof versteht, darf mir gerne vorwerfen, ich würde nicht zielgruppengerecht kommunizieren - ich habe keine Ahnung, über welche Vorkenntnisse ihr verfügt ;).
Dabei habe ich noch nicht einmal näher erwähnt, dass es für einen Netzwerkknoten durchaus mehrere Namen geben kann (als Beispiel einfach mal vom Pi-hole ein nslookup an die Fritzbox-IP-Adresse schicken). Und insgesamt ist das auch nur eine vereinfachte Darstellung von dem, was auf Netzwerkebene tatsächlich passiert.
Seht es der tapferen kleinen Schar unserer Pi-hole-Entwickler also nach, wenn sie sich immer zuerst auf das wesentliche konzentrieren:
Dass Pi-hole ungewollte und böswilige Hosts wegfiltert.
Um den Rest kümmern sie sich auch, etwas langsamer, aber mit jeder Version ein bisschen besser und ein bisschen mehr.
Unter den gegebenen Umständen ist die Verwendung der IP-Adresse daher die beste verfügbare Lösung, um während der Verarbeitung der DNS-Anfragen ein aussagekräftiges Log zu generieren.
Ex-post kann man jetzt noch im Zuge der Aufbereitung der Statistik versuchen, mit diesen erfassten Informationen zu einer besseren Abbildung für die Statistik zu kommen, wie z.B. die Zusammenfassung der Anfragen eines Hosts mit all seinen (eindeutig bekannten) Adressen.
Das ist für die Zukunft wohl auch geplant, wobei hier zunächst Informationen aus dem relativ neuen [Network overview bei der Auflösung der IPv6-Adresse aus den Logs berücksichtigt werden sollen - allerdings zunächst nur unter Annahme eines einfachen Heimnetzes, ohne Switches und ACs (was für die Mehrzahl der Standard-Heimanwender wohl auch hinkommt).
Nachlesen kann man das z.B. im Feature Request Show name in Top Clients lists rather than IPv6 addresses. Ihr seht also, Pi-hole lebt von den Anregungen seiner Community.
Dann hast Du wohl einen Haken bei Never forward reverse lookups for private IP ranges (bogus-priv) gesetzt.
Dadurch verwendet Pi-hole die Fritzbox nicht mehr zur Auflösung lokaler Adressen
Normalerweise ist das eine vernünftige Wahl, da man so nicht in die Verlegenheit kommt, seine lokalen IP-Adressen an DNS-Server im öffentlichen Netz weiterzugeben, die ohnehin nichts damit anfangen können.
Aber Du hast ja laut Deinem Beispiel genau die Fritzbox als Upstream-DNS-Server für Deinen Pi-hole konfiguriert. Wenn Du Pi-hole jetzt die Rück-Auflösung privater IP-Adressen verbietest, bleibt nur noch Conditional Fowarding. Ist aber ein Extra-Schritt für Pi-hole - wobei der wahrscheinlich zeitlich überhaupt nicht auffällt.
Es empfiehlt sich hier, außerdem einen Blick in die tatsächliche dnsmasq-Konfiguration zu werfen:
Die Anzeige unter Settings befüllt Pi-hole nämlich zum guten Teil aus der hinterlegten Sollstellung (setupVars.conf), was nicht immer der tatsächlichen Konfiguration entsprechen muss (insbesondere, wenn man gerne manuell in den Konfigs herumfuhrwerkt was sich aber für manche Ziele nicht vermeiden läßt.)
nano /etc/dnsmasq.d/01-pihole.conf
Da sollte auf keinen Fall die Zeile bogus-priv auftauchen.
4 Likes
@Bucking_Horn Danke für deine Geduld und die sehr ausführlichen und verständlichen Erklärungen.
Ich habe den Haken bei Never forward reverse lookups for private IP ranges ( bogus-priv ) rausgenommen und die conf kontrolliert.
Es ist erstaunlich, was ich hier alles lerne 
Um es in WhattsApp nach einem deutschen Comedian auszudrücken: Ankommen sind die Informationen, daher zwei schwarze Haken. Bis die blau werden (verstanden), kann es aber dauern 
Ach ja: nslookup brachte 11 Adressen 
@Klattsche Jetzt funktioniert die Namensauflösung scheinbar komplett. Ich habe keine v6-Adressen mehr in der Clientübersicht.
@Bucking_Horn
Sage mal, Du bist nicht zufällig einer dieser besagten tapferen kleinen Schar?
Auch von mir vielen Dank für Deine ausführlichen Erklärungen. Sicher sind da auch Begriffe mit denen ich auf Anhieb nichts anzufangen weiß, aber wenn sich jemand schon so viel Mühe gibt ist es sicherlich nicht zu viel verlangt, dass ich als Leser diese Wissenslücken selbst recherchiere 
Davon abgesehen ist die automatische Namensauflösung für mich mehr ein nice to have, schließlich kann man via fixer IP-Adressen und der hosts Datei mit sehr überschaubarem Aufwand dafür sorgen, dass die gewünschten Namen auftauchen.
Hallo zusammen, ich sage auch danke für die ganzen Beiträge, die haben mir echt weitergeholfen. Allerdings verstehe ich den Unterschied und die Auswirkungen der Konfigurationen von @Olli und @Gert_Chlupaty nicht ganz so. Kann mir das bitte jemand erklären und sagen welche Konfiguration besser ist?
Danke und Gruß
R3scol
@R3scol
Für mich besteht der Unterschied darin, dass in "meiner" Konfiguration die Fritzbox die Kommunikation nach aussen übernimmt (DNS-Server 1.1.1.1), in der Konfiguration von Olli übernimmt Pihole das. In dieser Konfiguration ist Pihole als DNS-Server in der Fritzbox eingetragen.
Es funktioniert beides.
Pihole sollte aber nicht im DHCP-Bereich der Fritzbox liegen (wenn Pihole nicht den DNS-Server stellt). Mein Pihole hat 192.xxx.yyy.19
Ich habe irgendwann mal die Regel gelernt: Alle Server-IPs unter 50, alle (Netzwerk-) Drucker über 220, alle natürlich mit statischen IP-Adressen.
1 Like
@Gert_Chlupaty danke für die Erklärung, das ergibt für mich Sinn. Die Frage ist nun welche Variante ist die bessere und warum? 
Danke für die Info. Ja das mit der statischen IP für das Pi hole hat bei mir erstmal nicht geklappt, weil der Punkt "immer selbe Adresse vergeben" nicht angezeigt wurde. Aber ich habe herausgefunden, sobald die IP des Pi Holes außerhalb des DHCP Bereichs des Routers vergeben, kann ich den Haken "immer selbe IP vergeben" setzten.
Gruß
R3scol
Was wäre denn besser?
Das hängt sehr von den persönlichen Umständen und Präferenzen ab. Eine pauschale Antwort ist hier nicht seriös möglich.
Die eine richtige FritzBox-Konfiguration für alles gibt es nicht.
(Und noch kurz etwas zur Abgrenzung zwischen fixer (bzw. fester) und statischer IP-Adresse)
Fix und Statisch wird zwar oft synonym verwendet, aber es gibt da durchaus einen Unterschied.
Eine statische IP wird vom Gerät selbst deklariert, ohne dass hierbei Konfigurationsoptionen aus dem Netzwerk (z.B. von einem DHCP-Server) berücksichtigt werden. Insbesondere müssen hier im Normalfall auch Gateway und DNS manuell konfiguriert werden.
Ein so konfiguriertes Gerät macht seine IP per Broadcast im Netzwerk bekannt.
Damit eine solche Adresse nicht mit dynamisch vergebenen Adressen kollidiert, sollte sie in der Tat nicht im Adressbereich eines DHCP-Servers liegen.
Kollisionen mit anderen ebenfalls statisch vergebenen Adressen sind natürlich trotzdem noch möglich (und führen im Zweifelsfall dazu, dass keines der statisch konfigurierten Geräte mehr zuverlässig erreichbar ist).
Eine fixe IP-Adresse kann eine statische Adresse oder eine per DHCP lease reservation vergebene dynamische IP-Adresse sein.
Eine auf letzere Weise vergebene fixe IP-Adresse kann selbstverständlich im DHCP-Adressbereich liegen (FB-Standard: .20 bis .200).
Da diese zentral verwaltet werden und so konfliktfrei ins Netzwerk integriert werden kann, ist eine lease reservation gegenüber der geräteseitigen statischen Deklaration die klar zu bevorzugende Variante.
Genau das macht eine FritzBox in ihrer Eigenschaft als DHCP-Server, wenn Du dort eine feste IP-Adresse einträgst.
Sie gibt die Möglichkeit zur Bearbeitung aber nur frei, wenn das Gerät seinerseits nicht statisch konfiguriert wurde und die gewünschte IP-Adresse nicht bereits in Verwendung ist.
Demgegenüber kann sich eine frei dynamisch vergebene IP-Adresse für ein Gerät nach Ablauf ihrer Gültigkeit (FB-Standard: 10 Tage) ändern.
Für die meisten Gerät macht das keinen Unterschied, aber Pi-hole sollte im Heimnetz stets unter derselben fixen IP-Adresse erreichbar sein.
2 Likes
Danke dir für die Erklärung zwecks fester/statischer/fixer IP 
Ja das denke ich mir schon, das jede Konfig so seine Vor- und Nachteile hat, mir ist nur nicht klar welche das sind. Deswegen frage ich, weil sich mir nicht erschließt was für meine Umstände besser ist
Danke und Gruß
R3scol
Hallo in die Runde!
Ich bin neu hier und habe diesen Thread in den letzten Tagen von Anfang an durchgelesen. Nun habe ich ein aktuelles pihole auf einem rpi 4B aufgesetzt und in Betrieb genommen. Das funktioniert auch relativ gut. Aber...
jf62 hatte hier mal am 1 Jun '18 geschrieben:
Wieso arbeitet ihr so?
Bei mir ist alles super schnell und sauber mit folgender Config:
Das habe ich mir zu Herzen genommen und seine Konfiguration nachgestellt. Leider schmeißt man sich damit IP-TV Angebote aus dem Haus. Jedenfalls bei mir. Genaugenommen funktioniert der Magenta Entertain MR401 dann nicht mehr.
Kann da jmd. Tipps zur Problembehebung abgeben?
Viele Grüße.
theo
Es führen viele Wege nach Rom: meiner sieht so aus wie von jf62
klick
Wenn du die von mir oder jf62 in der Fritzbox eingestellten DNS-Server von Cloudflare gegen die der Telekom austauschst, also die des Providers nutzt, könnte es klappen.
Hallo Gert,
vielen Dank für die schnelle Antwort. Ich habe in der Fritzbox erst einmal gar keinen neuen UpstreamDNS eingetragen. Ich habe alles auf Telekom belassen und lasse nur die IP des pihole über DHCP verteilen.
Leider genügt allein das, um den MR401 und das Magenta TV abzuschießen.
Also kurz - es geht so leider nicht...
und... was noch viel wichtiger ist, ich möchte ja langfristig den DNS von DigitalCourage o.ä. nutzen. Dazu muss ich aber die Spezifik der DNS-Probleme kennen, die den MR401 abhalten, korrekt zu arbeiten. Daher hier meine Frage...
Ist da was bekannt? Spezielle DNS-Einträge oder ??
Die Frage ist legitim.
Aber -ich wiederhole mich- sie läßt sich nicht seriös beantworten.
Ich sehe das differenziert so:
Eine Konfiguration hat per se keine Vor- oder Nachteile.
Sie hat vielleicht eine Reihe von Eigenschaften.
Ob jemand eine dieser Eigenschaften als Vor- oder Nachteil bewertet, liegt allein im Auge des Betrachters - ebenso, ob er die Konfiguration insgesamt aufgrund der Bewertung aller Eigenschaften als vorteilhaft empfindet oder nicht.
Zwei kleine Beispiele:
Die von @Gert_Chlupaty aufgelisteten Parameter (n.b: das sind längst nicht alle Stellschrauben, an denen man drehen könnte) führen bei ihm zu einer lauffähigen Konfiguration, mit der er auch zufrieden ist.
Die haargenau gleiche Konfiguration würde vielleicht bei jemandem, der einen AD-Domänencontroller in seinem Netzwerk betreibt, dazu führen, dass er lokale Hostnamen nicht mehr auflösen kann.
In dem genannten Setup definiert außerdem die FritzBox, welche DNS-Server letzlich mit der Namensauflösung beauftragt werden.
In der FB kann ich allerdings nur jeweils zwei DNS-Server für IPv4 und IPv6 eintragen.
Das ist ganz objektiv eine Einschränkung gegenüber Pi-hole, wo ich wesentlich mehr DNS-Server gleichzeitig beauskunften kann.
Aber ist das jetzt auch ein Nachteil?
Wenn ich mich eh für die Server von DigitalCourage entschieden habe, eher nicht.
Wenn ich die theroretisch größtmögliche Ausfallsicherheit für DNS-Dienste haben möchte, vielleicht schon.
Die Beispiele sollten hinreichend verdeutlichen, wie sehr Umstände (hier also die besondere AD-Netzwerkkonfiguration) und persönliche Präferenzen (hier bezüglich der DNS-Server) die Beurteilung einer Konfiguration bereits auf der Ebene einzelner Parameter beeinflussen.
Ohne genaue Kenntnis der Umstände ist es daher nicht seriös möglich, die Qualität oder Eignung einer Konfiguration zu beurteilen.
Was ich allerdings sagen kann:
Jede funktionierende Konfiguration ist ein guter Startpunkt.
Wenn dann Probleme auftreten oder ein bestimmter Wunsch noch nicht ausreichend abgedeckt ist, findet man hier im Forum mit einer gezielten Fragestellung im Hinterkopf wahrscheinlich schneller und besser Unterstützung, als wenn man versucht, alle möglichen Aspekte vorab in einer Universalkonfiguration zusammenzufassen.
In den Fällen, in denen eine Suche im Forum keine Ergebnisse bringt, ist es das Beste, die für die Suche verwendete Fragestellung aus dem Hinterkopf in ein eigenes Topic zu füllen.
Niemand ist in allen Bereichen bewandert, aber eine gut formulierte Fragestellung mit einem aussagekräftigen Titel erhöht die Chancen, die richtigen Leute auf sein Thema zu locken - und ganz nebenbei auch anderen Besuchern zu helfen, die nach einer Lösung für ein ähnlich gelagertes Problem suchen
2 Likes
Hi an alle,
ich habe mir nun schon einige Themen und dessen Posts angeguckt, komme jedoch zu keinem Erfolg, was die Interne Namensauflösung auf dem Dashboard angeht.
Was ich bislang versucht habe:
Use Conditional Forwarding
IP der Fritzbox und "fritz.box" als domain.
Never forward non-FQDNs
Never forward reverse lookups for private IP ranges
hier hat egal welche konstellation kein Erfolg gebracht.
Als DNS im Pi habe ich jetzt sogar nur noch die Fritzbox unter custom drin.
Die Fritzbox hat unter Internet den DNS 1.1.1.1 bzw. 1.0.0.1 drin.
DNS Rebound in der Fritzbox habe ich folgende Info:
pi.hole
pi.fritz.box
Unter allen Domains geschah eine auflösung des Pi´s im terminal mit dem Dig befehl
allerdings ist es so, wenn ich von meinem Ubuntu Notebook ein Dig sende, geht das automatisch an 127.0.0.53. Ist das so gewollt?
Hab ich irgendwo was übersehen oder etwas falsch ausgewählt?
Ich hab keine IPv6 im Netz und nutze ein Adressbereich im 10.16.x.y.
Ich wäre für jede Hilfe sehr Dankbar. - Ich quäle mich damit nun schon seit Tagen.
also ich habe an den Einstellungen
nichts geändert und die interne Namensauflösung am pihole läuft einwandfrei.
vielleicht 127.0.0.1:53? das wäre eine DNS-Abfrage an den localhost - oder wirklich an 127.0.0.53?
Werden auf der Fritz!Box alle Netzwerkgeräte mit ihren Namen richtig angezeigt?
Der DHCP-Server der Fritz!Box muss die statische IP des pihole propagieren!
vielleicht hilft einer dieser Tips?
@theobald: Kannst du in den Listen/Queries Telekom-Adressen finden, die geblockt werden? Vielleicht auch in den Regex-Filtern? Vielleicht wird da was geblockt, was der MR401 braucht.
Vielleicht findest du auch was unter Tools/Thail pihole.log. Da wird alles "in Echtzeit" angezeigt, was so passiert.