VPN 的 DNS 出错？可能是某台权威服务器数据过期

连上 VPN，某个主机名却解析到昨天的地址，或者干脆解析不出来。断开 VPN，一切又恢复正常。第一反应往往怪罪隧道推送的解析器，但更常见的原因是一台对外公布的域名服务器停止了接收区域更新。新的路径只是走到了另一台权威，而不是缓存答案原来的来源。

症状随解析器而变

递归解析器会把权威告诉它的结果返回，然后在整个 TTL 内保留这份答案。如果隧道推送了另一个解析器，或改变路径让原来的解析器不再可达，客户端就会去问另一台权威，从而拿到不同的答案。那一刻域名并没有变，变的是你的视角。

这就是为什么同一个名字在办公室能用、在酒店却失败，也是为什么清空本地缓存只偶尔有效。清空缓存只是把问题重新发给同一个权威。

有区分力的测试，是直接向每台对外公布的服务器查询。

直接查询每一台权威

从委派入手，而不是凭记忆里的清单。先问父区要 NS 集合，再向集合里的每个名字查询你关心的记录。同一个名字在两台不同权威上的两次查询，立刻就能告诉你区域是否一致。

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

区域顶点的 NS 记录也要照做，因为迁移之后，父级委派和区域自身的 NS 集合可能并不一致。接下来该比较的是 SOA 上的序列号，而落后很多的从服务器属于传输问题，不是应答问题。

这些查询要在出问题的网络里执行，而不是只在办公桌上做。

把有意为之的视图和坏掉的视图分开

有些域名确实会按地区或解析器分组给出不同答案，分裂视野的部署在企业网络里很常见。

关键在于这种差异是否有据可查、是否稳定。非预期的视图是另一副样子：某台权威有一条其他服务器从未收到的记录，或者缺少一条大家都有的记录。RFC 2182 的选择与部署指南把权威可用性视为共同责任，这正是此处合适的框架。只有当每台对外公布的服务器都能用预期数据作答时，冗余才真正存在；仅仅在 53 端口上接受连接是不够的。

返回 SERVFAIL 的服务器，比自信地给出错误答案的服务器更容易诊断。

一次迁移会揭开缓存所掩盖的东西

更换服务商时，有两个权威位置会变：父级委派和区域自身的 NS 记录。两者都需要更新，而且各自按 TTL 缓存。如果旧服务器仍在运行并继续提供旧的区域，那些解析器指向它的客户端在切换看似完成之后很久，仍会拿到旧答案。

长期存活的缓存掩盖的正是这种状态。整周都好用的工作站，其实是在跟一台持有新权威新鲜答案的解析器对话，而旧服务器仍在把过期数据发给其他人。

在笔记本上更换解析器，只修好了那台笔记本，别的什么也没修。

修区域，而不是修解析器

弄清哪些服务器才应该是该区域的权威，修正托管区域或委派，让它们每一台都提供预期数据，并保住你计划中的冗余。因为某个 VPN 出口拿到一次奇怪的答案就删掉一台域名服务器，只会降低可用性，并把不一致留在原处。

然后从两个网络重新执行直接查询，并等待你改动的那条记录的 TTL 过期。

确认每台权威给出的答案都稳定，再把预期视图写进区域文档，这样下一次出现差异时容易分类。