Tailscale与Linux DNS冲突排查：公共DNS和DoT怎么选？

在 Linux 服务器上使用 Tailscale 时，有时会遇到一个奇怪现象：网络连接正常，但域名解析间歇性失败；调整系统 DNS 后，问题又暂时消失了。遇到这种情况，是否应该直接启用 DNS-over-TLS（DoT）？

这篇文章记录一套通用的排查思路。所有示例均为公开 DNS 服务或通用占位信息，不涉及实际设备名称、内部 IP、域名或网络拓扑。

一、先分清可能冲突的几层 DNS

Linux 上的域名解析可能同时受到以下组件影响：

• systemd-resolved：负责系统 DNS 缓存、上游服务器和按域名分流。
• Tailscale / MagicDNS：负责 Tailnet 内的设备名称解析；Tailscale 的本地 DNS 服务通常位于 100.100.100.100。
• 云平台或 DHCP 下发的 DNS：可能提供专有的内部域名解析能力。
• 上游 DNS 的重绑定保护：部分 DNS 服务会拦截解析结果指向私有地址或共享地址空间的域名。

需要注意：不能只凭“安装 Tailscale 后 DNS 出问题”，就断定是 Tailscale 自身的防伪造策略所致。 DNS 重绑定保护通常由上游解析器实施，此外也可能是多个 DNS 管理器、路由规则或转发链路之间的冲突。

二、将 DNS 改成公网解析器有什么影响？

一个常见的 systemd-resolved 配置示例如下（公共地址仅供演示）：

[Resolve]
DNS=1.1.1.1 1.0.0.1
Domains=~.

其中，DNS= 指定公共 DNS；Domains=~. 表示将根域作为“仅路由域”，让这些服务器优先处理没有被更具体域名规则匹配的查询。它不意味着必然覆盖所有接口上的专用 DNS 规则。

这样做可能让普通网站的解析恢复正常，但也有代价：

1. 默认 DNS 传输不加密。 传统 DNS 通常使用 UDP/TCP 53，途经网络可能观察或干扰查询。
2. 云平台内部域名可能失效。 公开解析器未必知道私有服务、内部域名或特定云环境的记录。
3. 不等于修复了冲突根因。 如果真正的问题是 Tailscale 的分流 DNS 或 Linux DNS 管理器配置，改用公共 DNS 可能只是绕过了症状。

另外，多个 DNS 服务器并不一定按照书写顺序严格主备切换，不能简单理解为“第一台始终优先”。

三、带证书校验的 DNS-over-TLS 是什么？

DoT 是在 TCP 853 上使用 TLS 传输 DNS 请求。与普通 DNS 相比，它不仅加密查询内容，还能验证所连接的解析器身份，降低途中窃听和篡改的风险。

对于使用 systemd-resolved 的系统，Cloudflare DoT 的配置示例如下：

[Resolve]
DNS=1.1.1.1#one.one.one.one 1.0.0.1#one.one.one.one
Domains=~.
DNSOverTLS=yes

这里的 #one.one.one.one 用于 TLS 的服务器名称指示（SNI）和证书身份校验；DNSOverTLS=yes 表示严格要求加密。如果解析器不支持 DoT、证书验证失败或网络阻断了出站 TCP 853，DNS 解析可能直接失败。

DoT 并不是匿名服务：DNS 提供商仍能看到查询，也不保证其返回的数据必然正确。相较之下，DNSOverTLS=opportunistic 允许退回非加密 DNS，不能提供同等级别的安全保证。

四、为什么不建议直接全局启用 DoT？

Tailscale 的 MagicDNS 使用本地解析机制，而云平台内部 DNS 也可能有独立的接口配置。systemd-resolved 同时支持全局 DNS、按接口 DNS 和按域名路由；全局启用严格 DoT 后，需要确认各接口的 DNS-over-TLS 设置不会让不支持 DoT 的内部解析器被强制使用 TLS。

因此，DoT 适合用于保护支持该协议的公网 DNS 查询，但它不是解决 MagicDNS 冲突、DNS 重绑定保护或内部域名解析错误的万能开关。

五、推荐的排查顺序

先查看配置来源，而不是反复更换 DNS 服务商：

resolvectl status
ls -l /etc/resolv.conf
resolvectl query example.com
tailscale status

重点观察：

1. 全局 DNS 和各网卡 DNS 分别是什么，是否有 tailscale0 的专用规则。
2. 是否存在 ~. 或更具体的内部域名路由，查询实际上发往哪里。
3. /etc/resolv.conf 是否被网络管理器或 Tailscale 接管。
4. 普通公网域名能否解析；如果使用 MagicDNS，再单独检查内部设备名称能否解析。
5. 启用 DoT 前，确认出站 TCP 853 可达，并保留回滚配置的方式。

如果确认某台机器完全不需要 Tailscale 分配的 DNS 设置，可以评估 tailscale set --accept-dns=false，让本机自行管理 DNS；代价是该设备不再自动应用 Tailnet 的 MagicDNS / Split DNS 配置。不要在依赖内部域名的服务器上未经验证就这么做。

六、结论

先恢复稳定、再考虑加密。 对只访问常规公网域名的服务器，公共 DNS 可以作为一种简单方案，但要注意明文查询和内部域名兼容性。如果确认系统的 DNS 路由已理顺，且无需让不支持 DoT 的内部解析器继承严格 TLS 要求，再考虑启用带证书校验的 DoT。

排障时最有价值的不是“换一个 DNS 地址”，而是弄清楚：是谁在管理 DNS、哪个域名交给谁解析、查询最终走了哪条链路。