Tailscale MagicDNS 正常，但 macOS 上 nslookup 失败

在 Mac 上，ping 能解析 tailnet 机器名，nslookup 却返回失败，而两条命令说的都是实情。应用通过系统解析器解析，Tailscale 会按接口配置它；nslookup 和 host 读取的则是一个 MagicDNS 从不触碰的静态文件。两条路径可能不一致，却不会丢失任何一个数据包。改动任何 DNS 设置前，先判断出故障的应用走的是哪条路径。

两条解析路径，两个不同答案

macOS 上的应用流量走系统解析器，按接口限定的解析器条目决定哪个服务器应答哪个域名。Tailscale 把自己的 MagicDNS 条目装在那里，所以 Safari 和 ssh 能找到 tailnet 名称。nslookup、host 和 dig 则读取 /etc/resolv.conf，或在命令行指定服务器；这个文件通常仍指向路由器或办公服务器。发往该文件的 tailnet 名称没有等待它的权威应答，于是工具报失败，而系统路径却成功。

两个工具都没有出错。它们询问的是不同服务器，其中只有一个服务器知道你的 tailnet。

用系统路径测试同一个名称

先用系统查询调用做第一次测试，再把它与直接发往 MagicDNS 解析器的查询作对比。两者拼写必须完全一致，连 tailnet 域名也不例外，因为短名称和完全限定名称是两个不同的问题，答案也不同。

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

这三个输出回答三个问题：系统返回什么、哪些解析器为哪些域名配置、MagicDNS 自己知道什么。名称在第二和第三个输出中存在、在第一个中缺失，说明问题在本地配置，而不在 tailnet。

名称解析成功后，再测试服务

正确的 DNS 应答只能证明名称映射到地址。其后的服务可能已停止，端口可能被访问规则过滤，证书也可能指向与你输入不同的主机。

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

保留原始错误文本，因为证书警告、连接超时和查无此名会分别指向不同方向。更换域名服务器能修好第三种，却会在前两种上浪费一个下午。

MagicDNS 不能替代办公 DNS

办公区域内的名称不是 tailnet 设备名，即使同一客户端能访问两者。当目标位于子网路由器之后时，客户端需要为该区域配置指向内部解析器的拆分 DNS，这是与 MagicDNS 不同的设置，并且与它一并记录。

搜索域也很重要。未限定的短名称会按顺序追加每个已配置的后缀，因此最近加入其他网络的笔记本可能通过过期后缀解析。在宣布区域损坏之前，先检查实际应用了哪个后缀。

两条路径都失败时，由 tailnet 的事实决定

如果你相信存在的设备在系统查询和直接查询下都失败，问题出在 Mac 解析器的上游。

在管理控制台确认机器名和 tailnet 域名，确认设备在线且已批准，并确认客户端的 DNS 设置没有被本地禁用。离线设备仍保留名称，只是没有可返回的地址。

然后按证据选择。在系统路径上解析成功、在 nslookup 中失败的名称，是工具路径差异；能解析但服务拒绝的名称，是访问或证书问题；在任何地方都无法解析的名称，是 tailnet 或 DNS 配置问题。三个负责人、三处修复，而 MagicDNS 文档 覆盖了第一种情况的 macOS 细节。