Chrome功能在全球根DNS服务器上造成巨大负载

Chromium 浏览器——谷歌 Chrome 和新版 Microsoft Edge 的开源、上游父级——正因一项善意的功能而受到严重的负面关注，该功能检查用户的 ISP 是否“劫持”了不存在的域结果。

该内联网重定向检测，这使得欺骗查询随机“域”统计上不太存在，负责大约一半的全球根DNS服务器收到的总流量。威瑞信工程师马特·托马斯 (Matt Thomas) 写了一篇冗长的 APNIC 博客文章， 概述了问题并定义了其范围。

DNS 解析通常如何工作

DNS，或域名系统，是计算机如何将相对容易记住的域名(如 arstechnica.com)转换为不太容易记住的 IP 地址，如 3.128.236.93。如果没有 DNS，互联网就无法以人类可用的形式存在——这意味着其顶级基础设施上的不必要负载是一个真正的问题。

加载一个现代网页可能需要大量的 DNS 查找。当我们分析 ESPN 的首页时，我们统计了 93 个独立的域名——从 a.espncdn.com 到 z.motads.com——需要执行这些操作才能完全加载页面!

为了使必须为整个世界提供服务的查找系统的负载易于管理，DNS 被设计为多阶段层次结构。在这个金字塔的顶端是根服务器——每个顶级域，例如 .com，都有自己的服务器系列，这些服务器是其下每个域的最终权威。一个步骤以上 那些是实际的根服务器，a.root-servers.net 通过m.root-servers.net。

这种情况多久发生一次?

由于 DNS 基础设施的多级缓存层次结构，世界上只有很小一部分 DNS 查询实际上到达了根服务器。大多数人会直接从他们的 ISP 获得他们的 DNS 解析器信息。当他们的设备需要知道如何访问arstechnica.com 时，查询首先转到该本地 ISP 管理的 DNS 服务器。如果本地 DNS 服务器不知道答案，它会将查询转发到它自己的“转发器”，如果有的话。

如果 ISP 的本地 DNS 服务器或其配置中定义的任何“转发器”都没有缓存答案，则查询最终会直接冒泡到您尝试解析的域上方的域的权威服务器 - 对于arstechnica.com，这意味着查询com 自己的权威服务器，在gtld-servers.net。

被gtld-servers 查询的系统以arstechnica.com域的权威名称服务器列表以及至少一个包含此类名称服务器的 IP 地址的“胶水”记录作为响应 。现在，答案沿着链向下渗透——每个转发器将这些答案传递给查询它的服务器，直到答案最终到达本地 ISP 服务器和用户的计算机——并且所有这些都沿着线路缓存该答案以避免打扰任何不必要的“上游”系统。

对于绝大多数此类查询，arstechnica.com的 NS 记录已经缓存在其中一台转发服务器上，因此无需打扰根服务器。不过，到目前为止，我们讨论的是一种更熟悉的 URL——解析为普通网站的 URL。Chrome的查询，上面打的水平 是，在实际的root-servers.net 集群本身。

Chromium 和 NXDomain 劫持测试

Chromium 浏览器——谷歌 Chrome、新的 Microsoft Edge 和无数其他鲜为人知的浏览器的父项目——希望为用户提供单框搜索的简单性，有时也称为“多功能框”。换句话说，您将真实 URL 和搜索引擎查询都输入到浏览器顶部的同一个文本框中。将易用性更进一步，它也不会强迫您实际键入 URLhttp:// 或https://URL 的一部分。

尽管它可能很方便，但这种方法要求浏览器了解什么应该被视为 URL，什么应该被视为搜索查询。在大多数情况下，这是相当明显的——例如，其中包含空格的任何内容都不会是 URL。但是，当您考虑内部网(私有网络，它可能使用解析为实际网站的同样私有的 TLD)时，这就变得棘手了。

如果公司 Intranet 上的用户键入“marketing”，并且该公司的 Intranet 有一个同名的内部网站，Chromium 会显示一个信息栏，询问用户是否打算搜索“marketing”或浏览https://marketing. 到目前为止，一切都很好——但许多 ISP 和共享 Wi-Fi 提供商劫持了每个错误输入的 URL，将用户重定向到某种充满广告的登陆页面。

随机生成

Chromium 的作者不想在那些常见环境中的每个单词搜索中都看到“你是不是要说”信息栏，因此他们实施了一项测试：在启动或网络更改时，Chromium 会针对三个随机生成的七项进行 DNS 查找 -到 15 个字符的顶级“域”。如果这些请求中的任何两个使用相同的 IP 地址返回，则 Chromium 假定本地网络正在劫持NXDOMAIN 它应该接收的错误 - 因此它只会将所有单字条目视为搜索尝试，直到另行通知。

不幸的是，在没有劫持 DNS 查询结果的网络上 ，这三个查找往往会一直传播到根名称服务器：本地服务器不知道如何解析qwajuixk，因此它将该查询反弹到其转发器，后者回报恩惠，直到最终a.root-servers.net 或它的一个兄弟姐妹不得不说“对不起，这不是一个域。”

由于大约有 1.67*10^21 个可能的 7 到 15 个字符的假域名，因此在大多数情况下 ，在诚实网络上发出的这些探测中的每一个最终都会干扰根服务器。如果我们按照威瑞信部分集群的统计数据，这加起来 占根 DNS 服务器总负载的一半root-servers.net。

历史总是重演

这不是第一次一个善意的项目用不必要的流量淹没或几乎淹没公共资源——我们立即想起了 D-Link 和 Poul-Henning Kamp 的 NTP(网络时间协议)服务器的漫长而悲伤的故事，从 2000 年代中期开始。

2005 年，Poul-Henning Kamp — 一位 FreeBSD 开发人员，同时运行着丹麦唯一的 Stratum 1 网络时间协议服务器 — 意外收到了巨额的带宽账单。长话短说，D-Link 开发人员将 Stratum 1 NTP 服务器地址(包括 Kamp 的地址)硬编码到公司交换机、路由器和接入点系列的固件中。这立即使 Kamp 的服务器的带宽使用量增加了九倍，导致丹麦互联网交易所将他的账单从“免费”更改为“请每年支付 9,000 美元”。

问题不在于有太多的 D-Link 路由器——而是它们正在“跳过指挥链”。与 DNS 非常相似，NTP 旨在以分层方式运行——Stratum 0 服务器为 Stratum 1 服务器提供数据，后者为 Stratum 2 服务器提供数据，并继续向下。一个简单的家用路由器、交换机或接入点，如 D-Link 硬编码这些 NTP 服务器的那些，应该查询 Stratum 2 或 Stratum 3 服务器。

Chromium 项目可能是出于最好的意图，通过将 Internet 的根服务器加载到它们永远不必处理的查询中，将 NTP 问题转化为 DNS 问题。