Quellen und DynDNS

Wechselt die IP eines Servers, muss sie in jedem Eintrag nachgezogen werden, der auf ihn zeigt. Quellen drehen das um: Der Eintrag bindet sich an einen benannten Endpunkt, und die Adresse steht nur an einer Stelle.

Statische Quellen (Source Hosts)

Eine Quelle trägt einen Namen und ihre IPv4-/IPv6-Adressen — etwa edge-lb mit zwei Adressen. Anlegen unter Projekt → Source Hosts; doppelt vergebene Adressen meldet die Maske.

Im Record-Set-Editor bietet das Wertefeld beim Tippen die Quellen an. Ein gebundenes Set zeigt in der Tabelle die aufgelösten Adressen und einen Verweis auf die Quelle; ändert man deren Adressen, ziehen alle gebundenen Einträge automatisch nach.

Bestehende Einträge werden automatisch verknüpft: Legt man eine Quelle an (oder ändert ihre Adressen), und ein A-/AAAA-Eintrag im Projekt trägt exakt diesen Adress-Satz, wird der Eintrag automatisch an die Quelle gebunden — er ist ja bereits dieser Endpunkt und folgt ihr ab jetzt. Das gilt nur für freie Einträge (manuell, übernommen oder gestempelt) und nur bei exakter Übereinstimmung aller Adressen; Einträge mit weiteren Adressen, gebundene Sets und Sync-Group-Einträge bleiben unberührt.

Auch MX- und SRV-Zielfelder schlagen Quellen vor und setzen deren Hostnamen ein.

Dynamische Ziele (DynDNS)

Ein DynDNS-Ziel ist eine Quelle, deren Adresse von außen gemeldet wird — typischerweise von einem Router mit wechselnder IP.

Anlegen: Projekt → DynDNS → Ziel anlegen. Optional wählt man gleich eine Zone und eine Subdomain; dann entstehen A- und AAAA-Eintrag mit an das Ziel gebundenen Werten. Solange noch keine Adresse gemeldet wurde, stehen sie auf wartet… und es wird beim Provider nichts geschrieben.

Nach dem Anlegen zeigt der Dialog einmalig das Token samt fertiger Update-URL. Danach ist es nicht mehr abrufbar — nur ein neues Token lässt sich erzeugen.

Update-Schnittstellen

Das Ziel akzeptiert das verbreitete DynDNS2-Protokoll, das nahezu jeder Router spricht:

https://<dyndns-hostname>/nic/update

Authentifiziert wird per Basic Auth mit dem Token; die IP wird aus der Verbindung ermittelt oder per Parameter (myip, myipv6, ip) übergeben. Antworten folgen der DynDNS2-Konvention (good, nochg, badauth).

Zusätzlich gibt es einen offenen Echo-Endpunkt, der die eigene IP als reinen Text zurückgibt. Über die getrennten Hostnamen für IPv4 und IPv6 lässt sich gezielt eine Familie abfragen.

Die Hostnamen dafür kommen aus den Kern-Einstellungen; ohne sie kann die Oberfläche keine fertige Update-URL anzeigen.

Beispiele

curl — Absender-IP der Verbindung verwenden:

curl "https://<label>:<token>@dyn.example.net/nic/update?hostname=home.example.com&myip="

curl — IPv4 und IPv6 explizit:

curl "https://<label>:<token>@dyn.example.net/nic/update\
  ?hostname=home.example.com&myip=203.0.113.10&myip6=2001:db8::10"

REST mit Bearer-Token — z. B. alle 5 Minuten per Cron:

*/5 * * * * curl -fsS -X POST https://dns-editor.example.net/api/v1/dyndns/update \
  -H "Authorization: Bearer <token>" -d "{\"ip\":\"$(curl -s https://api.ipify.org)\"}"

FRITZ!Box (Internet → Freigaben → DynDNS → Benutzerdefiniert):

Feld	Wert
Update-URL	https://dyn.example.net/nic/update?hostname=<domain>&myip=<ipaddr>&myip6=<ip6addr>
Domainname	home.example.com
Benutzername	Label des DynDNS-Ziels
Kennwort	das Token

Die FRITZ!Box ersetzt <ipaddr>/<ip6addr> selbst durch die aktuellen Adressen.

ddclient (/etc/ddclient.conf):

protocol=dyndns2
use=web, web=https://api.ipify.org
server=dyn.example.net
login=<label>
password=<token>
home.example.com

Weitere Varianten stehen in der In-App-Doku unter /docs. Kurze TTLs (60–120 s) sorgen dafür, dass Adresswechsel schnell greifen.

Steht die Instanz hinter einem Reverse Proxy, muss DNSE_TRUSTED_PROXIES gesetzt sein — sonst landet die Adresse des Proxys im Eintrag statt die des Routers.

DynDNS-Client (WebSocket statt Polling)

Für Systeme, die am Standort ohnehin laufen (Server, NAS, Container), gibt es den DynDNS-Client (dnseditor-dyndns-client): Er hält je Adressfamilie eine WebSocket-Verbindung zur Instanz. Wechselt die öffentliche IP, bricht die Verbindung — der Neuaufbau trägt die neue Quell-IP, und der Server wendet sie sofort an. Kein Polling, Reaktion in Sekunden; ohne WebSocket (Proxy/älterer Server) fällt der Client automatisch auf 60-s-Polling zurück.

Einrichtung: DynDNS-Ziel anlegen — der Token-Dialog zeigt das fertige Setup-Kommando. Auf dem System:

dnseditor-dyndns-client setup --host https://dns.example.com --token dnsedyn_…
dnseditor-dyndns-client update
sudo systemctl start dnseditor-dyndns-client

Danach zeigt die DynDNS-Seite einen grünen Live-Punkt je Familie (v4/v6) samt Client-Version. Sind die Service-Hostnames konfiguriert, verbindet der Client sich je Familie über den A-only-/AAAA-only-Hostnamen; ohne sie läuft er degradiert (eine Verbindung, fehlende Familie von den lokalen Interfaces). Pakete (.deb/.rpm), Docker-Image und Details: Repo dns-editor/dyndns-client.