[Problem] FB6660 DNS reverse lookup lokaler IP's kaputt

[HohDen]

Hallo Zusammen,

meine FB6660 FW7.57 treibt mich seit gestern in den Wahnsinn. 2 Jahre lang hat alles ohne Probleme funktioniert und aus heiterem Himmel ist gestern scheinbar der interne DNS gestorben.
Mein Setup:
FB6660 (192.168.178.1) als DCHP, DNS via PiHole, NodeRed, Mosquitto, (alles Docker) auf einem RPi4 (192.168.178.10). Wöchentlicher Reboot (Montags Früh um 3Uhr)
Heimnetz, Multimedia, Firmennetz getrennt 192.168.178.0/21
Im PiHole keine lokalen DNS Einträge, "Conditional Forwarding" aktiv auf 192.168.178.0/21, 192.168.178.1, fritz.box

Gestern Nachmittag aus heiterem Himmel war plötzlich eine Steckdose nicht mehr erreichbar, innerhalt kürzester Zeit waren dann alle (12) "weg".
Lange Rede, es lag nicht an den Steckdosen, es liegt am FritzBox internen DNS.
Hier alles gut:


Von jetzt auf gleich:


Gerät ist da

Und direkt an der FB abgefragt erhalte ich diesen "Mist". Das hat 1000% funktioniert.


Jetzt wird es richtig spannend. In meiner Verzweiflung habe ich dann heute Nacht eine Sicherung von vor 6 Monaten in die FB eingespielt. Nach dem Wiederherstellen lief es etwa 10 Minuten und dann aus dem Nichts, wieder nicht mehr... Selbes wenn ich die FB komplett neu aufsetzte und nur Laptop und eine Steckdose verbinden.

Auch das komplette "trennen" des Raspi und zurückstellen der FB-DNS Einträge (FB als DNS mit 192.168.178.1) hat nichts geändert. Die FB löst die IPs (betrifft ALLE ca. 65 Geräte) einfach nicht mehr auf.
An meinem Setting habe ich mind. 6 Monate nichts mehr verändert. Das letzte RPi- und der Docker-Container-Update ist etwa 4 Wochen her, die Konfigs haben sich nicht geändert.
Im Laufe des gestrigen Abends gab es auch unzählige Neustarts, teils sogar durch gezogenem Stecker und länger als 5 Minuten. Nichts hat geholfen.

Hat irgendjemand eine Idee oder einen heißen Tipp? Gibt's ne Möglichkeit irgendwie den internen DNS zu resetten? Verstellen der DCHP-Lease-Dauer, bzw. des Bereichs bringt auch nix.
Früher konnte man ja noch per SSH auf die FB, geht inzwischen ja auch nicht mehr...

Danke schonmal im Voraus, auch fürs lesen ;-)

 

[tango501]

Hallo HohDen, willkommen hier im Forum.
Da der Zeitpunkt des Problems ungefähr bekannt ist, welche Einträge stehen zeitlich dazu in der GUI der 6660 unter "System - Ereignisse - Alle"? Gerne die Einträge daraus hier posten.

 

[HohDen]

Hallo tango501,

laut Logs gab's "nur" 2 Kabel-Ausfälle zu der Zeit. Das ist leider nichts neues und kommt, seitdem der Bagger im Juli in der Straße Glasfaser verlegt hat, öfters vor.
Die Kabel-Ausfälle hatten bisher im internen Netzwerk noch nie Auswirkungen.
NodeRed hat mich um 15:29Uhr informiert das mind. eine Steckdose seit >= 5 Minuten nicht erreichbar ist. Um 15:33Uhr habe ich mich Remote eingeloggt und um 15:41Uhr habe ich dann die FB neu gestartet.

 

[PeterPawn]

Ich würde - wenn ich schon 8 Subnetze mit je 256 (möglichen) Hosts brauche (daher ja hoffentlich die 21-bittige Netzwerk-Maske) - dafür ein Segment wählen, was sich eben gerade NICHT mit den intern von AVM verwendeten ins Gehege kommen kann.

Zwar weicht die Firmware beim Gastnetz (normalerweise ja 192.168.179.0/24 und nicht explizit durch den Benutzer konfigurierbar) auf andere Adressen aus, wenn dieses Netz über dev lan (eine Bridge im FRITZ!OS) erreichbar sein sollte (weil die IP-Konfiguration oder explizit gesetzte LAN-Routen dafür sorgen), aber m.W. ist es bei den "internen" DNS-Servern immer noch so, daß die - ohne daß man das irgendwo im GUI sehen würde - unter den Adressen 192.168.180.1/32 und 192.168.180.2/32 in der Routing-Table hinterlegt sind und an dev dsl gehen. Damit sind diese Adressen aus dem FRITZ!OS heraus nicht erreichbar - was dann auf Geräten mit diesen Adressen auch alles an Mechanismen aussteigen läßt, was mit "broadcasted annoucements" und anschließendem unidirektionalen Dialog arbeitet (wie z.B. DLNA bzw. UPnP).

Gleichzeitig besteht eben auch die Gefahr, daß für diese Netzsegmente irgendwelche internen Änderungen in der Firmware zu einem veränderten Verhalten führen - als Beispiel sei hier die "Erkennung", ob ein Request aus dem LAN kommt oder von der WAN-Seite, wo dann bestimmte Ergebnisse (die Aufschluß über den internen Aufbau des LAN geben könnten) blockiert werden, genannt.

Daher würde ich bei einer "ungewöhnlichen" Netzwerk-Konfiguration (und eine /21-Maske gehört dazu) dann auch generell NICHT weiterhin das Segment 192.168.178.0 benutzen, sondern so ausweichen, daß KEINE Adressen zwischen 192.168.178.0 und 192.168.189.255 (letzteres als Gastnetz bei einer Box im Router-Modus über LAN1 bzw. WAN, wenn vorhanden) enthalten sind.

Die Supportdaten geben genauere Auskunft darüber, was der DNS-Server im FRITZ!OS an Zuordnungen "kennt" und von wo diese abgefragt werden dürfen. Da (also in den Supportdaten) dürften sich auch bei Deiner Konfiguration die zwei Einträge für 192.168.180.1/32 und 192.168.180.2/32 in der Routing-Table finden lassen, die - zumindest beim Kontakt mit Software in der FRITZ!Box selbst, denn der Rest wird ja nur "geswitched" - für ggf. aufgetretene Probleme bei Geräten mit diesen Adressen verantwortlich sind.

Die geschilderten Symptome lassen mich jedenfalls vermuten, daß da irgendwelche Geräte aus den zusätzlichen Segmenten über entsprechende Broadcasts nach einiger Zeit den DNS-Server in der Box soweit "verwirrt" haben, daß der die Quelle von Abfragen nicht mehr korrekt zuordnen kann und Reverse-Abfragen dann blockiert. Da der verantwortliche Daemon im FRITZ!OS (der nennt sich multid) sich seine Sicht auf die Geräte im LAN aus mehreren Quellen zusammenbaut (DHCP, mDNS, andere Broadcasts), läßt sich auch nicht immer 100% klären (ohne die Supportdaten jedenfalls nicht), wie die resultierende Konfiguration entstanden ist.

Je nachdem, wie da die intern gespeicherten in-addr.arpa-Zonen aussehen, könnte es sogar sein, daß für die 180.168.192.in-addr.arpa tatsächlich keine Zone existiert, weil der multid beim Start nur die 178.168.192.in-addr.arpa angelegt hat (auf der Basis der Segmentadresse und ohne Berücksichtigung der Maske) und darin eine 192.168.180.20 nicht gesucht wird, selbst wenn sie dort registriert sein sollte (als "absoluter" PTR-Eintrag ginge das ja zumindest in der Theorie).

Aber - wie geschrieben - das kannst Du problemlos (auch bei einer 6660 und ohne Shell-Zugriff) aus den Supportdaten ablesen, wo es da klemmt und um Dir da mit weiteren Ideen zu helfen, braucht es ohnehin diese Daten aus der Supportdatei.

Das "grundsätzliche Problem" mit den Netzwerk-Segmenten, die mit intern genutzten Adressen überlappen, würde ich bei der nächsten Gelegenheit an Deiner Stelle aber auch angehen, wenn die Geräte (konsequent) per DHCP konfiguriert werden - dann wäre das ja nur ein Umkonfigurieren des Routers und ein (anschließender) Neustart aller vorhandenen Clients. Damit ist man dann auch gegen künftige (dokumentierte und undokumentierte) Änderungen seitens AVM gefeit - wenn sich doch wieder mal etwas an den internen Abläufen ändern sollte (was vermutlich in den aktuellen Labor-Versionen schon erfolgt ist, wenn man die (Kurz-)Beschreibungen der Änderungen berücksichtigt).

 

[HohDen]

Hallo PeterPawn,

zunächst erstmal vielen Dank für deine ausführliche Erläuterung!
Ich hoffe die DNS Sections der Supportdaten sind erstmal ausreichend?

 

[PeterPawn]

Da sehe ich nicht wirklich etwas Besonderes (EDIT: der Anhang wurde wohl inzwischen entfernt/korrigiert, da die IPv6 und anderes noch abzuleiten waren) - nur die Tatsache, daß die Einträge für die 192.168.180.20 offenbar NICHT per mDNS erlernt wurden, was bei mir anders ist.

Sind eigentlich die lokal im LAN vergebenen Adressen "fixiert" in der FRITZ!Box (aka "immer dieselbe Adresse zuweisen")? (Ja, sind sie, wie ich aus einer "conversation" inzwischen weiß.)

Ich bleibe - bis zum Beweis des Gegenteils - mal bei meiner Vermutung/These, daß irgendwann die IP-Adresse des (den DNS-Server) abfragenden Clients nicht mehr unter "Zugriff erlaubt" eingeordnet wird und dann etwas in der Art des "Never forward reverse lookups for private IP ranges" bei Pi-hole (hier bei AVM ggf. als "do not answer …" gesehen) greift.

Daher würde ich das zunächst mal mit verschiedenen Adressen aus den acht /24-Subnetzen (192.168.176.0/24 bis 192.168.183.0/24) systematisch abfragen und damit testen. Zumal hier ja noch dazukommt, daß - durchaus auch ungewöhnlich, wenn auch nicht direkt "verboten" - die Box selbst eine IP-Adresse mittendrin im Segment verwendet (auf der viele der internen Tests basieren).

Da braucht bloß irgendwo jemand in einer Software von der Annahme ausgehen, daß auch bei einer Maske abweichend von /24 das erste der daraus abgeleiteten /24-Netze das "Stammnetz" sein müsse und schon geht das für eine Adresse aus 192.168.178.0/24 (oder "noch weiter hinten") schief, weil das "erst" das dritte /24-Segment in der Range ist.

Warum das aber erst in jüngster Zeit auftritt, kann ich auch nur vermuten - hier würde ich am ehesten auf Änderungen (Updates) "unter der Haube" tippen, die Du nicht bemerkt hast oder die Du nicht als relevant ansiehst (egal bei welcher Komponente im Netz).

EDIT: Da die Box die IP-Adressen hier ja "fest" vergibt, ist die funktionierende Abfrage für den Namen m.W. KEIN Beweis dafür, daß das fragliche Gerät auch wirklich im Netzwerk aktiv und erreichbar ist. Wenn sich die "reverse"-Sicht der Box auf den aktuellen Zustand des Netzes beziehen sollte (einfach testen) und der aus den "neighborhood"-Informationen dynamisch generiert würde, könnte mangelnder Kontakt von Clients mit der Box auch irgendwann zum "Vergessen" von "reversen" Zuordnungen führen. Auch das ist leicht zu testen - dazu müßte man nur von einem solchen Client (der ansonsten nicht über den Router geht - gerade bei SmartHome-Clients mit einer Zentrale im LAN ja nicht ganz ungewöhnlich - und für den die Auflösung irgendwann nicht (mehr) funktioniert) mal wieder auf das Internet zugreifen (meinetwegen die OTA-Update-Suche bei Tasmota per WebGUI) und danach prüfen, ob er nun (irgendwann) wieder aufgelöst wird.

EDIT2: Bei Cable-Boxen sollte man auch dem 192.168.100.0/24-Netz aus dem Weg gehen, da die IP-Adresse 192.168.100.1 in den DOCSIS-Spezifikationen eine besondere Definition hat und Cable-Router diese Adresse oft auch "versteckt" verwenden.