排查 DNS 解析缓慢的问题

DNS 解析本应快到让人察觉不到：缓存命中的应答通常只需个位数到十几毫秒，即便是完整的未缓存查询，也很少超过几百毫秒。当它明显比这更慢时，原因通常是少数几个具体的问题，而不是什么神秘的整体变慢。

常见的“嫌疑对象”

• 配置不当或负载过高的解析器：ISP 的默认解析器状态不佳，比人们想象的更常见，换用 1.1.1.1 或 8.8.8.8 这类公共解析器是正当的诊断步骤，而不只是一种临时规避办法。
• 过长的 CNAME 链：解析器在到达真正的 A/AAAA 记录之前，每多跟随一跳都会增加延迟，四五跳的链累积起来相当可观。
• 过短的 TTL 迫使解析器频繁做完整查询，而不是使用快速的缓存应答：对快速传播有帮助，但如果设置得远低于实际需要，就会拉低平均速度。
• 解析器与权威服务器之间的网络路径问题，与 DNS 软件完全无关：丢包、路由问题，或者与附近没有 Anycast 节点的域名服务器之间地理距离过远。

把 DNS 与其他因素隔离开

要判断 DNS 是否真的是瓶颈，最可靠的方式是把查询单独拿出来测量，与完整的页面加载分开。把查询耗时与建立连接、协商 TLS、下载响应的耗时分开计时，就能准确知道总延迟中有多少（如果有的话）是 DNS 造成的。如果查询始终在个位数毫秒内返回，网站却仍然加载很慢，那么瓶颈完全在 DNS 之后，进一步调优 DNS 不会有任何改善。

在下结论之前值得先检查一下：许多“网站很慢”的抱怨，最终发现与服务器或网站代码毫无关系；而另外许多看似整体变慢的情况，其实就是 DNS 的问题，调整 TTL 或更换解析器即可解决。

为什么 Anycast 解析器通常更快

1.1.1.1 和 8.8.8.8 这类公共解析器通常比默认的 ISP 解析器表现更好，并不是因为软件更聪明，而是因为 Anycast（任播）：同一个 IP 地址会从全球数十个物理位置同时通告，网络路由会自动把您的查询发送到拓扑上最近的那一个。相比之下，ISP 自己的解析器往往只有一个（或寥寥几个）数据中心，根据您与它的相对位置，往返时间可能确实更长。这也是为什么更换解析器是正当的首选排查步骤，而不是迷信：它解决的是真实存在的物理距离和路由差异，而不只是安慰剂效应。

当所有人都觉得慢，而不只是您自己

如果一个域名从多个不同的网络和解析器解析都很慢，而不只是某一个，那么问题很可能已经从“您到解析器的路径”转移到了“该域名自身的权威基础设施”。只有一台非 Anycast 的权威域名服务器，与大部分实际访问者之间隔着很长的网络距离；权威服务器负载过重；或者 DNS 区域庞大、传输缓慢，都可能表现为这种情况。这时，多解析器批量对比比单次查询更有诊断价值：在每个观测点都持续偏慢，说明问题出在上游，即该域名自己的 DNS 服务商，而不是中间的某个网络。