UGREEN NAS: DDNS für die eigene Domain einrichten

Ihr Internetanschluss bekommt bei den meisten Privatanschlüssen von Zeit zu Zeit eine neue IP-Adresse. Wer die UGREEN NAS von unterwegs erreichen will, etwa über ein VPN, braucht deshalb einen Namen, der immer auf die aktuelle Adresse zeigt. Genau das erledigt DDNS. Diese Anleitung zeigt die DDNS-Funktion von UGOS Pro und richtet für eine eigene Domain einen kleinen Docker-Container ein, der den Eintrag beim Domain-Anbieter selbst aktuell hält. Als Beispiel dient netcup, das UGOS nicht direkt unterstützt.

Voraussetzungen

• Eine UGREEN NAS mit der App Docker, siehe Teil 63
• SSH-Zugang, siehe Teil 52
• Für den Container-Weg eine eigene Domain mit Zugang zur Verwaltung beim Anbieter, im Beispiel netcup mit CloudDNS
• Etwa 30 Minuten

Schritt 1: Prüfen, ob DDNS bei Ihrem Anschluss hilft

DDNS trägt die öffentliche Adresse Ihres Routers in das DNS ein. Das bringt nur etwas, wenn diese Adresse wirklich bei Ihnen ankommt. Manche Anschlüsse, häufig bei Glasfaser und Kabel, teilen sich eine IPv4-Adresse mit anderen Kunden. Die Fachbegriffe dafür sind DS-Lite und Carrier-Grade-NAT. Dann führt kein Weg von außen über IPv4 zu Ihrem Router. Fragen Sie per SSH auf der NAS ab, welche Adresse das Internet sieht:

curl -4 https://api.ipify.org; echo

203.0.113.25

Vergleichen Sie die Zahl mit der IPv4-Adresse, die Ihr Router auf seiner Übersichtsseite für die Internetverbindung anzeigt. Stimmen beide überein, haben Sie eine eigene öffentliche Adresse. Zeigt der Router eine andere Adresse, etwa eine zwischen 100.64.0.0 und 100.127.255.255, eine private Adresse wie 192.168.x.x oder 10.x.x.x, oder gar keine IPv4-Adresse, kommt die öffentliche Adresse nicht bei Ihrem Router an. Dann helfen DDNS und Portfreigaben für IPv4 nicht. Greifen Sie in diesem Fall über einen Dienst ohne Portfreigabe zu, etwa Tailscale, oder fragen Sie Ihren Anbieter nach einer eigenen IPv4-Adresse.

Verifizieren: Die Adresse von api.ipify.org und die Adresse im Router sind identisch.

Schritt 2: Die DDNS-Funktion von UGOS ansehen

Öffnen Sie die Systemsteuerung, klicken Sie auf Geräteverbindung und oben auf Remotezugriff. UGOS bietet zwei Wege an:

UGREENlink verbindet über die Server von UGREEN und braucht keine Portfreigabe. DDNS führt direkt zu Ihrem Anschluss, dafür brauchen Sie später eine Portfreigabe am Router. Setzen Sie den Haken bei DDNS-Unterstützung aktivieren und klicken Sie auf Hinzufügen. Im Feld DDNS-Dienstanbieter stehen diese Anbieter zur Wahl:

No-IP und Duck DNS vergeben kostenlos Namen unter ihren eigenen Domains, etwa ihrname.duckdns.org. Cloudflare passt, wenn Ihre eigene Domain dort verwaltet wird. Für alle anderen Domain-Anbieter, etwa netcup, hat UGOS keinen Eintrag und keine Möglichkeit, eine eigene Adresse für die Aktualisierung einzutragen. Unter dem Anbieter folgen die Felder für den Namen und die Zugangsdaten:

Die Zugangsdaten erhalten Sie im Konto beim jeweiligen Anbieter. Darunter folgt das Pflichtfeld IPv4, mit Übernehmen speichern Sie den Eintrag. Unter Erweitert findet sich eine weitere Option:

Diese Option bittet den Router, Ports selbst freizugeben, üblicherweise per UPnP. Lassen Sie sie aus. Welche Ports offen sind, legen Sie besser von Hand und bewusst fest, siehe Teil 51.

Verifizieren: Nach dem Haken sind Hinzufügen, Aktualisieren und Erweitert anklickbar, und der Dialog zeigt die sieben Anbieter. Haben Sie keinen davon, schließen Sie den Dialog, entfernen Sie den Haken wieder und lesen Sie bei Schritt 3 weiter.

Schritt 3: Einen API-Schlüssel beim Domain-Anbieter anlegen

Für die eigene Domain bei einem Anbieter ohne UGOS-Eintrag aktualisiert ein Container den Namen über die Programmierschnittstelle, kurz API, des Anbieters. Das Beispiel nutzt die REST-API von netcup. Die REST-API gilt laut netcup für Domains mit CloudDNS, zu erkennen am Reiter CloudDNS in der Domainverwaltung. Den Schlüssel legen Sie laut netcup im Customer Control Panel unter Stammdaten, API an: Beschreibung eintragen, höchstens 50 Zeichen, Nutzungsbedingungen bestätigen. Der Schlüssel gehört zum Kundenkonto und erlaubt Änderungen an den DNS-Einträgen Ihrer Domains. Behandeln Sie ihn wie ein Passwort und speichern Sie ihn im Passwortmanager.

Andere Anbieter wie Hetzner, IONOS oder INWX haben eigene Schnittstellen mit anderen Befehlen. Der Ablauf in den folgenden Schritten bleibt gleich, nur die Aufrufe der Schnittstelle im Skript ändern sich.

Verifizieren: Der neue Schlüssel steht in der Liste der API-Schlüssel, und Sie haben ihn sicher abgelegt.

Schritt 4: Projektordner und Schlüsseldatei anlegen

sudo mkdir -p /volume2/docker/ddns
cd /volume2/docker/ddns
sudo nano .env

Tragen Sie in die Datei .env nur diese eine Zeile ein, mit Ihrem Schlüssel statt des Platzhalters:

NC_API_V1_KEY=IhrSchluessel

Speichern Sie mit Strg+O und Enter, beenden Sie mit Strg+X. Danach darf nur root die Datei lesen:

sudo chmod 600 .env
ls -l .env

So landet der Schlüssel weder in der Compose-Datei noch im Skript. Das Skript übergibt ihn außerdem so an curl, dass er nicht in der Prozessliste der NAS erscheint. Wer Docker auf der NAS bedienen darf, kann ihn mit docker inspect trotzdem sehen, geben Sie dieses Recht deshalb nur vertrauten Personen. Passen Sie volume2 an das Volume Ihrer NAS an, siehe Teil 15.

Verifizieren: ls -l .env zeigt am Anfang -rw------- und root als Besitzer.

Schritt 5: Das Skript für die Aktualisierung

sudo nano ddns.sh

Fügen Sie dieses Skript ein:

#!/bin/sh
# Hält HOST.DOMAIN bei netcup auf der öffentlichen IPv4-Adresse des Anschlusses
until apk add --no-cache curl jq tzdata >/dev/null 2>&1; do
  echo "Warte auf Paketquellen"; sleep 30
done
API="https://api.netcup.com/v1"
napi() {  # Schlüssel über stdin an curl, damit er nicht in der Prozessliste steht
  if [ -n "$3" ]; then
    printf 'header = "Authorization: Bearer %s"\n' "$NC_API_V1_KEY" | curl -s -m 30 -K - \
      -X "$1" "$API$2" -H "Content-Type: application/json" --data-binary "$3"
  else
    printf 'header = "Authorization: Bearer %s"\n' "$NC_API_V1_KEY" | curl -s -m 30 -K - -X "$1" "$API$2"
  fi
}
log() { echo "$(date '+%F %T') $*"; }
log "Start für $HOST.$DOMAIN"
while true; do
  ip=$(curl -4 -fsS -m 10 https://api.ipify.org)
  dom=$(napi GET "/domain?fqdn=$DOMAIN")
  did=$(echo "$dom" | jq -r --arg d "$DOMAIN" '[.result[]? | select(.fqdn==$d)][0].id // empty' 2>/dev/null)
  rev=$(napi GET "/domain/$did/dns/revision" | jq -r '[.result[]? | select(.serial != null)] | max_by(.serial) | .identifier // empty' 2>/dev/null)
  alt=$(napi GET "/domain/$did/dns/revision/$rev/record" | jq -c --arg h "$HOST" '[.result[]? | select(.name==$h and .type=="A") | {name, type, rdata, ttl}]' 2>/dev/null)
  if [ -z "$ip" ]; then
    log "Fehler: öffentliche IP-Adresse nicht abrufbar"
  elif [ -z "$did" ]; then
    log "Fehler: Domain $DOMAIN nicht gefunden: $(echo "$dom" | jq -r '.errors[0].message // "keine Antwort"' 2>/dev/null)"
  elif [ -z "$rev" ] || [ -z "$alt" ]; then
    log "Fehler: DNS-Einträge nicht abrufbar"
  elif [ "$(echo "$alt" | jq -r '.[0].rdata // empty')" != "$ip" ] || [ "$(echo "$alt" | jq length)" -gt 1 ]; then
    body=$(jq -n --argjson del "$alt" --arg h "$HOST" --arg ip "$ip" \
      '{autoCommit: true, strict: true, delete: $del, create: [{name: $h, type: "A", rdata: $ip, ttl: 300}]}')
    res=$(napi POST "/domain/$did/changeset" "$body")
    if [ "$(echo "$res" | jq -r .success 2>/dev/null)" = "true" ]; then
      log "$HOST.$DOMAIN: $(echo "$alt" | jq -r '.[0].rdata // "kein Eintrag"') -> $ip"
    else
      log "Fehler beim Eintragen: $(echo "$res" | jq -r '.errors[0].message // "keine Antwort"' 2>/dev/null)"
    fi
  fi
  sleep "${INTERVAL:-300}"
done

Das Skript arbeitet in einer Schleife:

• Beim Start installiert es curl, jq und die Zeitzonen-Daten. Ist die NAS noch nicht online, versucht es das alle 30 Sekunden erneut.
• Es fragt bei api.ipify.org die aktuelle öffentliche IPv4-Adresse ab.
• Über die API holt es die Domain, deren aktuellen Stand der DNS-Einträge, bei netcup Revision genannt, und den A-Eintrag für Ihren Namen.
• Nur wenn die Adresse abweicht, der Eintrag fehlt oder mehrere A-Einträge für den Namen bestehen, schickt es eine Änderung: alle A-Einträge des Namens löschen, einen neuen mit 300 Sekunden Gültigkeit anlegen. Fehlermeldungen der API schreibt es ins Protokoll.
• Danach wartet es die eingestellte Zeit und beginnt von vorn.

Das Skript vergleicht mit dem Eintrag in der API, nicht mit einer DNS-Abfrage. Das ist Absicht: Die Nameserver von netcup übernahmen eine Änderung bei uns erst nach drei bis vier Minuten. Eine Version mit DNS-Abfrage hätte in dieser Zeit dieselbe Adresse mehrfach eingetragen.

Verifizieren: sudo sh -n ddns.sh gibt nichts aus, das Skript enthält also keinen Syntaxfehler.

Schritt 6: Den Container starten

sudo nano compose.yaml

services:
  ddns:
    image: alpine:3.24
    container_name: ddns
    command: ["/bin/sh", "/ddns.sh"]
    env_file: .env
    environment:
      - DOMAIN=example.de
      - HOST=heim
      - INTERVAL=300
      - TZ=Europe/Berlin
    volumes:
      - ./ddns.sh:/ddns.sh:ro
    restart: unless-stopped

Ersetzen Sie example.de durch Ihre Domain und heim durch den gewünschten Namen davor, im Beispiel entsteht heim.example.de. INTERVAL gibt in Sekunden an, wie oft das Skript prüft, 300 sind fünf Minuten. Das kleine Image alpine lädt beim Start curl, jq und die Zeitzonen-Daten nach. Ohne das Paket tzdata stand im Protokoll bei uns trotz TZ die UTC-Zeit. Starten Sie den Container:

sudo docker compose up -d
sleep 15
sudo docker logs ddns

2026-11-05 16:50:47 Start für heim.example.de
2026-11-05 16:50:49 heim.example.de: kein Eintrag -> 203.0.113.25

Die zweite Zeile erscheint nur, wenn das Skript etwas ändert. Bei einem Neustart mit unveränderter Adresse bleibt es bei der Startzeile. Ändert der Anbieter Ihre Adresse, folgt beim nächsten Durchlauf eine Zeile mit alter und neuer Adresse. Wir haben einen Wechsel nachgestellt, mit INTERVAL=60, und den Eintrag von Hand auf eine falsche Adresse gesetzt. Beim nächsten Durchlauf stellte das Skript ihn zurück:

2026-11-05 16:51:54 heim.example.de: 203.0.113.10 -> 203.0.113.25

Verifizieren: sudo docker ps --filter name=ddns zeigt den Container mit Up, und sudo docker logs ddns | grep -i fehler gibt nichts aus.

Schritt 7: Den Namen von außen prüfen

Warten Sie nach der ersten Änderung einige Minuten und fragen Sie dann einen öffentlichen DNS-Server:

dig +short A heim.example.de @1.1.1.1

dig und nslookup sind auf der NAS vorhanden, Sie können den Befehl also direkt per SSH ausführen.

203.0.113.25

Bei uns zeigten die Nameserver von netcup und der öffentliche Server 1.1.1.1 den neuen Eintrag nach drei bis vier Minuten. Steht dort noch eine andere Adresse, warten Sie und fragen Sie erneut. Hatte der Name vorher schon einen Eintrag, etwa über einen Platzhalter wie *.example.de für alle Namen, hält ihn ein DNS-Server bis zum Ablauf der alten Gültigkeit fest, in unserem Fall eine Stunde. Der neue Eintrag selbst gilt nur 300 Sekunden, spätere Adresswechsel kommen deshalb schnell an.

Verifizieren: dig liefert dieselbe Adresse wie curl -4 https://api.ipify.org aus Schritt 1.

Was DDNS allein nicht erledigt

Der Name zeigt jetzt auf Ihren Router, nicht auf die NAS. Damit von außen etwas ankommt, braucht der Router eine Portfreigabe. Geben Sie dafür nur einen VPN-Zugang frei, nicht die Oberfläche von UGOS. Das richten wir in den Teilen 48 und 51 der Serie ein. Für HTTPS mit Ihrem Namen brauchen Sie zusätzlich ein passendes Zertifikat, siehe Teil 46.

Typische Fehler

• „Fehler: Domain example.de nicht gefunden: Authentication token is not valid or has expired.“: So meldete sich das Skript bei uns mit einem falschen Schlüssel. Prüfen Sie die Zeile in .env und erstellen Sie den Container danach mit sudo docker compose up -d --force-recreate neu, damit er die Datei neu einliest.
• „Domain … nicht gefunden“ mit anderem Text: Die Domain heißt anders als in DOMAIN oder nutzt laut netcup noch kein CloudDNS. Schreiben Sie die Domain in Kleinbuchstaben, die API unterscheidet laut netcup Groß- und Kleinschreibung.
• „Fehler beim Eintragen“: Die API hat die Änderung abgelehnt, ihre Begründung steht hinter dem Doppelpunkt. Prüfen Sie HOST: Dort steht nur der Teil vor der Domain, ohne Punkt am Ende.
• dig zeigt nach Minuten noch die alte Adresse: Die alte Gültigkeit ist noch nicht abgelaufen, siehe Schritt 7.
• Der Name stimmt, von außen kommt trotzdem nichts an: Die Portfreigabe fehlt, oder der Anschluss hat keine eigene IPv4-Adresse, siehe Schritt 1.

Häufige Fragen

Warum trägt das Skript statt des Routers den Namen ein?

Viele Router können selbst DDNS-Anbieter bedienen, meist aber nur bestimmte Anbieter mit einer festen Aktualisierungsadresse. Für eine eigene Domain mit API ist der Container unabhängig vom Router und lässt sich an andere Anbieter anpassen.

Was ist mit IPv6?

Das Skript trägt nur IPv4 ein. Bei IPv6 hat jedes Gerät eine eigene öffentliche Adresse, ein AAAA-Eintrag müsste deshalb auf die Adresse der NAS zeigen, nicht auf die des Routers. Dafür bräuchte das Skript einen zweiten Teil, der die Adresse der NAS ausliest und als AAAA einträgt.

Ist DDNS ein Sicherheitsrisiko?

Der Name selbst nicht, er verrät nur Ihre öffentliche Adresse, die jede Gegenstelle ohnehin sieht. Das Risiko entsteht durch offene Ports. Geben Sie nur frei, was Sie wirklich brauchen, am besten nur ein VPN.

Fazit

Mit DDNS bleibt Ihre UGREEN NAS unter einem festen Namen erreichbar, auch wenn der Anbieter die Adresse wechselt. Nutzen Sie einen der sieben Anbieter in UGOS, genügt ein Eintrag in der Systemsteuerung. Für die eigene Domain bei netcup hält ein kleiner Container den Eintrag aktuell, für andere Anbieter mit API lässt sich das Skript anpassen. Er vergleicht direkt mit dem Stand beim Anbieter und trägt nur bei einer Änderung ein.

Weiterführende Anleitungen und Quellen

• Teil 64: Erstes Docker-Compose-Projekt anlegen
• UGREEN: Unterschied zwischen UGREENlink und DDNS
• netcup: API-Schlüssel anlegen
• netcup: Beschreibung der REST-API