Ich habe jetzt echt ne Menge versucht um bei der PiHole die IP6 Hostnames von der Fritzbox (dhcp) anzuzeigen, aber ich kriege es nicht zum laufen. Hat vielleicht eine genaue Anleitung?
1 Like
Ich hatte mehrere Einstellungen mit meiner Fritzbox 7490 und meinem pihole auf einem Raspberry 3b+ (RPi) ausprobiert und hatte lange Zeit die Situation, dass nach der ersten Installation von pihole alles lief, aber nachdem ich das erste mal alles ausgemacht hatte, ging dann nichts mehr. Jetzt habe ich das Setup endlich zum Laufen bekommen und schildere für alle, die auch Probleme haben meine Installation und Einstellungen unten.
Mit der "Blacklist" im pihole habe ich durch den Eintrag "(^|.)facebook.com$" (ohne ") getestet, ob der pihole Block auf den angeschlossenen Geräten wirklich funktioniert. Facebook sollte immer geblockt werden. Die Einstellung kann man auch gleich so lassen 
1. Installation von pihole auf dem RPi
https://blog.cryptoaustralia.org.au/instructions-for-setting-up-pi-hole/
[Wenn ihr Windows 10 benutzt müsst ihr eventuell für Etcher den "Controlled folder access" der Ransomware Protection in Windows Security-Virus & threat protection ausschalten.]
2. Update die Fritzbox Firmware
07.11 zum Zeitpunkt dieser Beschreibung
3. Feste IP in Fritzbox zuweisen
Dem RPi muss man in der Fritzbox eine feste IP zuweisen. Je nachdem welchen Hostnamen man dem RPi bei der Installation zugewiesen hat, kann man den RPi sehr einfach unter Heimnetz-Mesh finden. Standard ist "raspberrypi". Hier in der Liste der aktiven Verbindungen auf 'Details' klicken und dann dem RPi eine feste IP zuweisen und auswählen, dass man dem Gerät immer dieselbe IP gibt.
Weiter unten sieht man hier auch die IPv6 Adressen des RPi und sollte sich die Adresse mit "fd00" am Anfang für Punkt 5. notieren.
4. Fritzbox IPv4 Einstellungen
Unter Heimnetz-Netzwerk-Netzwerkeinstellungen-IPv4-Adressen sieht man die eingestellte DHCP Range und sollte die IP des RPis so wählen, dass sie außerhalb dieses Bereichs liegt. Hier muss man außerdem die oben festgelegte IPv4 des RPi als lokalen DNS-Server eintragen.
5. Fritzbox IPv6 Einstellungen
Auch für IPv6 muss man dem RPi eine feste IP geben. Hierfür unter Heimnetz-Netzwerk-Netzwerkeinstellungen-IPv6-Adressen den Punkt 'Unique Local Addresses (ULA) immer zuweisen' auswählen.
Und auch hier gleich wieder die die IP des RPi als lokalen DNS-Server eintragen. Diesmal ist das aber für IPv6. Man braucht beide, um Anfragen über IPv6 und IPv4 mit dem pihole abzufangen.
Am besten die "fd00" Adresse nehmen, die in den Details zum RPi in der Fritzbox angezeigt wird (s. Punkt 3.)
[6. DNS Rebind Schutz]
Dieser Punkt ist bei mir aktuell nicht nötig, um das Setup zum laufen zu bringen.
Unter Heimnetz-Netzwerk-Netzwerkeinstellungen muss man beim Punkt 'DNS-Rebind-Schutz' "pi.hole" (ohne ") eintragen. Unter 'Zeitsynchronisation' habe ich die Fritzbox als Zeitserver im Heimnetz auch rausgenommen, ob das wirklich nötig ist, habe ich aber jetzt nicht nochmal extra validiert.
7. Fritzbox DNS-Server festlegen
Unter Internet-Zugangsdaten-DNS-Server müssen die IPs des RPis eingetragen werden, welche man oben schon genutzt hat und auch im Admin Webinterface von pihole unter Settings-System finden sollte.
Hier habe ich die gleiche IP für "bevorzugt" und "alternativ" verwendet. Hier könnte man auch die IPs eines zweiten RPis mit pihole eintragen, der als Backup fungiert. Sollte man aber andere IPs eines anderen DNS Servers eintragen, kann es vorkommen, dass einige Anfragen nicht mehr über mein pihole laufen und dieses dementsprechend ad absurdum geführt wird.
8. Einstellungen im Pihole
Pflicht
- 'Use DNSSEC' musste ich hier deaktivieren (soll wohl mit dem nächsten pihole Update weniger Probleme bereiten).
Standard
- Unter Advanced DNS settings habe ich "Never forward non-FQDNs" und "Never forward reverse lookups for private IP ranges" ausgewählt gelassen.
Optional
Settings-System'Query Logging' deaktiviert (braucht man nicht und es wird ja trotzdem ein Log erstellt, über den man dann Statistiken hat und Abfragen laufen lassen kann).Settings-DNSQuad9 (filtered, DNSSEC) als Upstream DNS Servers für IPv4 und IPv6 (Je nachdem welchen DNS Service man hier als Favorit hat).
Jetzt funktioniert nur nichts mehr, wenn ich den pihole abschalte und so hatte ich es mir ja auch vorgestellt. Ich hoffe, dass die Beschreibung eventuell jemandem bei Problemen mit der pihole Installation helfen kann. Sollte bei euch eine andere Einstellung zum Erfolg geführt haben, bitte gern posten, damit andere mitlernen können. Immerhin sieht jedes Netzwerk etwas anders aus.
2 Likes
Das würde mich auch interessieren.
Hi, dank Dir für Deine Settings.
Die Einstellung von Punkt 8 habe ich noch nicht getroffen, da ich diesbezüglich noch viele Fragezeichen habe.
Anscheinend wird aber zuverlässig auch unter IPv6 geblockt.
Hallo Zusammen,
über diesen Thread bin ich in die wichtigsten Konzepte vom Pihole eingestiegen. Nachdem ich mich hier durch alle Posts durchgekämpft habe, musste ich leider feststellen, dass im ersten Post und auch in den weiteren Posts Informationen sind, die mittlerweile veraltet sind... Ich möchte hier diese Themen kurz aufgreifen und hoffe, dass der Thread-Ersteller seinen Startpost aktualisiert und ggf. den Titel des ganzen Threads mit einem Zusatz "V.2" oder "2019" ergänzt (@caesar)
Thema 1: IP-Tables für IPv4 und IPv6 um HTTP/S Anfagen zu behandeln und langsames laden von Webseiten verhindern
So wie es für mich aussieht sind die IP-Tables Einstellungen (in der aktuellen pihole-Version) obsolete und die Informationen hierzu können meiner Meinung nach komplett aus dem Initial-post entfernt werden, damit sich neue User nicht mehr unnötig mit diesem Thema beschäftigen.
Thema 2: Blockingmode
Auszug aus der Dokumentation: (Blocking mode - Pi-hole documentation)
Für mich sieht es so aus als wurde Thema 1 mit dem BlockingMode gelöst. Da BLOCKINGMODE per default auf NULL steht, bräuchte man hier noch nicht mal mehr einen Hinweis zum BlockingMode im Intial post geben...
In dem Initialpost könnten meiner Meinung nach die folgende Absätze gelöscht werden:
- Manche Seiten laden sehr lange.
- Probleme am iPhone
- Seiten laden langsamer
Diese Absätze hängen scheinbar alle damit zusammen was damals mit den IPTables und heute per default mit dem Blockingmode gelöst wird. Das macht die Anleitung auch schlanker und macht es neuen Usern auch wieder einfacher.
Ab hier sind von mir noch Ergänzungen die aktuell noch in arbeit sind und hoffentlich ggf. später in den Initial post eingearbeitet oder in ein gesonderten Anleitung verfasst werden:
Thema 3: Rebindschutz
hier bin ich mir selbst noch nicht ganz im klaren drüber und daher folgenden hier die Infos später..
Thema 4: Conditional Forwarding
Was klar ist:
- Diese Option sollte aktiviert, solange der pihole nicht DHCP macht.
- CF sorgt dafür, dass die Clientnamen im Pihole Webinterface (z.B. Top Clients) anstatt die IP angezeigt werden
Was noch unklar ist:
- CF kann alle Clientnamen am Router erfragen und dadurch können auch die Clients ihre lokale Namen gegenseitig auflösen können.
Thema 4: Never forward non-FQDNs & Never forward reverse lookups for private IP ranges
hier bin ich mir selbst noch nicht ganz im klaren drüber und daher folgenden hier die Infos später..
Konfigurationen / Konzepte:
Zuletzt möchte ich noch meine Übersicht zu den einzelnen Konzepten hier bereitstellen.
Das ganze ist noch nicht fertig getestet aber bringt die Vor- und Nachteile gut auf den Punkt.
Persönliche Anmerkungen:
Ich möchte den Pihole nicht als DHCP laufen lassen, da ich der Fritzbox HW in sachen Ausfallsicherheit mehr traue als meinen kleinen Raspberries.
Ich habe daher zwei Piholes am laufen und möchte diese im besten Fall ganz klassisch allen Clients als DNS1 und DNS2 mitgeben.
Momentan verwende ich noch Konfiguration #1 um so beide Piholes einzubeziehen. Hat aber den Nachteil, dass ich in den Webinterfaces als Client immer nur die Fritzbox sehe, da alle Geräte über die Fritbox anfragen. Dieses Thema wurde hier so weit ich weiß nicht bemängelt und scheint keinen zu stören. Daher finde ich diese Lösung (die häufig vorgeschlagen wird) ziemlich unbefriedigend... Okay das Filtern funktioniert, ist schnell und auch sind die Piholes redundant aber es wäre schon schön zu welche Clients welche Domains anfragen um trouble-shooting zu betreiben.
Nächster schritt ist zu prüfen ich den Clients per Fritzbox nicht bei doch zwei DNS server mitgeben kann oder ich muss mir noch mal die pihole-cluster ansehen...
Fritzbox-qual
Update: Es ist mir nicht möglich per Config in der Fritzbox zwei eigene IPv4 oder zwei eigene IPv6 DNS server an die Clients per DHCP zu verteilen.
Der wert:
- lan_dns6_server = ipv6-adresse; (nimmt nur eine Adresse an, eine zweite durch komma getrennte IP hat nix gebracht.)
- lan_dns4_server = ipv4-adresse; (nimmt nur eine Adresse an, eine zweite durch komma getrennte IP hat nix gebracht.)
Nix gebracht heißt: Fritzbox kommt nach dem obligatorischen neustart mit ihrer werks-IP zurück und hat alle DHCP settings wieder auf default gesetzt....
So bleibt mir nix übrig als die piholes wieder im Upstream der FB einzutragen und die FB per DHCP als DNS an die Clients zu verteilen. Mit der Einschränkungen, dass ich in der Pihole oberfläche nur die fritzbox als client sehe...
3 Likes
Hallo zusammen,
ich bin noch neu in der Raspi-Welt, mache aber hobbymäßig und auch beruflich schon seit Anfang der 80er mit PC´s rum. Der/die Raspi(s) sollen mir den Ruhestand versüßen 
Mein erstes Projekt ist pihole auf einem 3a (ich weiß, ist überdimensioniert, war aber samt Gehause nicht teurer als ein Zero W).
Nach dem Durcharbeiten etlicher Anleitungen zum Thema Fritzbox und pihole musste ich feststellen, dass die sich teilweise widersprechen oder "gut abgehangen" sind und viele Schritte enthalten, die nicht mehr nötig und dadurch ggf. sogar kontraproduktiv sind
Nach vielem Testen, überdenken, Sicherungen der FB wieder einspielen etc. hat sich im Moment folgende Konfiguration als lauffähig erwiesen:
Kursiv: Originaleintrag, auf Anregung von Bucking_Horn geändert (s.u.). Funktioniert 
Einstellungen in der Fritzbox (7490, BS 7.12)
Bitte beachtet auch die Hinweise von "Bucking_Horn" vier Beiträge weiter unten und ff.
- Internet -> Zugangsdaten -> DNS-Server
- 1.1.1.1
2606:4700:4700:0:0:0:0:1111 - 1.0.0.1
2606:4700:4700:0:0:0:0:1001
(oder eigene oder den ISP auswählen) - Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv4-Adressen
- Lokaler DNS-Server: 192.168.xxx.yyy (Adresse des pihole)
- Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv6-Adressen -> DNSv6-Server im Heimnetz
- Lokaler DNS-Server: 2003:xxxx:yyyy:.... Besser: fd00:xxxx:xxxx:xxxx:xxxx:.(v6-Adresse des pihole, zu finden unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> Details für pihole (Stiftsymbol)
Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> DNS-Rebind-Schutz (Optional)
IP-Adresse des pihole und den Servernamen (pi.hole) in jeweils einer Reihe eintragen:
192.168.xxx.yyy
pi.hole
Einstellungen im pihole
- Settings -> DNS
- Upstream DNS Servers (oben rechts)
- Custom 1 (IPv4) 192.xxx.yyy.zzz (IPv4-Adresse der Fritzbox)
- Custom 3 (IPv6) fd00: xxxx:yyyy: etc (IPv6-Adresse der Fritzbox, zu finden unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen > IPv6-Adressen - >)
- Custom 2 und 4 ggf. wie oben
- Advanced DNS-setting
- Never forward reverse lookups for private IP ranges - nicht anhaken bzw. Haken entfernen
- Use DNSSEC -> NICHT aktivieren, machte bei mir erhebliche Probleme
- [...] gelöscht
Es werden alle Clients im pihole angezeigt, die Namensauflösung der lokalen Clients funktioniert, Werbung ist schön wenig bis nicht vorhanden, die Seiten werden schnell ausgeliefert - läuft erst mal.
2 Likes
Vielen Dank für die ausführliche Anleitung! Hat bei mir auf Anhieb funkioniert. Ich verwende Raspian Buster Lite (aktuelles Release).
Folgende Tipps möchte ich noch beisteuern:
- Um dem Raspi eine feste v4 IP (Punkt 3. in der Anleitung) aus dem Bereich unterhalb des DHCP-Pools (in meinem Fall
.5) zuzuweisen, musste ich die Adresse in der dhcpcd-Konfig eintragen. Einfach nur in der FritzBox festlegen, hat nicht funktioniert. Anleitung findet man hier: Raspberry Pi: Statische/feste IPv4-Adresse für Raspbian Jessie - Die FritzBox zeigt die ULA das Raspi schon an, wenn diese noch gar nicht vergeben bzw. aktiv ist. Das hat mich verwirrt. An der Kommandozeile kann man mit
ping6 <hier die ULA eintragen>(ohne spitze Klammern) prüfen, ob sie aktiv ist. Nach der FB-Einstellung gemäß Punkt 5. war sie dann sofort aktiv. - Beim Eintragen der Raspi-ULA als Lokaler DNSv6-Server (Punkt 5.) müssen die
::in der Adresse mit Nullen aufgefüllt werden, bis die Adresse aus acht Teilen besteht. Bei mir steht also der Teil::für:0:0:0:Das ist zwar IPv6-Grundlagenwissen, aber ich mussste es lernen. - Da ich an einem "v6-DSL"-Anschluß hänge, wurde die Werbung erst herusgefiltert, nachdem ich auch IPv6 gemäß Anleitung vollständig konfiguriert hatte. Irgendwie auch logisch
Anmerkungen:
- ULA ist sozusagen die Netz-interne IPv6-Adresse beginnend mit
fd00, siehe Punkte 3. & 5. der Anleitung - Als Kommandozeile zum Testen verwende ich ein Ubuntu des Windows Subsystem for Linux. Also Linux shell unter Windows 10. Da stehen auch so hilfreiche DNS tools wie z.B.
digzur Verfügung.
3 Likes
Hallo zusammen,
dank der vielen Anleitungen und Ratschläge habe ich es auch recht schnell hinbekommen das Pi-hole zu füttern, dafür also schon mal besten Dank an die jeweiligen Poster
Im Grunde entspricht mein Setup nun dem von Gert_Chlupaty zwei Posts vor diesen skizzierten.
Allerdings kommen eine Hand voll Geräte statt mit ihrer von der FB festgelegten statischen IPv6 Adresse fd00.... mit der vom Provider (so hab ich es zumindest verstanden) vergebenen 2a02... an und werden entsprechend nicht korrekt mit dem Hostnamen angezeigt. Hat das noch jemand? Oder ist das vielleicht gar nicht die Ursache der fehlenden Hostnamen?
Außerdem finde ich es etwas unübersichtlich, dass zwei Einträge pro Gerät existieren, sofern das Geräte sowohl über IPv4 als auch 6 anfragt. Kann man das wohl nur für die Statistiken irgendwie in einem Eintrag aggregiert anzeigen?
@Klattsche: Ich kann nicht nachvollziehen, was du meinst. Kannst du mal einen (anonymisierten) Screenshoot einstellen?
Wundert mich ja, das auf diesen alten Post immer noch neue Antworten eintrudeln
Der Original-Post ist mittlerweile zumindest teilweise überholt, der ursprüngliche Ersteller hat außer diesem nützlichem Beitrag vom Februar 2018 nichts wieder von sich hören lassen, und die über die lange Historie ergänzten zusätzlichen Konfigurationsbeispiele haben auch alle so ihre kleine Macken.
Nichts weltbewegendes, aber vielleicht trotzdem den ein oder anderen Hinweis oder eine Erläuterung wert
Du solltest hier besser die ULA-Präfix-IPv6-Adresse Deines Pi-Holes verwenden (klicken für mehr).
2003: - das ist mit einiger Wahrscheinlichkeit eine öffentlich sichtbare (nicht dasselbe wie erreichbare!) IPv6-Adresse mit einem seitens Deines ISP vergebenen Präfix.
Demgegenüber würden ULA-Adressen standardmässig mit fd00: und geräte-autark vergebene link-lokale Adressen mit fe80: beginnen.
ULA-Adressen sind gegenüber link-lokalen Adressen zu bevorzugen, da letzere nur in dem Netzwerksegment definiert sind, in dem sich das entsprechende Gerät befindet.
Beide Adresstypen sind wiederum einer öffentlichen IPv6-Adresse vorzuziehen, denn: Bei der üblichen täglichen Zwangstrennung kann Dein ISP das Präfix neu vergeben, wodurch die aktuell hinterlegte IPv6-Adresse ungültig würde.
Das bekommt man nicht einmal unmittelbar mit, aber Geräte mit bevorzugter IPv6-Nutzung könnten dann verstärkt an Pi-hole vorbeisegeln.
Smartphones sind geradezu berüchtigt dafür - und eine fehlerhafte oder im Lauf der Zeit ungültig gewordene IPv6-Adresse des Pi-holes kann ein Grund dafür sein.
Die Definition von Rebind-Schutz-Ausnahmen für Pi-hole ist in Deiner Konfiguration nicht erforderlich (klicken für mehr).
Der Rebind-Schutz veranlasst Deine FritzBox dazu, DNS-Antworten zu verwerfen, die Deine FritzBox auf eine Anfrage von einem DNS-Server erhält, sofern diese Antwort auf eine lokale IP-Adresse in Deinem Heimnetz verweist.
Theroretisch könnte Pi-hole solche Antworten an die FritzBox ausliefern.
Pi-hole wird aber in Deinem Setup gar nicht von der FritzBox befragt - Du hast 1.1.1.1 bzw. 1.0.0.1 und die IPv6-Pendants als Upstream-DNS-Server Deiner FB unter Internet | Zugangsdaten | DNS-Server eingetragen.
Die Ausnahme schadet aber auch nicht
DNSSEC erfordert eine genau gehende Uhr auf den beteiligten Rechnern.
Da ein RPi keinen RTC-Baustein besitzt, bezieht er die Uhrzeit periodisch aus dem Netz (klicken für mehr)
Zur Sicherheit schreibt die simulierte HW-Uhr des RPi außerdem alle paar Minuten einen Zeitstempel in eine Datei, um bei einem Neustart nicht mit einem Nullwert starten zu müssen.
Das funktioniert, solange man eine stabile Internetverbindung zu gut verfügbaren Zeitservern hat - und solange man den RPi nicht gewollt oder zwangsweise (Stromausfall z.B.) neu bootet.
Dann nämlich arbeitet der RPi mit einer bestenfalls um Minuten, je nach Abschaltdauer aber schlimmstenfalls um Stunden, Tage oder Wochen abweichenden Uhrzeit, und zwar solange, bis ein erneuter Snyc mit einem Zeitserver klappt.
In dieser Zeitspanne kann eine DNSSEC-Verbindung nicht zuverlässig ausgehandelt werden.
Installationen auf einem Rechner mit vorhandener RTC sind weit weniger anfällig für diese Probleme.
Streng genommen kannst Du in Deinem Setup auf Conditional Forwarding verzichten (klicken für mehr)
Zumindest, solange gleichzeitig Never forward reverse lookups for private IP ranges nicht gesetzt ist.
Du hast nämlich zuvor Deinen Fritzbox-Router als Upstream-DNS-Server für Deinen Pi-hole konfiguriert.
Hostnamen, die Pi-hole nicht auflösen kann, werden an die Upstream-DNS-Server weitergereicht - und Deine FritzBox kennt die Namen Deiner lokalen Clients. Das ist auch der Grund, warum ich dieses Setup für ganz robust halte und es selbst so fahre
2 Likes
@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