为什么 MagicDNS 能解析设备却解析不了办公室主机名

MagicDNS 会为 tailnet 中的每台设备分配一个名称，该名称派生自设备的机器名和 tailnet 的 DNS 域。这个名称由 Tailscale 创建，并沿 Tailscale 的解析器路径得到应答。像 files.office.example 这样的办公室主机名属于 Tailscale 从未写入的区域，因此重命名设备无法创建它。两个命名空间并存，只是所有者不同。

这一机制背后是一个非常常见的报告：Tailscale 主机有应答，而文件服务器仍然返回解析错误。

两个命名空间，两个所有者

设备名称由机器自身的主机名生成，冲突由 Tailscale 解决，结果位于 tailnet 域之下。办公室区域由运行办公室解析器的人维护，记录由管理员或动态注册创建。短名称掩盖了区别：files 可能是办公室 DNS 应答的搜索后缀扩展、某台 tailnet 设备，或者什么都不是。查询完整名称可以看出究竟是哪个系统作了应答。

更改子网路由器的机器名对办公室区域毫无作用。它只会重命名一台 Tailscale 设备，办公室服务器上的记录保持不变，所以改名重试永远不会收敛。

把办公室区域指向它的解析器

Tailscale 的拆分 DNS 会把所选域的查询发送到你指定的名称服务器，其余一切遵循剩余策略。要添加的是办公室解析器实际提供服务的域，而不是你碰巧输入的搜索后缀。搜索后缀告诉客户端要追加什么，它并不告诉解析器该去哪里查找。这两项设置在控制台里看起来相似，行为却完全不同。

受限名称服务器必须对它关联的域具有权威性，否则得到的会是转介而不是地址。

可达性先于解析

客户端还必须能够到达该名称服务器。对于私有 LAN 上的解析器，子网路由必须被通告并接受，访问策略必须允许查询，而且必须存在返回路径。管理控制台中的正确 DNS 地址只能证明配置已被保存。如果数据包无法到达解析器，症状是超时，这与权威的“无此记录”回答看起来不同。

这种区别具有诊断意义。超时指向路由或策略，而立即的否定回答指向记录或区域。在更改任何 DNS 设置之前，先读清楚你得到的是哪一种。

把名称故障与服务故障分开

如果资源能在其私有地址上响应，但不能按主机名响应，调查就停留在 DNS 上。如果两者都不行，先修复路由或服务，因为解析到不可达地址的名称并不是进展。查询完整名称，并记下是哪个服务器作的应答。 在 macOS 上，某些命令行工具走的是与普通应用不同的路径，因此终端里的 dig 和浏览器可能对同一个名称给出不同结果。

如果这就是设备的常规模式，请在选中出口节点的情况下重复测试。出口节点的 DNS 处理与无出口配置不同，只在一种模式下测试可能漏掉用户实际看到的故障。

记录区域、解析器地址以及承载查询的路由。这三者能在不必再来一轮重命名的情况下解释大多数 MagicDNS 的意外。