Your provider may hand you a new address whenever it likes. DDNS makes sure your name notices before your friends do.
The short answer
DDNS (dynamic DNS) keeps a DNS name pointed at an address that changes: your router or a small script reports the current address to a DDNS service, and the service updates the name's record [2]. That lets you reach your home network under a stable name even when the provider changes your address. It does not create a public address. Our assessment: DDNS solves the changing address and nothing else.
How it works
- The idea. DNS maps names to addresses. At home the address can change after a reconnect or at the provider's will, so a fixed entry in DNS would soon be wrong. DDNS replaces the manual edit with an automatic update.
- Two ways to update. The DNS standard has its own update message, defined in RFC 2136 [1]. Consumer services mostly use something simpler: one HTTPS request. DuckDNS, for example, takes a request with the domain name and an account token, detects your IPv4 address if you leave it out, and answers OK or KO [2].
- IPv4 and IPv6. An IPv4 address lives in an A record, an IPv6 address in an AAAA record [4]. DuckDNS can update both in one request, and it detects only IPv4 automatically [2]. Our assessment: if your server is reachable over IPv6, send that address explicitly.
- Router or script. A FRITZ!Box can report its address to a DDNS provider itself; AVM documents where you enter the provider's update address and your credentials [3]. A server behind a router that has no such function can run a small scheduled script that calls the update address.
- The TTL. Every DNS record carries a time to live, the interval for which it may be cached [5]. After a change, some resolvers may still serve the old address until it expires. Which TTL a given service uses is unverified for the services we looked at.
- What it cannot fix. A name that points at an address nobody can reach is still unreachable. AVM requires a public IPv4 address or an IPv6 address for port sharing [6]. Behind CGNAT the name will point at the provider's shared address (see Related pages).
- Treat the token like a password. Anyone who has it can change your record. Our assessment: keep it out of shared scripts, repositories and screenshots.
A homelab example
The Bytearium homelab runs rack servers (HPE ProLiant DL360 Gen9 and DL380 Gen10) and a QNAP NAS, as of 14 to 18 Oct 2026. We have not recorded whether we use DDNS, so we say nothing about it. A general example for your own Linux machine: create a name with a DDNS service, store the token in a file that only your user can read, and call the update address every few minutes from a scheduled job: curl -fsS "https://www.duckdns.org/update?domains=<name>&token=<token>&verbose=true" [2]. The verbose answer shows UPDATED or NOCHANGE, which tells you whether the address moved [2]. Then check with dig +short <name>.duckdns.org that the name returns the address your router shows.
Checklist
- Check first that your connection has a public IPv4 or an IPv6 address.
- Choose a service that documents its update address and its HTTPS use.
- Store the token in a file with restricted rights, not in a shared script.
- Send the IPv6 address explicitly if you want to be reached over IPv6.
- Schedule the update and read its answer in a log for the first days.
- Compare the name's answer with your router's address after a reconnect.
- Note the record's TTL and expect a delay after a change.
- Rotate the token if it ever appears in a screenshot or a repository.