症状
终端访问 nas.home.example、router.home.example 等完整名称正常，但输入短名称 nas 时显示找不到主机、落到公司 VPN 的同名记录，或在不同 Wi-Fi/VLAN 得到不同结果。直接修改客户端 DNS 服务器有时短暂有效，但下一次 DHCP 续租后问题又出现。
短名称不是一个全局 DNS 协议对象。客户端是否为短名称追加搜索后缀，取决于操作系统、当前接口、VPN、DHCP 选项和本地 DNS 配置。RFC 3397 描述 DHCP Domain Search Option 的编码与传递；它并不保证每个设备系统都会以相同顺序应用该选项，也不能让不存在的局域网 DNS 记录自动出现。
判断层级
按照 完整 FQDN 是否正确 → 当前 DNS 服务器 → DHCP 租约中的搜索后缀 → 操作系统接口/VPN 优先级 → 本地缓存 排查。先确定应使用的完整内部名称，再判断短名称是否是一个有必要且可控的便利功能。
尤其不要把 DNS 搜索后缀和 mDNS 混为一谈：nas.local、nas 与一个由 DHCP 下发的企业/家庭搜索域可以走不同机制。跨 VLAN 发现失败时，也不能仅靠添加搜索域解决广播或访问控制问题。
只读诊断命令
在受授权终端上分别查询完整名和短名称，并观察 DHCP/系统当前显示的 DNS 与搜索域。不要在输出中保留私有主机名、完整内部域或地址租约。
# Linux：查看生效的 resolver 配置；不同发行版的来源可能不同
resolvectl status 2>/dev/null || cat /etc/resolv.conf
getent hosts <fqdn>
getent hosts <short-name>
# Windows：只读查看 DHCP/DNS 搜索后缀与当前解析结果
ipconfig /all
Resolve-DnsName <fqdn>
Resolve-DnsName <short-name>
# OpenWrt：确认 dnsmasq 的 DHCP/DNS 配置来源
uci show dhcp
logread | grep -iE 'dnsmasq|dhcp' | tail -n 80在公共网络、公司网络或不受自己管理的 VPN 上，不要尝试伪造 DHCP 选项来“修复”短名称；应联系网络管理员或使用已批准的完整名称。
判断分支
- FQDN 与短名称都失败：先检查 DNS 服务记录、DHCP 下发的 DNS 服务器和 VLAN 到解析器的可达性；搜索域不是首要问题。
- 只有短名称失败，FQDN 正常，且客户端没有预期搜索后缀：检查该 VLAN 的 DHCP Domain Search Option 及客户端是否真的从该 DHCP 服务续租。
- 短名称被解析为错误网络或 VPN 的同名主机：比较接口与搜索后缀优先级，优先用 FQDN 消除歧义；不要依赖一个可能被多个网络追加的裸名称。
- 只有 Apple/Android 或一个特定系统失败：检查系统是否采用私有 DNS、工作资料或 VPN 的独立 resolver。RFC 3397 的存在不能证明该平台必然按桌面系统方式处理搜索域。
最小修复
为每个可管理 VLAN 指定一个有文档的内部后缀和一个解析该后缀的 DNS 服务；通过 DHCP 只下发该网络需要的搜索域，并保留 FQDN 作为文档、脚本和 NAS 挂载的稳定写法。做出变更后只让一台测试客户端更新租约，确认不影响访客网络或公司 VPN。
不要把公开后缀、.local 或其他网络已经使用的域随意重用于短名称。也不要把 DNS 后缀问题归因于外部出口、Wi-Fi 信号或网线；它们属于不同层级。
验证
在 DHCP 续租后，比较 FQDN 与短名称的实际 DNS 查询；再连接一次不同 VLAN 或启用 VPN 的终端做反向对照。验证应该包括“短名称在预期网络命中正确记录”和“在不应解析的网络保持不可解析或使用正确 FQDN”，而不只是一次浏览器成功。
证据与边界
RFC 3397 是 DHCP Domain Search Option 的协议依据，Research Engine 已静态抓取并保存本页证据哈希。它不定义某个厂商 GUI、企业 VPN 策略或客户端缓存清理方式；相关实现应以实际系统和网络管理员规则为准。