Heute ist mir aufgefallen, dass mein Blog plötzlich nicht mehr erreichbar war, während meine eigentliche Webseite weiterhin problemlos funktionierte. Da beide Dienste über dieselbe öffentliche IP erreichbar sein sollten, habe ich im Dynu-Control-Panel nachgesehen.

Dort zeigte sich, dass die IP-Adresse der Blog-Domain nicht aktualisiert worden war. Beide Domains befanden sich zwar in derselben Dynu-Gruppe, dennoch war nur die Domain der Hauptwebseite auf die aktuelle IP gesetzt. Ich war zuvor davon ausgegangen, dass ein Update durch den Router automatisch alle Domains innerhalb einer Gruppe aktualisiert.

Diese Annahme stellte sich als falsch heraus. Insbesondere bei Routern mit stark eingeschränkter Dynamic-DNS-Unterstützung wird ein Gruppen-Update nicht automatisch ausgelöst. Genau dieser Umstand führte dazu, dass der Blog zeitweise nicht erreichbar war.

Der folgende Artikel erläutert, warum dieses Verhalten auftritt und wie sich das Problem mit einer sauberen und zuverlässigen Lösung beheben lässt.

Problemstellung

Viele Router unterstützen Dynamic DNS (DDNS) nur sehr eingeschränkt. Typischerweise lassen sich dort nur folgende Felder konfigurieren:

  • Service‑Anbieter (z. B. Dynu)
  • Hostname
  • Username
  • Kennwort

Was nicht möglich ist:

  • eigene Update‑URLs
  • zusätzliche Parameter wie group=…

Das wird zum Problem, wenn man mehrere Dynu‑Domains besitzt, die alle auf dieselbe öffentliche IP zeigen sollen, der Router aber nur eine Domain aktualisieren kann.

Dieser Artikel zeigt eine saubere, stabile Lösung, die ohne Router‑Hacks funktioniert.

Warum Dynu‑Gruppen alleine nicht reichen

Dynu bietet zwar sogenannte Groups, in denen mehrere Domains zusammengefasst werden können. Wichtiges Detail:

Ein Gruppen‑Update wird nur dann ausgelöst, wenn die Dynu‑API explizit mit dem Gruppen‑Parameter (group=) aufgerufen wird.

Ein normales Router‑Update mit hostname=domain.freeddns.org:

  • aktualisiert nur diese eine Domain
  • triggert kein Gruppen‑Update

Das Verhalten ist korrekt, aber schlecht dokumentiert und führt daher oft zu Verwirrung.

Die Lösung: Externes Gruppen‑Update per Skript

Statt den Router zu verbiegen, übernimmt ein kleines Skript das eigentliche Dynu‑Gruppen‑Update.

Vorteile:

  • unabhängig vom Router
  • zuverlässig
  • vollständig automatisierbar (Cronjob)
  • funktioniert mit allen Dynu‑Accounts, die Groups unterstützen

Voraussetzungen

  • Dynu‑Account
  • Dynu‑Gruppe (z. B. gleicherrouter) mit mehreren Domains
  • gesetztes Gruppen‑Passwort
  • Linux‑System (z. B. Debian, Server, NAS, Raspberry Pi)

Bash‑Skript für Dynu‑Gruppen‑Update

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

#!/bin/bash

# Dynu Zugangsdaten
USERNAME="DEIN_DYNU_USERNAME"
GROUP="gleicherrouter"
PASSWORD="DEIN_GRUPPENPASSWORT"

# Passwort URL‑encoden (wichtig bei Sonderzeichen)
PASSWORD_ENCODED=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$PASSWORD'))")

# Öffentliche IPv4 ermitteln
IP=$(curl -s https://api.ipify.org)

# Dynu Gruppen‑Update
URL="https://api.dynu.com/nic/update?username=$USERNAME&group=$GROUP&password=$PASSWORD_ENCODED&myip=$IP"

RESPONSE=$(curl -s "$URL")

echo "$(date '+%Y-%m-%d %H:%M:%S') - $RESPONSE" >> ~/dynu_group_update.log

Datei ausführbar machen:

1

chmod +x ~/dynu_group_update.sh

Typische Dynu‑Antworten im Log

  • good x.x.x.x → IP wurde aktualisiert
  • nochg → IP hat sich nicht geändert (kein Fehler)
  • badauth → falsches Passwort
  • nohost → Gruppe existiert nicht

nochg ist der Normalfall, wenn sich die IP nicht geändert hat.

Automatisierung per Cronjob (jede Stunde)

Cronjob öffnen:

1

crontab -e

Eintrag hinzufügen:

1

0 * * * * /home/DEINUSER/dynu_group_update.sh

Ergebnis:

  • einmal pro Stunde wird die Dynu‑Gruppe aktualisiert
  • alle Domains zeigen immer auf dieselbe IP

Warum das besser ist als Router‑DDNS

  • keine Router‑Abhängigkeit
  • volle Kontrolle über Dynu‑API
  • transparentes Logging
  • leicht erweiterbar (IPv6, IP‑Change‑Detection, etc.)