Do You Need Dynamic DNS for a Home VPN Server?

Most home VPN failures people ask me about are not DNS failures, and they buy a dynamic DNS subscription first anyway. Before you configure anything, decide whether the hostname is the part that is actually broken. An updater rewrites a record when the address your ISP handed you moves; it cannot open a port, punch through carrier NAT, or make a live WireGuard session notice that its endpoint changed. Three conditions decide whether dynamic DNS is the whole fix or only one line of it.

Condition one: your address actually moves

Residential addresses move for unremarkable reasons: the modem re-syncs after a power cut, the ISP rebalances a pool, a new lease lands after a long outage. They also move rarely on some lines, and I have watched the same address survive for a year; business plans often include a static one. If nothing has changed in twelve months, a single A record you edit by hand is one less daemon to keep alive.

Measure it rather than guess. Read the WAN address on the router status page, then compare it with what the outside world sees. Run this from a machine on the LAN:

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

If the two values differ, something is translating in front of your router, and no hostname update will fix that. An address inside 100.64.0.0/10 is the shared range used for carrier-grade NAT, and that is the usual reason a correctly updated name still times out from outside.

Condition two: clients look the name up again

A short TTL is the part people skip. Recursive resolvers honor the record TTL, but client stacks cache separately, and a tunnel that is already up does not re-resolve anything. Set the record to 60-300 seconds while you are debugging; that shortens the window where a stale answer is served, and it does not migrate a connected session.

OpenVPN re-resolves the remote vpn.example.net 1194 line each time it reconnects, and resolv-retry infinite keeps it retrying instead of exiting when the lookup fails. On the server, float lets an established session follow a peer whose source address changed. WireGuard is blunter: wg-quick up resolves the Endpoint when the configuration is applied, and the client resolves it again when it rebuilds the tunnel, so a handshake that still succeeds against the old address keeps succeeding until it stops.

That difference shapes the plan. If clients connect on demand, an address change costs one reconnect. If they hold a session open for days, expect the tunnel to die at the next handshake, and make the client retry instead of assuming it stays up.

Condition three: the inbound path is still open

Dynamic DNS changes where the name points and nothing else. The port forward on the router, the firewall rule on the VPN host, and the ISP allowing inbound packets all have to exist before the record matters. Watch what the forward targets: if it is pinned to a WAN address instead of the interface, an address change breaks the forward silently and the record takes the blame.

Test from outside. A phone on cellular data with Wi-Fi off is the cheapest honest test; a laptop on the same LAN is not. When the name resolves to your public address and the router has no NAT loopback, an inside test fails while the record is perfectly correct, which sends most people off to edit a record that was never wrong.

What to run when all three hold

ddclient is the least surprising updater for a small host. A minimal configuration publishes the address the provider sees, which sidesteps the double-NAT mistake:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Run it from a systemd timer every few minutes rather than a shell loop, and log the provider reply instead of assuming success. Treat the credential like a key, because it decides where every client gets sent: use a scoped update token rather than an account password, keep the file at mode 0600, and send updates over HTTPS.

Verify before you commit

One lookup tells you what the rest of the world sees, and it prints the TTL you have to wait out after a change:

dig +noall +answer vpn.example.net @1.1.1.1

Compare that address with the router WAN address. If they match, the name is doing its job and whatever still fails is inbound reachability, a key, or a client that has not re-resolved. If they differ, the updater is publishing the wrong interface, often because it ran on the VPN host behind the router instead of on the router itself.

Keep a rollback that takes a minute: note the last working address and the previous TTL, so you can publish both by hand while the provider is having a bad afternoon.

When the answer is no

If condition one or three fails, the decision changes rather than the configuration. Behind carrier NAT your practical options are asking the ISP for a public address, moving the entry point to a small VPS with a stable address, or using an overlay that keeps its own rendezvous. If the address is static, skip the updater: one A record, one AAAA record if you run IPv6, the same port forward.

If the address changes while clients stay connected, the honest fix lives on the client: reconnect logic and a retry interval, not a faster updater. Adding a second provider only hides the interval.

Before you move on, confirm four things in order:

• The address the updater publishes matches the router WAN address.
• The record TTL is short enough that a change shows up within minutes.
• The port forward is bound to the interface, not to a fixed address.
• One real client has reconnected and passed traffic since the last change.

If all four hold, leave the setup alone; your next failure is a key or a firewall rule rather than a naming problem. If any fails, fix that row before adding another moving part. RFC 2136 describes the update mechanism itself, if you want to see what the daemon puts on the wire.