WireGuard Still Uses the Old Endpoint After DNS Changes

The tunnel stopped passing traffic after the server's DNS record moved, and the name resolves correctly from the same machine. Those two facts are not in conflict. A WireGuard configuration holds an endpoint, and the tooling resolves the name when it applies that configuration, so the running interface can keep using the address it looked up hours ago. Check what the interface is using before you replace keys or touch the tunnel range.

The Name Is Resolved Once, Not Continuously

Core WireGuard configuration takes an endpoint as an address and a port, and the tooling that brings an interface up resolves a hostname at that moment. Nothing in the base protocol polls DNS on a schedule, and a client application may add refresh behaviour of its own on top. Recording the resolved address, the family and the port beside the name makes the gap visible. Without that record the configuration looks correct while the interface is talking to somewhere else.

There is one genuine automatic update, and it is worth knowing because it resembles DNS refresh without being it. A peer endpoint can move when correctly authenticated traffic arrives from a new address, which is roaming rather than name resolution. It follows the peer, so it cannot discover an unrelated new server that the old endpoint never contacted.

Compare the Record With the Address in Use

Query the documented name through the resolver the client uses, then ask the interface which endpoint it holds. The two answers are the comparison that decides the rest of this page:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

The wg(8) manual documents the show subcommands these lines use. Compare the address family as well as the address, because a record that gained an IPv6 entry is a different comparison from one whose IPv4 address changed. If the endpoint differs from the record, the interface is running on stale information and the name was never the problem. If they agree and the tunnel still fails, move to the listener and the rules rather than to the profile.

The handshake timestamp is in that block because the endpoint alone does not say whether the peer is reachable. A stale timestamp next to a correct endpoint is a path problem, not a resolution problem, and the distinction changes what you touch next.

Restart Through the Interface's Manager

Once the endpoint is confirmed stale, refresh it through the mechanism that owns the interface instead of editing the live configuration. For an interface started by wg-quick that is a down and up, for a systemd unit it is a restart, and for an interface owned by a manager it is a change made in that manager, because a runtime edit is overwritten at its next apply:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Then confirm the replacement listener and its identity are the service you intended. A DNS move is not an identity change, so it should never be the occasion for trusting a key you have not verified. If the interface now reports the new address and still produces no handshake, the fault has moved to the new network path or listener, which is progress rather than the same fault twice.

Handshake First, Then the Data Path

Separate the two outcomes before choosing a checklist. A handshake that succeeds under an application that fails is a data-path problem: routes, allowed prefixes or DNS inside the tunnel. A handshake that never happens is a reachability or identity problem at the endpoint. Mixing the two produces a report nobody can reproduce and a change log with three unrelated edits.

Record the name, the resolved address, the endpoint in use and whether the handshake completed. Those four facts answer the question this failure keeps asking, and they turn the next occurrence into a two-minute check. Name maintenance and client adoption remain separate jobs: correcting the record does not perform the adoption, and restarting the interface does not fix a record that is still wrong.