Keep a name pointed at a changing address#

You will end up with a DNS name that follows your connection's address as the provider changes it. This is what makes a WireGuard endpoint or a published service usable on a connection without a fixed address.

Before you start#

The operator role and a licence.
An account with a DNS provider, and an API token for it.
A name at that provider to keep up to date.

Step 1 — Add the service#

Services → DNS, Dynamic DNS tab, Add dynamic DNS.

Name it — home.
Choose the Provider: Cloudflare, Duck DNS, No-IP, Namecheap and thirty-odd more, by the names they go by.
Add the Host names to keep pointed at this router.
Choose where the address comes from (step 2).
Fill in what the provider asks for. The form shows the fields it takes — a Zone for Cloudflare, a User name for most others — and Save stays unavailable, saying why, until they are filled in.
Password or API token: use a token scoped to the one zone it needs, never an account password.
Save changes, and apply.

Step 2 — Choose how the router learns its own address#

The address of an interface reads the address the router holds on its uplink. It is right when the router has the public address itself.

The address a web lookup sees asks a service on the internet what address your traffic comes from. It is right when the router is behind another NAT, which is common on cable and on 4G. The lookup URL is optional; without it the router uses its own default.

Check it worked#

The name resolves to the right address, from somewhere that is not the router:

bash

dig +short home.example.com @9.9.9.9
curl -s https://ifconfig.co

Those two should match. The Last update panel on the tab shows the router's own record of each name's last update, once it has made one.

Then check it after the address changes. A dynamic DNS entry that has never had to update is untested.

The token stays on the router#

The page never shows a password or token back: the service says Set, and the form's field starts empty. Leave it empty when you edit a service and the router keeps the token it has; type a new one to replace it. It is part of the router's configuration, so it is in every backup — another reason to use a narrowly scoped token.

Things that will bite#

A stale record cached somewhere. Providers publish short TTLs for this; a resolver that ignores them, or a client that caches for its own reasons, still sees the old address for a while.

A hairpin rule with the old address in it. A NAT reflection rule holds the public address as a literal, so it goes stale when the address changes — one more reason to use split-horizon DNS inside instead.

The wrong address source. The interface option behind another NAT publishes a private address, and everything appears configured while nothing works.

Undoing it#

Edit → Delete on the service. The record at the provider keeps its last value; delete it there too if you want it gone.