短内部名在 VPN 上失效：你从未见过的后缀
短名之所以能用，是因为有搜索后缀把它补全。比较完整名和短名，就能分清是后缀缺失还是解析器故障。
短名在办公室里能用，连上 VPN 却失效，而完整名解析正常。其实什么都没坏。像 intranet 这样的裸名并不是完整名称；客户端会从自己的搜索列表里补上一个后缀，再去查询结果。如果 VPN 配置没有提供那个后缀，熟悉的短名就不再存在。
这就是全部的迷思。DNS 没坏，变的是搜索策略。
裸名不是名字
当你只输入一个标签时，解析器必须先决定问什么。它会先按原样查询，然后逐个追加搜索列表里的条目，直到有东西应答。在 Linux 上，resolv.conf 用 search 和 ndots 设置控制这个顺序。在 Windows 上，后缀列表和名称解析策略起同样的作用。把后缀去掉，解析器就无从追加。
所以，能用的短名是策略的证据，而不是 DNS 服务器健康的证据。
后缀列表和解析器地址各自负责什么
这两者经常被混为一谈。解析器地址决定去问谁；后缀列表决定问哪个名字。VPN 可能给你一个没有后缀的私有解析器，也可能给你后缀却配错了解析器。这两种故障里，只有一种看起来像 DNS 中断。
要分开检查，因为修错方向会白白耗掉一个支持窗口。
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
三种症状，三个不同的责任人。
先测完整名
去问管理员记录在案的完全限定名，不要靠猜。一个能解析的 FQDN 证明解析器可达、记录存在，一次查询就能排除一半可能原因。用能显示是哪台服务器应答的工具，避免读到缓存结果。
测试要保密。把内部变体发给公共解析器会泄露名称，也是在检验一套没人打算用的策略。
修复该落在哪里
去改拥有该配置的配置文件，或者生成它的管理系统。手动修改本地解析器配置，通常重连就消失，或者对所有接入的网络都生效，后者更糟。
在 Windows 上，要查看实际生效的策略，而不是你记得的那个复选框。Get-DnsClientNrptPolicy 会显示真正在起作用的名称解析规则。
在 macOS 上，scutil --dns 会按作用域接口打印解析器配置，包括 VPN 推送的搜索域。
在 Linux 上，读取 /etc/resolv.conf 里的 search 行，但要确认 VPN 客户端是否重写过它。如果该文件由系统管理，就改真正的源文件，而不是渲染结果。上一次网络残留的旧 search 行是常见原因。
配置文件旁边该留什么
把修正后的完整名、后缀列表和解析器地址存在客户端配置旁边。下一位报告内网站点打不开的人，可以比对这三个已知值，而不用从空白页开始。
如果只有短名失效，就在工单里写明。这一句能替解析团队省下一个下午。