Stale DDNS Record vs a Broken VPN Endpoint: How to Tell
Two failures look identical from outside: a hostname pointing at yesterday's address, and a VPN that refuses you. Check DNS before touching certificates.
From the outside, a stale hostname and a broken VPN look identical. The client resolves a name, the name points somewhere, and the connection times out or refuses. One is a DNS update problem and the other is an authentication or forwarding problem, and the difference only becomes obvious when you compare the address that is published with the address your line actually has.
Two failures that present the same way
The first failure is that the record still lists yesterday's WAN address. The second is that the record is correct and the tunnel refuses you for its own reasons. Both produce the same message on the client, and the temptation is to start regenerating certificates.
Order matters here. Checking DNS takes a minute and is reversible. Regenerating a CA is neither.
Compare the addresses before anything else
Ask the network owner which address the line currently has, then ask DNS what it publishes. dig +short vpn.example.com gives the answer your client will get, and dig @1.1.1.1 vpn.example.com shows whether a different resolver sees something else. If those two disagree, you are looking at cache behaviour rather than a broken updater.
A recursive answer can lag an update by its TTL, so keep the authoritative record and whatever your laptop cached in separate boxes.
What the updater's credential really is
Legacy DDNS devices often authenticate with the account password itself, which is why changing that password breaks them silently. They keep retrying with the old value and report nothing useful. No-IP's device-password guidance documents exactly this compatibility problem in older hardware, and the sensible response is a scoped update credential rather than a weaker account password.
Newer mechanisms issue a separate update token or key with its own lifecycle. That is the value to rotate into the router, and the one to log in your credential inventory. It is also not the value to paste into a chat thread while you debug.
Inspect the updater's non-secret status: last success time, response category, and the hostname it believes it owns. A credential rejection and a connectivity failure need different fixes.
What a DNS fix cannot do
Correcting the record does not create inbound reachability. If the line sits behind carrier-grade NAT, no hostname will make an inbound connection work. It also does not open a firewall rule or forward a port. And it is never a reason to disable server verification on the client, which is the move people make when they decide the certificate must be the problem.
Conversely, a VPN password change is not a fix for stale DNS. It just adds a second fault to the same ticket.
Reconnect and prove it end to end
Once the authoritative record is right, the client may still hold an old lookup. Use its supported reconnect or endpoint refresh and give it a moment instead of hammering connect. Then prove the path in four steps: resolve the name, confirm the address, check the listener is reachable, and authenticate. Four separate results, four separate answers.
Keep the updater in the rotation checklist beside the VPN account. One intended record owner, a valid credential and an observable success is what prevents the next version of this ticket.