Sources and DynDNS

When a server’s IP changes, it has to be updated in every entry pointing at it. Sources turn this around: the entry binds to a named endpoint, and the address lives in one place only.

Static sources (Source Hosts)

A source carries a name and its IPv4/IPv6 addresses — such as edge-lb with two addresses. Create them under Project → Source Hosts; the form flags addresses that are assigned twice.

In the record set editor, the value field suggests sources as you type. A bound set shows the resolved addresses in the table plus a reference to the source; when its addresses change, all bound entries follow automatically.

Existing entries are linked automatically: when you create a source (or change its addresses) and an A/AAAA entry in the project carries exactly this address set, the entry is bound to the source automatically — it already is this endpoint and follows it from now on. This only applies to plain entries (manual, adopted or stamped) and only on an exact match of all addresses; entries with additional addresses, bound sets and sync group entries stay untouched.

MX and SRV target fields also suggest sources and insert their hostnames.

Dynamic targets (DynDNS)

A DynDNS target is a source whose address is reported from the outside — typically by a router with a changing IP.

Creating: Project → DynDNS → Create target. Optionally you pick a zone and a subdomain right away; then A and AAAA entries are created with values bound to the target. As long as no address has been reported yet, they show waiting… and nothing is written to the provider.

After creation, the dialog shows the token together with a ready-made update URL once. After that it can no longer be retrieved — only a new token can be generated.

Update interfaces

The target accepts the widespread DynDNS2 protocol that nearly every router speaks:

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

Authentication is via Basic Auth with the token; the IP is determined from the connection or passed as a parameter (myip, myipv6, ip). Responses follow the DynDNS2 convention (good, nochg, badauth).

In addition there is an open echo endpoint that returns your own IP as plain text. Via the separate hostnames for IPv4 and IPv6, a specific address family can be queried deliberately.

The hostnames for this come from the core settings; without them the interface cannot show a ready-made update URL.

Examples

curl — use the connection’s source IP:

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

curl — IPv4 and IPv6 explicitly:

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

REST with bearer token — e.g. every 5 minutes via 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 → Permit Access → DynDNS → Custom):

Field	Value
Update URL	https://dyn.example.net/nic/update?hostname=<domain>&myip=<ipaddr>&myip6=<ip6addr>
Domain name	home.example.com
Username	label of the DynDNS target
Password	the token

The FRITZ!Box replaces <ipaddr>/<ip6addr> with the current addresses itself.

ddclient (/etc/ddclient.conf):

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

Further variants are documented in the in-app docs at /docs. Short TTLs (60–120 s) ensure that address changes take effect quickly.

If the instance runs behind a reverse proxy, DNSE_TRUSTED_PROXIES must be set — otherwise the proxy’s address ends up in the entry instead of the router’s.

DynDNS client (WebSocket instead of polling)

For systems that run at the location anyway (server, NAS, container) there is the DynDNS client (dnseditor-dyndns-client): it holds one WebSocket connection per address family. When the public IP changes the connection dies — the reconnect carries the new source IP and the server applies it immediately. No polling, reaction within seconds; without WebSocket (proxy/older server) the client automatically falls back to 60-second polling.

Setup: create a DynDNS target — the token dialog shows the ready-made setup command. On the system:

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

The DynDNS page then shows a green live dot per family (v4/v6) plus the client version. With the service hostnames configured the client connects per family via the A-only/AAAA-only hostname; without them it runs degraded (one connection, the missing family taken from the local interfaces). Packages (.deb/.rpm), Docker image and details: repo dns-editor/dyndns-client.