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