VPN Client DNS Records: Owner, TTL and Cleanup Are Separate
A VPN address, a DNS record and a cache entry have separate owners: decide who may publish the name, which interfaces register, and when records age out.
Laptops connect, receive a VPN address, and the name other systems resolve still points at yesterday's office address. Nothing failed: an address was allocated, a record was not updated, and a cache still holds the old answer. Those are three objects with three owners, and only one of them belongs to the VPN. Planning publication means deciding who writes the name, which interfaces participate and when stale data disappears.
The symptom: a name that follows the wrong address
From the device, the tunnel is up and the VPN address answers. From a colleague's workstation, the same hostname resolves to a private address the device no longer holds, so the connection times out against a machine that has moved. The record is authoritative and wrong, which is worse than missing. Everyone trusts it and nobody can connect.
The reverse case is quieter: the record disappears and the name stops resolving at all. Both outcomes come from the same design gap, and neither is fixed by lowering the TTL. A shorter cache lifetime changes how long the wrong answer survives, not whether it is written.
Start by asking which object is stale. The address the VPN assigned, the record in the zone, and the answer in a resolver cache have different lifetimes and different owners.
Three objects, three owners
The VPN owns the address allocation, and it may hand the address out from an internal pool without any DHCP exchange reaching the laptop. The DNS zone owns the record, and its security model decides who may create or modify it. The resolver cache owns the copy that a reader is currently using, and nothing the device does can reach into it.
Assuming one component does all three is where the design breaks. An address that looks like it came from a managed range does not prove that a DHCP server performed the registration, and a successful registration does not prove that readers have refreshed their cache.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
Who may update the record
In an Active Directory-integrated zone with secure dynamic updates, permissions live on the record itself. A record created by a DHCP service account may not be writable by the laptop's computer account, and changing the ownership model later is a transition rather than a toggle. That is why an ownership conflict survives every client-side setting.
Microsoft's dynamic-update guidance favours client-side registration for domain-joined hybrid endpoints. Adopting it means transferring existing records deliberately, not just ticking a box on the VPN adapter and hoping the old owner gives way.
Where a DHCP service must register for other device classes, give it the supported credential and permission model for that role. Keep forward and reverse records in the same plan, because they are frequently maintained by different components and one of them is usually forgotten.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042The first command shows which addresses the device believes it holds and whether the connection is set to register them. The second and third compare what a client resolves with what the zone actually stores, which separates a cache problem from an authoritative one.
Three clocks, not one
Publication and refresh is the first clock: when the authorised updater announces that an address changed. Cache TTL is the second: how long a resolver may keep the answer it received. Authoritative cleanup is the third: how obsolete records are removed by the registration process or by aging and scavenging.
These clocks are independent, and confusing them produces fixes that do not work. A change to one is invisible to the other two. A short TTL shortens the life of a cached answer and grants no update permission. Scavenging removes records that were not refreshed, and it cannot repair a record that was never written by the right owner.
Set the TTL from how quickly readers must see a change, and set scavenging from how long an abandoned device should keep a name. Neither number decides who is allowed to write the record, and no TTL value turns address assignment into DNS administration rights.
Plan publication for a roaming device
Decide which interfaces participate in registration. A home Wi-Fi address, a VPN address and an old office address serve different audiences, and publishing all of them produces a name with several answers of unequal usefulness. Register the interfaces that the intended readers can actually reach.
Keep the stable computer name as the identity and treat the addresses as attributes of it. Preserve the domain discovery records the device needs, and do not disable registration wholesale to solve a duplicate-record problem that a permission change would fix.
Write the allocator, the updater and the cleanup owner into one record, with the intended readers named. When the name points at the wrong address again, that record tells you which of the three to inspect first instead of restarting the investigation.