Mir ist heute aufgefallen, dass der Pi-hole PTR request für eine ULA an den Upstream DNS weiterleitet obwohl Conditional Forwarding aktiv ist, somit sollte das eigentlich an den lokalen router gehen.
nslookup fd00::20c:11xx:22yy:8z99
Server: pi-hole
Address: fd00::20c:11xx:22yy:8z99
*** fd00::20c:11xx:22yy:8z99 wurde von pi-hole nicht gefunden: Non-existent domain.
Und hier der Eintrag aus dem Pi-hole log
dnsmasq[7699]: query[PTR] 9.9.z.8.y.y.2.2.x.x.1.1.c.0.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa from fd00::78hd:92ej:29af:2d2f
dnsmasq[7699]: forwarded 9.9.z.8.y.y.2.2.x.x.1.1.c.0.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa to ::1
dnsmasq[7699]: forwarded 9.9.z.8.y.y.2.2.x.x.1.1.c.0.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa to to 127.0.0.1
dnsmasq[7699]: reply fd00::20c:11xx:22yy:8z99 is NXDOMAIN
Du kannst das über Settings | DNS unterbinden, indem Du Never forward reverse lookups for private IP ranges anhakst.
Auch die darüber angezeigte Option Never forward non-FQDNs würde ich anhaken, sofern für Pi-hole öffentliche Upstream-DNS-Server konfiguriert sind (in Deiner Konstellation indirekt via unbound), da reine Hostnamen (also z.B. laptop oder pi-hole) in aller Regel ohnhehin nur lokal bekannt sind.
Unabhängig von Deiner Frage ist mir in Deinem Debug Log noch folgendes aufgefalllen (klicken für Details)
Zeigt Pi-hole in seinen Upstream DNS Servers tatsächlich keine Ports an?
Dann solltest Du die dort (wieder) ergänzen, damit die Anfragen auch entsprechend an unbound gehen, d.h: 127.0.0.1#5353.
Und noch ein Hinweis zum verwendeten Port: 5353 ist der Standard-Port für mDNS. Das ist ein für lokale Namensauflösung und Dienste-Erkennung insbesondere von Apple-Geräten verwendetes Protokoll, das z.B. von Bonjour und Avahi implementiert wird.
Um potentielle Seiteneffekte oder Störungen bei Verwendung von Apple-Geräten in Deinem Netzwerk zu vermeiden (und ggf. um Netzwerk-Analysetools nicht zu verwirren), würde ich einen anderen Port verwenden, z.B. 5153.
Problem ist ja nicht, dass Pi-hole diese forwarded, sondern das sie an den falschen resolver forwarded werden, statt an den upstream resolver müssten diese wie private IPv4 Adressen an den localen resolver forwarded werden, was Pi-hole ja bei IPv4 bei aktiviertem "Conditional Forwarding" auch tut.
Ich habe die beiden Optionen aktiviert, aber dennoch löst Pi-hole ULA´s nicht auf, weswegen auf dem Dashboard die ULA´s statt der Hostnamen angezeigt werden.
nslookup fd00::xx9x:xxxx:xx67:b4xx
Server: pi-hole
Address: fd00::xx9x:xxxx:xx67:b4xx
*** fd00::xx9x:xxxx:xx67:b4xx wurde von pi-hole nicht gefunden: Non-existent domain.
nslookup fd00::xx9x:xxxx:xx67:b4xx 192.168.2.1
Server: fritz.box
Address: 192.168.2.1
Name: DS-P51.fritz.box
Address: fd00::xx9x:xxxx:xx67:b4xx
Das sind zwei separate Probleme, von denen wir das erste gelöst haben:
a) ungewollte Weiterleitung an den Upstream-Server (gelöst durch bogus-priv)
b) fehlende Auflösung von lokalen IPv6-Adressen
b) wird in der Tat für IPv6 von Pi-hole noch nicht vollständig unterstützt.
Du kannst manuell folgende Zeile zur dnsmasq-Konfiguration hinzufügen (z.B. in /etc/dnsmasq.d/90-reverse-ipv6.conf):
Das wird aber dennoch nicht für alle Geräte die gewünschte Namensauflösung bringen.
Grund hierfür ist IPv6 selbst, das auf geräte-autarke Verfahren zur Netzwerkintegration setzt.
Dabei entscheidet das Gerät selbst (oder besser gesagt, sein Betriebssystem), welches Verfahren verwendet wird: SLAAC bzw. Stateless oder Stateful DHCPv6.
Während z.B. Windows-Geräte DHCPv6 bevorzugen, unterstützen Android-Geräte ausschliesslich SLAAC. Und bei SLAAC bleiben lokale Hostnamen aussen vor, während DHCPv6 dies in RFC4704 regelt.
Für Android-Smartphones wirst Du über CF also keine Hostnamen erhalten, es sei denn, Deine Router-Firmware verwendet entsprechende Tools, die diese Lücke schliessen (z.B. ip6neigh für OpenWRT).
Um dies auszugleichen, kannst Du Hostnamen für IPv6-Adressen in /etc/hosts/ definieren.
Habe das jetzt so eingetragen allerdings statt der IPv4 die ULA der FritzBox und es funktioniert
Als Lösung bräuchte man beim Conditional Forwarding ja nur 2 IP Felder jeweils für IPv4 & IPv6 (ULA)
Bei aktiver Privacy Extensions leider nicht praktikabel, da sich der Interface Identifier ja ständig ändert.
Kannst Du so machen, ist absolut gleichwertig zur IPv4-Adresse (oder anders gesagt: egal ).
Und natürlich müsste bei anderen Konfigurationen die Domäne für den Reverse Lookup entsprechend der jeweiligen ULA angepasst werden.
Das obige Beispiel habe ich extra für Dich aus den Daten in Deinem Debug Log abgeleitet.
Diesbezüglich ist bereits eine Anpassung in Arbeit.
Das hängt von der von Deinen Clients verwendeten SLAAC-Implementierung ab.
Sofern z.B. RFC 7217 unterstützt wird, können private Adressen stabil bleiben (also bei Dir fe80: und fd00:). Globale IPv6-Adressen (2000::/3) bleiben natürlich aussen vor, da hat aber Dein ISP ggf. Kontrolle über die Namen.
Mein Pi-hole-RPi läuft jedenfalls schon lange mit derselben ULA-Adresse.
Wenn die Privacy Extensions aktiv ist (slaac privat) werden temporäre Adressen verwendet.
Wenn deaktiviert (slaac hwaddr) dann ist die ULA statisch und beinhaltet die MAC Adresse der NIC
Bei slaac privat ist es gerade gewollt, dass der Interface Identifier wechselt um eine Identifizierung des Client zu erschweren.
The method specified in this document is orthogonal to the use of temporary addresses [RFC4941], since it is meant to improve the security and privacy properties of the stable addresses that are employed along with the aforementioned temporary addresses.
Privacy Extensions und stabile private Adressen schliessen sich also nicht aus.
Unter Raspbian z.B. editiert man für RFC7217-Adressen etc/dhcpcd.conf und setzt slaac private, siehe auch
man dhcpcd.conf
slaac [hwaddr | private]
Selects the interface identifier used for SLAAC generated IPv6 addresses. If private is used, a RFC7217 address is generated.
Nein, das sind genau die stabilen RFC7217-Adressen.
Kurze Frage, bitte:
Auch bei mir werden die kryptischen IPv6-Namen im dashboard angezeigt, wobei eine FritzBox verwendet wird, die weiterhin der DHCP-Server ist.
Ich habe nun versucht, via Terminal folgendes zu machen:
editieren -> sudo nano /etc/dnsmasq.d/90-reverse-ipv6.conf
einfügen -> server=/0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa/192.168.2.1
Jedoch gibt es in dem Verzeichnis lediglich die Datei 01-pihole.conf. Dort sollte man es wahrscheinlich nicht eintragen. Wo dann ?
Und, muss ich die Einfügezeile anpassen, wenn die FritzBox bei 192.168.178.1 liegt ? Nochwas anpassen ?
Dann wurde geschrieben, die ungewollte Weiterleitung an den Upstream-Server sei gelöst. Wo finde ich diese Lösung ?
Wenn du die FritzBox als Upstream DNS verwendest, solltest du diesen Eintrag nicht machen müssen, dieser ist nur erforderlich, wenn dein Pi-hole nicht die FritzBox als Upstream DNS verwendet.
In die Datei 01-pihole.conf sollte man keine manuellen Einträge machen, denn die Datei wird vom Pi-hole ggf überschrieben.
Daher eine neue Datei anlegen z.B. 90-reverse-ipv6.conf
Der Befehl
sudo nano /etc/dnsmasq.d/90-reverse-ipv6.conf
sollte das eigentlich auch tun, sofern man das speichern am ende nicht vergisst.
Ja und nein, Windows 10 z.B. verwendet jeweils eine statische private Adressen für ULA & GUA aber auch jeweils eine Temporäre Adresse für ULA & GUA und diese werden bevorzugt genutzt und ändern sich alle 24 Std.
Mit slaac [hwaddr|private] kontrollierst Du auf Deinem Pi-hole-Rechner den Wechsel zwischen EUI-64 und stabiler privater RFC7217-Adresse (die eben gerade keine temporären PE-Adresse ist).
Die Frage dreht sich aber eigentlich darum, ob man durch Einträge in hosts für eine bessere Namensauflösung sorgen kann.
Und hier macht ein Eintrag einer temporären PE-Adresse wenig Sinn, aber bei Verwendung der stabilen lokalen IPv6-Adressen (egal ob EUI-64 oder RFC7217) lässt sich durchaus eine Verbesserung erzielen.
Unter Windows (mindestens ab W7) könntest Du ggf. noch versuchen, über gezielte Anpassung von Prioritäten für prefix policies eine Änderung zu erreichen. Die vorhandenen lassen sich wie folgt anzeigen:
netsh interface ipv6 show prefixpolicies
Änderungen gehen über set, für das Du die Hilfe wie folgt aufrufst:
netsh interface ipv6 set prefixpolicy ?
Allerdings habe ich selbst noch nie etwas an diesen Rangfolgen verändert
Auch das habe ich selbst noch nicht ausprobiert.
Eventuell ergänzt Windows diese Adresse umgehend oder nach einem Neustart auch einfach wieder.
(Alle angeführten netsh-Kommandos gehen zudem auch deutlich über Pi-hole hinaus ).
Komplett auflösen lassen wird sich das wegen der Unstimmigkeiten in IPv6 bezüglich der lokalen Namensvergabe allerdings nie vollständig.
Pi-holes Entwickler tun hier das bestmögliche, um Verbesserungen herauszuholen, die die Protokolle alleine nicht hergeben, z.B. im verbesserten Network overview in Pihole 5.
).