Ich habe bei meinem Setup das Problem, dass trotz vermeintlich korrekter Einstellungen die Auflösung der privaten IP-Adressen in die Hostnames mit der Fritzbox nicht oder dubioserweise nur teilweise funktioniert.
Das Netzwerk ist wie folgt konfiguriert:
Adressbereich 10.0.0.0/23
Fritz!Box bei 10.0.0.1 als DHCP-Server
Pi-hole bei 10.0.0.2, wird über DHCP an die Clients verteilt
DNS-Trafficfluss: Clients > Pi-hole > Upstream
DHCP-Adressbereich von 10.0.1.1 bis 10.0.1.250
Conditional Forwarding aktiv (Einstellungen: 10.0.0.0/23, 10.0.0.1, fritz.box)
IPv6 mit Unique-Local-Präfix aktiv, DHCPv6 gibt nur das Pi-hole als DNS bekannt.
Dennoch werden bei fast allen Clients nur die IP-Adressen im Log angezeigt. Versucht man manuell mit einer Anfrage bei der FritzBox die IPs aufzulösen, funktioniert der Reverse Lookup nicht, obwohl ein Forward Lookup direkt die richtige IP zurück liefert:
Forward Lookup:
└─$ dig @10.0.0.1 Pixel-7-Pro
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> @10.0.0.1 Pixel-7-Pro
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; QUESTION SECTION:
;Pixel-7-Pro. IN A
;; ANSWER SECTION:
Pixel-7-Pro. 9 IN A 10.0.1.17
Reverse Lookup (keine Answer-Section und warning zu recursion?):
└─$ dig @10.0.0.1 -x 10.0.1.17
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> @10.0.0.1 -x 10.0.1.17
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44029
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;17.1.0.10.in-addr.arpa. IN PTR
Lediglich ein einziges Gerät in der Client-Liste wird mittels der IPv6-Adresse zum korrekten Hostnamen aufgelöst:
Danke! Das habe ich gemacht, was auch dazu geführt hat, dass manche Hostnames nun aufgelöst werden.
Allerdings sehe ich immernoch im Query Log Anfragen auf interne IPs, die folgendermaßen gelistet sind:
Die Conditional Forwarding Rule steht inzwischen auf 10.0.0.0/16 (damit sie durch 8 teilbar ist).
Es scheinen aber auch manuelle Anfragen zum Reverse Lookup der im Screenshot als Blocked (external, NXRA) aufgelisteten IPs fehlzuschlagen - auch mit dig auf die Fritz!Box gerichtet bekomme ich da keine Ergebnisse.
Es scheint mir also, als würde die Fritz!Box einfach manche der IPs im lokalen Netz nicht auflösen wollen - in der Client-Liste werden für manche Clients nämlich tatsächlich die Hostnames angezeigt, nur nicht für alle... mir ist rätselhaft, warum.
Der eingestellte Adressbereich müsste so passen - die FritzBox hat in den Netzeinstellungen die IP-Adresse 10.0.0.1 und eine Subnetzmaske von 255.255.254.0 (also das Netz 10.0.0.0/23).
Das wird auch so an die Geräte weitergegeben.
Der DHCP-Server vergibt dabei die Adressen zwischen 10.0.1.1 und 10.0.1.250, während das gesamte Netz ja 10.0.0.1-10.0.1.254 als Hostadressbereich umfasst (ich wollte eine einfach ersichtliche Trennung zwischen dynamisch vergebenen IPs/DHCP und statischen Hosts/meinen Servern/Netzwerkequipment).
Mit diesem /23er Subnetz liegt bei einem Reverse-Lookup von 10.0.1.x eine andere Zone beim in-addr.arpa-Record vor als bei 10.0.0.y. Für den Reverse Lookup müsste die FritzBox ja die zwei Zonen verwalten:
0.0.10.in-addr.arpa., und
1.0.10.in-addr.arpa.
Kann es sein, dass die FritzBox dieses Verhalten nicht richtig implementiert?
Das müsste sich durch ein paar DNS-Anfragen prüfen lassen.
Wird fritz.box von Pi-hole aufgelöst?
nslookup fritz.box
Dann könntest Du versuchen, die FitzBox direkt zu befragen:
nslookup 10.0.0.1 fritz.box
nslookup 10.0.1.1 fritz.box
Wenn fritz.box nicht aufgelöst wird, verwendest Du stattdessen die IP-Adresse der Fritzbox. Üblicherweise wäre das die .1, also wohl die 10.0.0.1, sofern in der FB nichts anderes eingestellt ist.
Der Reverse-Lookup auf ein und die selbe IP aber nicht:
└─$ nslookup 10.0.1.17 fritz.box
** server can't find 17.1.0.10.in-addr.arpa: NXDOMAIN
Und es wird noch besser:
Das Pi-hole hat eine tatsächlich statische IP (10.0.0.2), keine DHCP-Reservierung.
Ein Reverse-Lookup auf diese statische IP, die auch im Webinterface der FritzBox mit einem Hostname versehen ist, liefert kein Ergebnis:
└─$ nslookup 10.0.0.2 fritz.box
** server can't find 2.0.0.10.in-addr.arpa: NXDOMAIN
Even worse:
Ein Forward-Lookup auf den korrekten Hostname des Pi-hole (fluffy) liefert eine falsche Adresse, die auch nicht im Webinterface angezeigt wird
EDIT: Noch dazu: Pi-hole zeigt mir im Webinterface für manche Hosts den Hostname an (z.B. Flos-iPad-4 für 10.0.1.10 in der Client-Liste).
Ich verstehe allerdings auch dort nicht, wo die Info herkommt, da:
└─$ nslookup 10.0.1.10 fritz.box
** server can't find 10.1.0.10.in-addr.arpa: NXDOMAIN
Hat Dein Pi-hole-Rechner (bzw. das mit diesem verbundene Netzwerkinterface) vielleicht früher einmal in der FB diesen Namen getragen?
Dann könnte Deine letzte Beobachtung zu fluffy vielleicht daran liegen: Die FB merkt sich diese namentlichen Zuordnungen mitunter länger als erwartet. Mir ist leider keine explizite Möglichkeit bekannt, das über die FB-Oberfläche zurückzusetzen. U.U. lässt sich das durch temporäres Erweitern und Zurücksetzen des DHCP-IP-Bereichs erreichen.
Die anderen Ergebnisse sprechen sehr dafür, dass die Fritzbox mit den Rückwärtsanfragen für 'krumme' Netzmasken nicht korrekt umgeht.
Dies liesse sich durch Anlage von Local DNS Records in Pi-hole vermeiden.
Das würde allerdings nur für Geräte mit fixen IP-Adressen Sinn machen.
