摘要

  • Gaurav Kansal 的报告称，在一项持续 91 天的 RIPE Atlas 比较中，NIC 公共解析器 1.10.10.10 的 DNS 响应均值为 27.0 毫秒，ping 均值为 17.3 毫秒。这些是作者报告的结果，不是独立服务审计。
  • 研究的价值与边界同时存在：每日热门域名可能已被缓存；失败查询和丢包没有被过滤；各解析器的观测数并不相同；本次核查到的公开文件也不足以重新计算这些均值。

一张表能说明什么

2026 年 9 月，Gaurav Kansal 发布了《Monitoring 1.10.10.10 with RIPE Atlas Probes》，比较印度国家信息中心（National Informatics Centre，NIC）的公共 DNS 地址 1.10.10.10 与 Cloudflare、Google 和 Quad9。文章报告的观测区间是 2025 年 11 月 13 日至 2026 年 2 月 11 日。下表复述原文给出的均值和样本数，本文没有拿逐条原始测量独立重算。

解析器 Ping 均值 Ping 观测数 DNS 响应均值 DNS 观测数
NIC 1.10.10.10 17.3 毫秒 1,038,738 27.0 毫秒 580,916
Cloudflare 1.1.1.1 14.8 毫秒 1,047,581 43.2 毫秒 528,540
Google 8.8.8.8 14.8 毫秒 1,039,961 32.1 毫秒 596,800
Quad9 9.9.9.9 55.8 毫秒 1,050,441 112.1 毫秒 577,032

按作者公布的 DNS 均值，NIC 在这组测试中低于三家对照服务；按 ping 均值，它则比 Cloudflare 和 Google 慢 2.5 毫秒。这并不矛盾：ping 测量的是 ICMP 数据包往返时间，DNS 测量的是一次名称查询的响应表现。两项数据也不足以给解析器排出普遍适用的优劣名次。“更好”可能指可用性、回答正确率、隐私保护、安全性、过滤效果或故障恢复能力，而这些都不是更低的延迟自动能够证明的。

这项工作的意义，是把公共服务的一项操作表现置于可比较的框架中，并公开时间区间、观测量和部分方法限制。一个带有方法说明的比较，比没有分母的宣传语更容易接受审视。但表格清晰，不等于问题范围扩大。结果仍受探针位置、查询名称、缓存状态和失败记录方式约束。

每日十个域名决定了测试对象

Kansal 说，DNS 测试每天选取 NIC 网络流量中访问量最高的十个域名，并在当天把同一组名称发给四个解析器。域名列表会随日期变化。让四家服务在同一天面对相同的名称，是一种有用的控制：这样比较的不是四组偶然不同的查询。

然而，这十个名称来自 NIC 流量中的热门域名。Kansal 也指出，它们很可能经常命中缓存。解析器已经保存答案时，可以直接返回，而不必重新走完 DNS 层级查询路径。这并不会让测试失去价值：热门名称确实属于日常使用的一部分。它限制的是结论范围。这更像是在特定时期对热门、可能反复查询的名称进行响应时间比较，而不是首次解析、冷缓存、罕见域名或所有可能查询的压力测试。

“热门”的定义也带有来源视角：它来自 NIC 流量。对研究 NIC 的运行负载来说，这可以是合理选择；但它并不证明这些名称代表印度所有网络或所有公共 DNS 用户。RIPE Atlas 探针是测量起点，NIC 流量决定待测名称。两个抽样框架相互交叉，却不因此成为全国人口样本。

Ping 的含义更窄。它说明某一探针向目标地址发送 ICMP 数据包后，是否得到响应以及往返耗时。它不验证 DNS 答案是否正确、最终网站是否快速加载，也不检验应用是否可用。把 ping 和 DNS 压缩成一个总分，可能反而抹掉它们之间的区别。

观测数量很大，分母仍需解释

文章报告每家解析器超过一百万次 ping 观测、超过五十万次 DNS 观测。大量记录可以让已观测事件的汇总更稳定，却无法仅凭总数说明哪些结果进入均值、缺失了什么、失败如何计入。DNS 总数从 Cloudflare 的 528,540 到 Google 的 596,800 不等，ping 总数也不同。

Kansal 写道，取数脚本没有滤除丢包或失败查询。这一点很重要：作者并没有把不理想结果被删除描述成既定事实。但“没有过滤”还不能说明一个没有正常响应时间的超时如何进入均值、是否存在重试，也不能解释观测数究竟代表计划发出的查询、返回的记录还是成功响应。要读懂均值，需要先知道分母是什么。

公开仓库中的一份文件展示了问题，却没有解决它。2025 年 11 月 13 日的 DNS 计数文件按解析器地址列出数量，不是逐次延迟记录；当天各地址计数并不相同。仅凭一天的差异，不能断言某家故障、比较有偏或均值错误。它只说明为什么读者需要完整的计数规则和底层结果。

公开的 1.10.10.10-tests 仓库及其 README 介绍每日计数和图表。在本文核查的公开仓库树中，没有找到清楚标识的测量 ID、完整延迟原始记录或采集脚本，因而现有可见文件本身不足以重建发布的 91 天均值。这一判断仅针对研究时核查的仓库树，不意味着相关材料不存在于别处。

均值还会隐藏分布。27 毫秒究竟接近典型值，还是被少数慢时段拉高？不同探针所在网络是否有显著差异？表格没有给出分位数、逐日分布、响应码或探针间差异。中位数、高分位数、每日曲线和缺失率可以回答不同问题。大量数据有助于描述样本内情况，但并不自动代表样本之外的网络。

RIPE Atlas 提供分布式观测点，不是独立审计章

RIPE Atlas 工作方式和用户自定义测量说明介绍了如何从由不同网络托管的探针发起测量。这种分布提高了观测视角的多样性。但平台没有因此选择 Kansal 的域名列表、计算其均值或认证其解读。由第三方托管探针让测量更分散，不会自动把服务运营方撰写的研究变成独立审计；现有记录也没有表明 RIPE NCC 为结论背书。

文章提到通常有 130 至 145 个位于印度的探针。它没有说明这些探针是按印度网络、接入运营商和用户构成做过概率抽样并加权的全国样本。对探针所在位置而言，结果可能很有用；对未参与的网络能否推广，仍是另一个问题。要称为全国平均，需要明确总体、抽样规则和权重。

职务说明工作位置，不等于用户代表权

APNIC 作者简介将 Kansal 介绍为 NIC 的 Joint Director (IT)，并称其负责 Sarvagya/Bharat Public DNS。APNIC 的文章是一篇署名投稿；其2026 年 8 月刊发说明指出观点属于作者本人。这些信息有助于理解他与相关机构、服务的关系，但不能据此把他视为印度互联网用户的代表。

印度政府 CGA 网络安全指南和 NIC Informatics 2025 年 7 月文章把 1.10.10.10 与 2409::1 列入配置建议或加固参数。这证明官方文件曾提出建议，不证明多少设备实际采用、覆盖哪些地区、服务持续可用或用户体验如何。

Kansal 的个人网站还提到服务规模、数据本地化和恶意域名过滤。这些应明确归于他的个人资料，而不是将其当作延迟研究验证过的事实。响应快不能证明日志保留政策、过滤准确度、安全表现或可用性；每种说法都需要相应证据。

RFC 1034记录了 DNS 名称系统的基础。解析器速度只是公共基础设施服务的一项属性。若配置在大量终端上，故障切换、服务承诺、隐私、安全、变更控制以及如何退出同样关系到部署风险。

下一版评分表可以更容易复核

后续研究若公开每组测试的 RIPE Atlas 测量 ID、探针选择与分布变化、精确查询类型和解析器配置，并明确超时、重试、失败和丢包如何计数，复核会容易得多。逐条结果和聚合代码也能让其他分析者重新计算均值，同时对敏感信息作适当处理。

均值可以保留为摘要，但应与中位数、高分位数、逐日表现及无响应占比并列。热门域名的缓存命中测试应与冷缓存查询、已知答案测试区分。可用性、正确性、DNSSEC、隐私、过滤和安全响应需要独立评测；延迟较低并不能替代这些评测。

时间也很关键：测量区间于 2026 年 2 月 11 日结束，文章到 9 月 17 日才发布。这是历史观测，不是 9 月份的当前服务数据。按固定周期重复测试，并保持定义可比或解释方法变更，才可能看出差异是否持续。

最稳妥的结论既不是“NIC 击败全球解析器”，也不是“这项研究毫无价值”。证据支持更窄的说法：按照文章公布的探针、名称、时间区间和方法，作者报告 NIC 的 DNS 均值低于三家对照服务，而 ping 均值略高于 Google 与 Cloudflare。文章给出了足以开展技术讨论的上下文和限制，但目前核查到的公开材料还不能完整重算这些均值。

Kansal 这项工作的价值正在于把公共服务的一部分操作表现公开出来。读者可以认可这项测量贡献，同时不把表格当成全国审计，也不把作者职位理解成代表每个用户的授权。公共评分表的可信度，最终取决于其边界是否清楚、第三方是否能检查其计算。

来源