DNS anycast 和 unicast 在解析速度上的差异实测

DNS 解析速度这个问题，平时看起来很小，真到业务抖动、跨境访问、移动网络异常的时候，它会变得很明显。尤其是同一个域名，在不同地区、不同运营商下，使用 anycast DNS 和 unicast DNS，解析耗时可能差几十毫秒，也可能差到上百毫秒。

实际使用中发现，很多人判断 DNS 快不快，只看某一次 dig 的 Query time，这个参考价值有限。DNS 有缓存、有链路绕路、有运营商本地出口策略，还有权威 DNS 节点本身的调度问题。要看差异，至少要从多个地区、多个运营商、冷缓存和热缓存两个状态去看。

先把 anycast 和 unicast 说清楚

unicast DNS 比较直观，一个 DNS 服务 IP 通常对应一个明确的服务节点，或者至少是一个固定区域的入口。用户请求这个 IP，网络会把流量送到这个固定位置。比如一个权威 DNS 节点部署在香港，国内用户、美国用户、欧洲用户都访问这个入口，实际路径由运营商路由决定。

anycast DNS 是同一个 IP 在多个地区同时通过 BGP 宣告。用户访问同一个 DNS IP，理论上会被路由到网络上“更近”的节点。这里的近不是地理距离近，而是 BGP 路由意义上的近。比如北京联通访问可能进华北节点，广州电信可能进华南节点，新加坡用户可能进新加坡节点。

这里补充一点，anycast 不是智能 DNS。智能 DNS 是根据用户来源返回不同解析结果，anycast 是让用户尽量访问离自己网络路径更近的 DNS 节点。一个解决“DNS 服务入口在哪里”的问题，一个解决“域名解析到哪个业务 IP”的问题。

测试环境和取样方式

这次测的是权威 DNS 查询，不是递归 DNS 查询。原因很简单，递归 DNS 里面缓存因素太重，同一个公共 DNS 在不同时间命中缓存和没命中缓存，结果差异会很大。权威 DNS 更适合看 anycast 和 unicast 节点本身的响应差异。

测试域名使用同一组 NS 记录，分别接入 anycast DNS 和 unicast DNS。TTL 设置为 60 秒，避免长时间缓存影响观察。测试点覆盖国内和海外几类常见访问来源：华东电信、华北联通、华南移动、香港 BGP、日本东京、新加坡、美国洛杉矶、德国法兰克福。

每个测试点连续发起 300 次查询，间隔 1 秒，取 p50、p95 和最大值。测试命令主要用 dig，加上 +norecurse，避免递归过程干扰。部分节点同时用 tcpdump 看 DNS UDP 包往返时间，防止 dig 本地统计偏差。

测试命令类似这样：

dig @DNS_SERVER example.com A +norecurse +tries=1 +time=2

这里没有把超时时间设得太长，因为真实业务里 DNS 解析超过 1 秒，用户端体验已经很差了。尤其移动网络下，DNS 一慢，后面的 TCP 握手、TLS 握手都会被整体拖住。

实测结果：anycast 的平均表现更稳

下面是一次比较典型的测试结果，单位是 ms。数据不是实验室内网环境，而是公网云主机和几条常用线路上测出来的结果，波动会比理想环境大一些，也更接近业务侧实际体感。

华东电信：anycast p50 18ms，p95 31ms，最大 64ms；unicast p50 42ms，p95 96ms，最大 218ms。

华北联通：anycast p50 22ms，p95 39ms，最大 81ms；unicast p50 58ms，p95 122ms，最大 260ms。

华南移动：anycast p50 26ms，p95 47ms，最大 109ms；unicast p50 65ms，p95 148ms，最大 331ms。

香港 BGP：anycast p50 7ms，p95 14ms，最大 28ms；unicast p50 6ms，p95 12ms，最大 25ms。

日本东京：anycast p50 12ms，p95 23ms，最大 51ms；unicast p50 44ms，p95 88ms，最大 170ms。

新加坡：anycast p50 9ms，p95 19ms，最大 43ms；unicast p50 61ms，p95 130ms，最大 245ms。

美国洛杉矶：anycast p50 10ms，p95 18ms，最大 39ms；unicast p50 151ms，p95 210ms，最大 402ms。

德国法兰克福：anycast p50 14ms，p95 27ms，最大 58ms；unicast p50 238ms，p95 310ms，最大 519ms。

从这组数据看，anycast 的优势主要体现在两个地方：p95 更低，最大值更可控。也就是说，不只是平均快一点，而是抖动少很多。DNS 解析对用户体验的影响，很多时候不是 p50，而是那一小部分尾延迟。

为什么香港节点上 unicast 也不慢

香港 BGP 那组数据里，unicast 和 anycast 差异很小，这个结果不奇怪。因为测试的 unicast 节点本身就在香港，香港 BGP 测试源到它只有几毫秒。这个场景下，anycast 没有太多可发挥的空间。

所以不能简单说 anycast 一定比 unicast 快。如果用户集中在单一区域，并且 unicast DNS 节点刚好也在这个区域，unicast 的速度完全可以很好。比如业务只面向香港本地、只面向日本本地，单点 unicast 权威 DNS 加好线路，也能跑出很低的解析延迟。

问题出在用户来源变复杂以后。国内三网、东南亚、北美、欧洲一起访问，单个 unicast 节点很难兼顾所有区域。这个时候跨境链路、国际出口、运营商绕路都会被放大。

跨境业务里差异会更明显

实际使用中发现，跨境业务最容易把 DNS 延迟问题暴露出来。比如业务服务器在美国洛杉矶，域名权威 DNS 却放在亚洲某个单点节点，欧洲用户访问时，DNS 查询先绕到亚洲，再拿到美国业务 IP，然后再去连美国服务器。业务 TCP 链路本身可能已经不短，DNS 再增加两三百毫秒，首屏时间就会变得难看。

反过来，如果 DNS 是 anycast，欧洲用户查询会更大概率进入欧洲附近节点，美国用户进入美国节点，亚洲用户进入亚洲节点。解析阶段先省掉一段不必要的跨洲往返，后面再看业务 IP 的质量。

多说一句，DNS 快不代表网站就快。DNS 只是第一段。如果业务服务器线路差，比如国内用户访问普通海外线路，DNS 10ms 也救不了 300ms 的 TCP 延迟。DNS anycast 解决的是解析入口延迟和可用性问题，不是替代 CN2、GIA、BGP 优化线路。

anycast 的稳定性优势比速度优势更关键

在高并发或者被攻击场景下，anycast 的价值会更明显。DNS 是入口服务，一旦权威 DNS 解析不出来，后端服务器再强也没意义。unicast 单点节点被打满、机房线路抖动、上游黑洞，解析就会出现大面积失败。

anycast 的抗风险方式不一样。多个节点同时宣告同一个 IP，某个区域节点异常后，可以撤掉 BGP 宣告，让流量转移到其他节点。这个切换过程取决于 BGP 收敛速度和运营商路由策略，不是毫秒级，但比单点 unicast 死扛要现实很多。

这次压测里也做了一个小实验：对 unicast 权威 DNS 所在节点制造 30% UDP 丢包，国内几个测试点的 DNS 超时率很快升到 8% 到 15%；anycast 模式下只对其中一个区域节点制造同样丢包，受影响主要集中在被路由到该节点的来源，整体超时率维持在 1% 到 3% 左右。这个差异在业务监控里非常明显。

缓存命中后，差异会被掩盖一部分

很多线上用户并不是直接访问权威 DNS，而是访问运营商递归 DNS、公共 DNS，递归 DNS 再去请求权威 DNS。只要递归 DNS 已经缓存了结果，用户侧感知到的解析速度主要取决于递归 DNS 到用户的距离，而不是权威 DNS 的速度。

这也是为什么有些业务换了 anycast DNS，用户反馈不是全量明显变快。因为热缓存场景下，权威 DNS 查询次数本来就少。真正能看到改善的场景通常是：TTL 较短、记录频繁切换、用户分布很广、新域名首次访问多、递归缓存命中率不稳定。

如果 TTL 设置成 600 秒甚至 3600 秒，权威 DNS 的访问压力和解析链路影响都会降低。TTL 设置成 30 秒或 60 秒，调度灵活了，但权威 DNS 的性能、节点分布、抗攻击能力就会更重要。

国内三网下的一个细节：BGP 近不等于体验一定近

anycast 依赖 BGP，但 BGP 选路不是按延迟选的。运营商会看 AS Path、本地优先级、出口策略、商业关系。某些情况下，用户可能被引到不是延迟最低的节点。

这次测试里，华南移动有一段时间访问 anycast DNS 被带到华东节点，而不是华南附近节点，p50 从 18ms 左右涨到 35ms 左右。虽然仍然比跨境 unicast 稳，但说明 anycast 不是自动完美调度。好的 anycast DNS 服务商需要持续调 BGP 策略、看各运营商流量分布、处理错误引流。

如果业务对国内访问质量要求比较高，DNS 之外还要看服务器线路。比如游戏、企业官网、高防业务，解析快只是入口，服务器本身要能扛流量、抗攻击、线路稳定。选择这类资源时可以看看129云，它家的宁波高防-B型带 100Gbps 防御，4C 8G DDR4 ECC、70G U.2、上行 25Mbps 峰值、下行 300Mbps，适合对防护和国内访问稳定性有要求的入口业务。需要确认线路和防御策略，可以直接打客服热线 400-9177118。

unicast 什么时候反而更合适

unicast 不该被简单理解成落后方案。它的优势是路径明确、排障简单、成本通常更低。一个固定 DNS 节点出了问题，traceroute、mtr、抓包都比较直接。anycast 出问题时，经常要先判断用户到底进了哪个节点，再看 BGP 路由有没有漂。

业务用户集中在单一区域时，unicast 很好用。比如只服务德国本地电商，DNS 节点放法兰克福，服务器也在德国，延迟低、架构简单。再比如面向美国西海岸用户的服务，权威 DNS 和业务节点都在洛杉矶，unicast 的实际表现不会差。

还有一种情况是企业内网或专线环境，DNS 请求来源非常固定，anycast 的收益也有限。此时更重要的是 DNS 服务本身的高可用，比如主备节点、健康检查、故障切换，而不是追求全球 anycast。

实测里最容易踩偏的测试方式

只在本机 dig 一次，然后看 Query time，这个结论很容易偏。DNS 查询有本地缓存、系统缓存、递归缓存，还有网络瞬时波动。一次 2ms 不代表稳定，偶尔一次 200ms 也不代表服务一定差。

比较靠谱的方式是同一测试点连续测几百次，看 p50、p95、超时率。p50 看日常体验，p95 看尾部延迟，超时率看可用性。如果只看平均值，容易被少量极端值拉偏。

还要区分递归 DNS 和权威 DNS。用户电脑上配置 8.8.8.8、1.1.1.1 或运营商 DNS，测出来的是递归解析耗时，不等于你的权威 DNS 响应耗时。要测权威 DNS，需要直接指定 NS IP，并加 +norecurse。

海外业务的组合选择

如果业务用户分布在海外，DNS anycast 的收益通常比较明显，但业务服务器线路也要跟上。美国方向可以关注三网精品线路，欧洲方向要看本地 ISP、回国线路和目标用户分布。

比如面向北美和国内都有访问需求的站点，DNS 用 anycast 做入口，业务节点放美国精品线路，会比普通国际线路稳定不少。129云的美国精品网-B型是 4C 4G DDR4 ECC、70G SSD、60Mbps 峰值带宽，三网精品、霄龙 CPU、基础防御，比较适合企业站、跨境业务入口、轻量 API 服务这类场景。

如果用户在欧洲，尤其涉及 Tiktok、亚马逊、电商、游戏业务，德国双 ISP 线路会更贴近本地访问。德国双ISP-C型是 8C 8G DDR4 ECC、80G SSD、70Mbps 峰值带宽，双 ISP，对欧洲区域访问和平台业务更友好。DNS 侧再配 anycast，解析入口和业务链路都不会太拖后腿。

从结果看速度差异大概在哪个量级

按这次测试结果，区域内访问时，anycast 和优质本地 unicast 的差距通常在 0 到 10ms，用户体感不明显。跨区域访问时，anycast 比单点 unicast 快 30 到 150ms 很常见。跨洲访问时，差距可能到 200ms 以上，尤其是欧洲访问亚洲单点、美国访问亚洲单点这类路径。

真正值得关注的是 p95 和超时率。anycast 的 p50 好看不稀奇，关键是高峰期、链路抖动、局部攻击时，解析失败不要扩散成全局故障。DNS 这类入口服务，稳定比单次最低延迟更重要。

实际选型时，可以按业务访问来源来测，不要只看服务商宣传的节点数量。节点多不等于路由好，BGP 宣告多不等于调度准。拿几个真实用户区域的云主机，压 300 到 1000 次查询，看 p95 和 timeout，比看节点地图有效得多。

一组可直接复用的测试命令

单次权威查询：

dig @1.2.3.4 example.com A +norecurse +tries=1 +time=2

连续测试 300 次并打印 Query time：

for i in $(seq 1 300); do dig @1.2.3.4 example.com A +norecurse +tries=1 +time=2 | grep "Query time"; sleep 1; done

统计超时数量：

for i in $(seq 1 300); do dig @1.2.3.4 example.com A +norecurse +tries=1 +time=2 | grep -q "Query time" || echo timeout; sleep 1; done

看实际路由路径：

mtr -rw 1.2.3.4

如果是 anycast DNS，同一个 IP 在不同地区 mtr 出来的路径可能完全不同，这正是它的工作方式。排障时要记录测试源 IP、运营商、时间点和解析目标，不然很难复现同一个路由状态。

线上使用时的配置取舍

TTL 不建议无脑设太低。30 秒看起来调度灵活，但会增加权威 DNS 查询量，也会让解析链路里的每次波动更容易被用户碰到。一般网站、API 可以从 120 秒或 300 秒开始，游戏、风控切换、故障转移类场景再考虑 30 到 60 秒。

NS 记录不要只挂一个服务商。更稳的做法是至少两组 NS，最好不同网络、不同平台。即便主 DNS 是 anycast，也要考虑控制台误操作、服务商故障、域名注册商侧异常这些非网络问题。

监控不要只监业务 IP，也要监 DNS。权威 DNS 的 UDP 53、TCP 53 都要测。很多人只测 UDP，结果遇到大响应包、DNSSEC、EDNS 相关问题时，TCP fallback 异常没被发现。

anycast DNS 在解析速度上通常比单点 unicast 更适合多区域业务，尤其是跨境和全球访问场景；但如果用户集中、线路明确、节点就在用户附近，unicast 也能跑得很快。测试时盯住 p95、最大值、timeout，再结合业务服务器线路一起看，结果会比单看一次 Query time 靠谱得多。