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.
).