Moving VPN providers: plan the hostname, not just the IP
A new DNS record does not move existing sessions. Plan who controls the name, when each client resolves it, and how you will retire the old endpoint.
Your DNS record is correct, the replacement is healthy, and some clients spend hours dialling the old address anyway. A few fail at once against a name that resolves and never answers. Both outcomes come from one gap: a hostname changes what a client looks up, not when it looks it up, and not what it trusts when the reply arrives.
The symptom: a correct record, stale tunnels
A profile that stores a name is not a client that keeps resolving it. Most resolve once, at configuration apply or when the tunnel comes up, and then reuse that address until the session ends. A long TTL stacked on top of that is why the cutover has to be planned around reconnects instead of around the DNS edit.
Neither behaviour is a defect, which is what makes the symptom confusing. The client is working from an answer it obtained earlier, and nothing on the server side shows which answer that was. Plan the reconnect into the maintenance window and tell users what they will see, or spend the window answering tickets. A queue of identical reports is the usual result.
Who controls the name, and what the client verifies
Control of the zone decides how fast a migration can move. Keep the record at a registrar you can log into, and write down who else is able to change it.
Trust does not follow the name. A TLS-based client may check a certificate identity or a pinned name, while WireGuard authenticates the peer's public key and ignores the hostname entirely. That difference decides whether a DNS edit is enough or whether every profile needs a new fingerprint. A record change should never authorize an endpoint nobody approved.
Keep administrative and recovery access away from the public client name. Losing a hosting account should not also cost you the record that redirects clients. Store the recovery path somewhere that does not depend on the provider you are leaving.
When each client re-reads the name
Resolution timing is a per-client property, so check the implementation you actually ship before promising a cutover window. wg-quick resolves the endpoint as the interface comes up and keeps that address until the tunnel restarts. An OpenVPN client looks the name up when it connects, and whether it looks again on reconnect depends on its options.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Mobile clients are the usual surprise, because they may hold a resolved address across sleep and network changes. Publish A and AAAA records only if the replacement answers on both families. An address that answers in one family proves nothing about the other, and a dead AAAA record adds a timeout to every attempt. Document the resolution behaviour for each client you support, then test on the devices people actually use.
A reconnect is a user action in most clients, and the server cannot force it. Put that step in the maintenance note, with a line on what the user will see when it happens.
Cut over on evidence, then retire the old endpoint
Before the switch, prove each layer at the replacement: the listener answers, the firewall passes the port, routes return the right way, the name resolves to the new address, and a known identity is accepted. A listener that accepts a connection is not the same as one that completes a handshake, so test the handshake and not the port. Keep the current revocation list beside the configuration, because a restored backup re-creates the peer list as it was and would reopen access you already closed. Record which identity you tested with, since "it works" is not evidence anyone can repeat.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesDuring the transition, watch connection attempts on both endpoints for the same identity. A client still authenticating against the old address is a profile or a cached answer that never moved. Retire the old endpoint on a dated plan, since two services accepting one identity leave two doors open.
The cutover test is an application session through the new endpoint, not a ping. Once that session works and the old endpoint logs no authorized attempts across a full reconnect cycle, the move is finished.