Brancheneinstufung2/duckdns_setup.md

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

docker logs dns-monitor

Szenario OK:

[TIMESTAMP] [OK] Pub: 87.x.x.x | CF: 87.x.x.x | Loc: 87.x.x.x

Szenario NETWORK_WAIT (Leitungsfehler):

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