Hostnameauflösung in Client-Liste mit fritz.box

Hallo zusammen!

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:

└─$ dig @10.0.0.1 +short -x fd49:f1b3:bed4:0:9826:1bfb:ce74:1769                          2 ⨯
DESKTOP-6I6RSUH.fritz.box.

Hier das Debug-Token:
https://tricorder.pi-hole.net/Fq2PpsGG/

Ich kann mir den Fehler in der Konfiguration nicht erklären.
Muss ich hier etwas anders einstellen?

Vielen Dank!

Ich denke, du bist von diesem Bug betroffen:

Der Bug existiert in FTL, dass auf dnsmasq aufsetzt. Der Bug ist behoben, aber noch nicht in einer neuen FTL version released.

Versuch mal, im Conditional Forwarding 10.0.0.0/16 einzusetzen...

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:

PTR 17.1.0.10.in-addr.arpa
Blocked (external, NXRA) -> NXDOMAIN

Gehe ich richtig in der Annahme, dass die IP aus irgendeinem Grund von der Fritz!Box nicht aufgelöst wird?

Diese Anfrage ist tatsächlich von extern geblockt worden. Gingen denn die geblockten Anfragen an die FB oder einen anderen upstream DNS server?

Die gingen an die Fritz!Box - also zumindest tun das die anderen PTR-Queries zu den Local IPs:

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.

Das sieht so aus, als verweigerte die Fritzbox die Auskunft.

Eventuell ist das in der DHCP-Konfiguration der FritzBox eingestellte Subnetz das Problem - der DHCP-Bereich würde auf 10.0.1.0/24 deuten?

Was war denn die Motivation für die Verwendung von 10.0.0.0/23 in Pi-holes Conditional Forwarding?

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.

Das Pi-Hole löst die FritzBox problemlos auf:

└─$ nslookup fritz.box pi.hole                                                          130 ⨯
Server:		pi.hole
Address:	<ipv6-of-the-pihole>#53

Name:	fritz.box
Address: 10.0.0.1

Nun – bear with me:

Die FritzBox wiederum löst sich selber auf:

└─$ nslookup 10.0.0.1 fritz.box
1.0.0.10.in-addr.arpa	name = fritz.box.

Mein Handy per Forward Lookup funktioniert (Hostname ist der FritzBox also bekannt):

└─$ nslookup Pixel-7-Pro fritz.box
Server:		fritz.box
Address:	<local-ipv6-of-the-fritz-box>#53

Name:	Pixel-7-Pro.fritz.box
Address: 10.0.1.17

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 :thinking:

└─$ nslookup fluffy fritz.box                                                             1 ⨯
Server:		fritz.box
Address:	<ipv6-of-the-fritz-box>#53

Name:	fluffy.fritz.box
Address: 10.0.1.27

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.

Kann nicht sein, da die FB neu gekauft ist.

Spannend! Dann war das evtl. die Adresse, die der Pi während des Setups bekommen hat.

Alles klar. Ich denke dann werde ich da mal etwas experimentieren... Danke schonmal auf jeden Fall!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.