Floke
7405c2acb9
- Added analysis of latest DNS monitor logs (06.01.2026). - Refactored sync_docs_to_notion.py to be generic and support multiple files.
82 lines
4.8 KiB
Markdown
82 lines
4.8 KiB
Markdown
# DuckDNS & DNS Monitor Setup
|
|
|
|
**Erstellt am:** 05.01.2026
|
|
**Zuletzt aktualisiert:** 06.01.2026
|
|
**Status:** Aktiv
|
|
**Architektur:** Sidecar-Pattern
|
|
|
|
Dieses Dokument beschreibt die Docker-basierte Lösung zur DynDNS-Aktualisierung und Überwachung sowie die kritischen Netzwerkeinstellungen auf der Synology Diskstation und der FritzBox.
|
|
|
|
## Problembeschreibung
|
|
Das System litt unter massiven DNS-Problemen:
|
|
1. **"IP Flapping":** Die IP sprang ständig zwischen der aktuellen (`.252`) und der gestrigen (`.49`). Ursache war **aggressives Caching** der alten IP durch Google DNS (`8.8.8.8`) und falsche DNS-Einstellungen in der Synology, die diesen Cache abfragten.
|
|
2. **Interne Unerreichbarkeit:** Dienste waren im LAN nicht erreichbar (NAT Loopback Problem).
|
|
3. **Synology DNS-Chaos:** Die Synology nutzte veraltete DNS-Server (`8.8.8.8`) fest in der Netzwerkschnittstelle.
|
|
|
|
## Lösung
|
|
Wir haben eine robuste **Zwei-Container-Lösung** implementiert und das gesamte Netzwerk-Environment gehärtet.
|
|
|
|
### 1. Docker Services (`docker-compose.yml`)
|
|
|
|
* **Updater (`duckdns`):** Aktualisiert zuverlässig die IP bei DuckDNS. Wir nutzen einen **neuen Token**, um alle alten Updater auszusperren.
|
|
* **Monitor (`dns-monitor`):** Überwacht alle 5 Minuten die DNS-Auflösung via Cloudflare (`1.1.1.1`).
|
|
|
|
## Kritische Peripherie-Konfiguration (MUSS GEPRÜFT WERDEN!)
|
|
|
|
### 1. Synology DSM Netzwerkeinstellungen (Die "versteckte Falle")
|
|
Die Synology kann DNS-Server an zwei Orten haben. Die Schnittstellen-Einstellung überschreibt die allgemeine Einstellung!
|
|
|
|
* **Ort 1 (Allgemein):** Systemsteuerung -> Netzwerk -> Allgemein -> "DNS-Server manuell konfigurieren".
|
|
* **Ort 2 (Schnittstelle - WICHTIG):** Systemsteuerung -> Netzwerk -> Netzwerk-Schnittstelle -> LAN 1 -> Bearbeiten -> IPv4.
|
|
* **Fehler:** Hier war manuell `8.8.8.8` eingetragen.
|
|
* **Korrektur:** Auf "Automatisch abrufen" oder manuell auf `1.1.1.1` (Cloudflare) stellen.
|
|
|
|
### 2. FritzBox (Router)
|
|
* **DNS-Server:** Internet -> Zugangsdaten -> DNS-Server auf Cloudflare (`1.1.1.1`, `1.0.0.1`) stellen.
|
|
* **DNS-Rebind-Schutz:** Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> "DNS-Rebind-Schutz". Alle Subdomains eintragen (`floke.duckdns.org` etc.).
|
|
|
|
### 3. Hardware / DSL-Leitung (Physische Ursache für Timeouts)
|
|
Die FritzBox-Logs zeigen wiederkehrende DSL-Sync-Probleme und den Fehler:
|
|
> *"An der DSL-Leitung wurde eine Beeinträchtigung des Signals durch eine unzulässige Verkabelung erkannt. [...] Die Abzweigung ist 17 Meter lang."*
|
|
|
|
Dies deutet auf eine **Stichleitung/Parallelschaltung** in der Hausverkabelung hin. Dies verursacht Signalreflexionen, Paketverluste und Timeouts (`NETWORK_WAIT` im Monitor).
|
|
**Empfehlung:** Hausverkabelung prüfen (lassen) und ungenutzte Telefondosen abklemmen.
|
|
|
|
## Logs & Monitoring
|
|
|
|
### DNS-Konsistenz prüfen
|
|
```bash
|
|
docker logs dns-monitor
|
|
```
|
|
|
|
**Szenario OK:**
|
|
```text
|
|
[TIMESTAMP] [OK] Pub: 87.x.x.x | CF: 87.x.x.x | Loc: 87.x.x.x
|
|
```
|
|
|
|
**Szenario NETWORK_WAIT (Leitungsfehler):**
|
|
```text
|
|
[TIMESTAMP] [NETWORK_WAIT] Pub: 87.x.x.x | CF: Unresolved | ...
|
|
```
|
|
Häufig verursacht durch DSL-Resyncs oder Paketverlust wegen der Stichleitung.
|
|
|
|
## Aktueller Status (06.01.2026)
|
|
|
|
Basierend auf den Logs des `dns-monitor` (Stand 20:34 Uhr) ergibt sich folgendes Bild:
|
|
|
|
### 1. Analyse der Log-Phasen
|
|
* **Vormittag/Nachmittag:** Sporadische `[ALERT]`-Meldungen. Die IP bei DuckDNS sprang kurzzeitig auf die veraltete Endung `.49` zurück, stabilisierte sich aber meist nach 5-10 Minuten wieder auf `.252`.
|
|
* **Kritische Phase (19:38 - 19:54 Uhr):** Ein 20-minütiger anhaltender Alert. Cloudflare (`CF`) lieferte hartnäckig die alte IP `.49`, obwohl die öffentliche IP (`Pub`) bereits `.252` war. Dies deutet auf eine verzögerte TTL-Aktualisierung oder einen "Zombie-Updater" im Netzwerk hin, der kurzzeitig erfolgreich war.
|
|
* **Stabilisierung (seit 19:59 Uhr):** Das System ist seit über 30 Minuten durchgehend im Status `[OK]`. Sowohl Cloudflare als auch die lokale Auflösung zeigen stabil auf die `.252`.
|
|
|
|
### 2. Erkenntnisse
|
|
* **Netzwerk-Instabilität:** Die `[NETWORK_WAIT]` Einträge korrelieren mit den DSL-Sync-Problemen der FritzBox. In diesen Momenten ist keine DNS-Abfrage möglich (Paketverlust).
|
|
* **Local Cache Lag:** Die Spalte `Loc` (Lokale Auflösung) zeigt oft noch `Unresolved` oder die alte IP, wenn Cloudflare bereits korrekt ist. Dies bestätigt, dass der interne DNS-Cache der Synology/Docker-Umgebung deutlich träger reagiert als externe Server.
|
|
|
|
### 3. Empfehlung
|
|
* **Beobachtung:** Da die Stabilisierung seit 19:59 Uhr anhält, scheint der neue DuckDNS-Token nun die Oberhand gewonnen zu haben.
|
|
* **Hardware:** Die physische DSL-Beeinträchtigung (Stichleitung 17m) bleibt das primäre Risiko für die `NETWORK_WAIT` Timeouts.
|
|
|
|
## Dateien
|
|
- `/app/docker-compose.yml`: Definition der Services.
|
|
- `/app/dns-monitor/monitor.sh`: Das Shell-Skript für den Monitor-Container. |