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.