VPN 客户端的 DNS 记录：所有者、TTL 与清理是三件不同的事

笔记本接入网络并获得 VPN 地址，而其他系统解析到的名称仍指向昨天的办公地址。没有任何环节报错：地址已分配，记录未更新，缓存仍然保留旧答案。这是三个对象、三个所有者，而其中只有一个属于 VPN。规划发布就是决定由谁写入名称、哪些接口参与，以及陈旧数据何时消失。

症状：名称跟着错误的地址走

从设备看，隧道已建立，VPN 地址可以应答。从同事的工作站看，同一主机名解析到的却是设备已不再持有的私有地址，于是一次又一次超时地连向一台已经搬走的机器。这条记录既权威又错误，比记录缺失更糟。所有人都信任它，而没有人能连上。

相反的情况更安静：记录消失，名称彻底无法解析。两种结果都源自同一处设计空白，而降低 TTL 对两者都无济于事。更短的缓存寿命改变的是错误答案能存活多久，而不是它是否被写入。

先问是哪个对象陈旧。VPN 分配的地址、区域中的记录，以及解析器缓存中的答案，有着不同的寿命和不同的所有者。

VPN 拥有地址分配权，它可以从内部地址池直接发放地址，而不必有 DHCP 交换到达笔记本。DNS 区域拥有记录，其安全模型决定谁可以创建或修改它。解析器缓存拥有读者此刻正在使用的那份副本，设备做什么都无法触及它。

设计正是在“一个组件包办三件事”这一假设处崩掉。看似来自受管网段的地址，并不能证明 DHCP 服务器执行过注册；注册成功，也不能证明读者刷新了缓存。

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

在集成 Active Directory 并启用安全动态更新的区域里，权限存在于记录本身。由 DHCP 服务账户创建的记录，笔记本的计算机账户可能没有写入权；而日后更换所有权模型是一次迁移，不是拨一个开关。这就是为什么所有权冲突会压过客户端侧的每一项设置。

Microsoft 关于动态更新的指南倾向于让已加入域的混合终端在客户端一侧注册。采纳它意味着有意识地转移既有记录，而不是只在 VPN 适配器上勾一个框，然后指望旧所有者让位。

当 DHCP 服务必须为其他设备类别注册时，请给它该角色所支持的凭据与权限模型。把正向与反向记录放在同一份计划里，因为它们常由不同组件维护，而其中一个总被遗忘。

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

第一条命令显示设备自认为持有哪些地址，以及连接是否被设置为注册它们。第二条和第三条把客户端解析到的内容与区域实际存储的内容做对比，从而把缓存问题与权威侧问题分开。

发布与刷新是第一个时钟：被授权的更新者宣布地址已变更的时刻。缓存 TTL 是第二个：解析器可以保留所收答案多久。权威侧清理是第三个：过期记录如何由注册流程，或由老化与清除来移除。

这些时钟彼此独立，混为一谈就会得到无效的修法。其中一个的变化，另外两个看不到。短 TTL 只缩短缓存答案的寿命，并不授予任何更新权限。清除只移除未被刷新的记录，它修不好一条从未由正确所有者写入的记录。

按读者必须多快看到变更来设定 TTL，按被弃用的设备应保留名称多久来设定清除。这两个数字都不决定谁有权写入记录，任何 TTL 值也不会把地址分配变成 DNS 管理权。

决定哪些接口参与注册。家庭 Wi-Fi 地址、VPN 地址和旧办公地址服务的是不同读者，把它们全部发布，只会得到一个带有多条价值不等的答案的名称。只注册目标读者真正能到达的那些接口。

把稳定的计算机名当作身份，把地址当作它的属性。保留设备所需的域发现记录，也不要为了修一个靠改权限就能解决的重复记录问题而整体关闭注册。

把分配方、更新方与清理方写进同一条记录，并写明目标读者。当名称再次指向错误地址时，这条记录会告诉你三者中先查哪一个，而不是从头再查一遍。