Chromium 浏览器是 Google Chrome 和新版 Microsoft Edge 的蓬勃发展的开源父辈，但由于一项本意良好的功能而受到了极大的负面关注：它检查用户的 ISP 是否“窃取”不存在的域查询结果。
，它为统计上不可能存在的随机“域”创建虚假查询，约占全球根 DNS 服务器收到的总流量的一半。 威瑞信工程师 Matt Thomas 写了一篇长篇文章 在 APNIC 博客上描述该问题并评估其规模。
DNS解析通常是如何进行的
这些服务器是您应该联系来解析 .com、.net 等的最高权限，以便它们告诉您 frglxrtmpuf 不是顶级域 (TLD)。
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 解析器信息。 当用户的设备需要知道如何访问特定网站时，首先会向该本地提供商管理的 DNS 服务器发送请求。 如果本地 DNS 服务器不知道答案，它会将请求转发给自己的“转发器”（如果指定）。
如果本地提供商的 DNS 服务器和其配置中指定的“转发服务器”都没有缓存响应，则请求将直接向权威域服务器提出 更高 您正在尝试转换的那个。 什么时候 домен.com 这意味着请求将发送到域本身的权威服务器 com，它们位于 gtld-servers.net.
系统 gtld-servers向其发出请求，并以域domain.com 的权威名称服务器列表以及至少一个包含此类名称服务器的IP 地址的链接记录进行响应。 接下来，响应沿着链向下移动 - 每个转发器将这些响应向下传递到请求它们的服务器，直到响应最终到达本地提供商的服务器和用户的计算机。 它们都缓存此响应，以免不必要地干扰更高级别的系统。
在大多数情况下，名称服务器记录 域名.com 将已经缓存在这些转发器之一上，因此根服务器不会受到干扰。 不过，现在我们讨论的是我们熟悉的 URL 类型 - 转换为常规网站的 URL。 Chrome 请求处于正常水平 更高 这，在集群本身的台阶上 root-servers.net.
Chromium 和 NXDomain 盗窃检查
Chromium 检查“这个 DNS 服务器是否在愚弄我？” 占到达 Verisign 根 DNS 服务器集群的所有流量的近一半。
Chromium 浏览器是 Google Chrome、新的 Microsoft Edge 和无数鲜为人知的浏览器的父项目，它希望为用户提供在单个框（有时称为“多功能框”）中轻松搜索的功能。 换句话说，用户将真实的 URL 和搜索引擎查询输入到浏览器窗口顶部的同一文本字段中。 进一步简化，它也不会强制用户输入 URL 的一部分 http:// или https://.
尽管这样很方便，但这种方法要求浏览器了解什么应被视为 URL 以及什么应被视为搜索查询。 在大多数情况下，这是非常明显的 - 例如，带有空格的字符串不能是 URL。 但是，当您考虑内部网（也可以使用私有顶级域来解析真实网站的私有网络）时，事情可能会变得更加棘手。
如果用户在公司的 Intranet 上输入“marketing”，并且该公司的 Intranet 有一个同名的内部网站，则 Chromium 会显示一个信息框，询问用户是否要搜索“marketing”还是转到 https://marketing。 情况可能并非如此，但许多 ISP 和公共 Wi-Fi 提供商“劫持”每个拼写错误的 URL，将用户重定向到一些充满横幅的页面。
随机生成
Chromium 开发人员不希望常规网络上的用户每次搜索单个单词时都会看到一个信息框询问他们的意思，因此他们实施了一个测试：当他们启动浏览器或更改网络时，Chromium 对三个网络执行 DNS 查找随机生成的“域”顶级，七到十五个字符长。 如果这些请求中的任何两个返回相同的 IP 地址，那么 Chromium 就会认为本地网络正在“劫持”错误 NXDOMAIN，它应该接收，因此浏览器将输入的所有单字查询视为搜索尝试，直至另行通知。
不幸的是，在网络中 没有 窃取 DNS 查询的结果，这三个操作通常会上升到最顶层，一直到达根名称服务器本身：本地服务器不知道如何解析 qwajuixk，因此将此请求转发给其转发器，转发器执行相同的操作，直到最后 a.root-servers.net 或者他的“兄弟”之一不会被迫说“抱歉，但这不是一个域”。
由于大约有 1,67*10^21 个可能的假域名，长度从 XNUMX 到 XNUMX 个字符不等，最常见的是 每 根据在“诚实”网络上执行的这些测试，它到达根服务器。 这相当于 半 根据该部分集群的统计数据，根 DNS 上的总负载 root-servers.net，归威瑞信所有。
历史重演
这并不是第一次带着最好的意图创建一个项目 或者几乎用不必要的流量淹没了公共资源 - 这立即让我们想起了 D-Link 和 Poul-Henning Kamp 的 NTP（网络时间协议）服务器在 2000 年代中期的漫长而悲伤的历史。
2005 年，FreeBSD 开发者 Poul-Henning（同时拥有丹麦唯一的 Stratum 1 网络时间协议服务器）收到了一笔意想不到的巨额传输流量账单。 简而言之，原因是 D-Link 开发人员将 Stratum 1 NTP 服务器（包括 Kampa 服务器）的地址写入该公司交换机、路由器和接入点系列的固件中。 这立即使 Kampa 的服务器流量增加了九倍，导致丹麦互联网交换中心 (Denmark's Internet Exchange Point) 将其资费从“免费”更改为“每年 9 美元”。
问题不在于 D-Link 路由器太多，而在于它们“脱节”。 与 DNS 非常相似，NTP 必须以分层形式运行 - 层 0 服务器将信息传递到层 1 服务器，层 2 服务器将信息传递到层 2 服务器，依此类推。 典型的家庭路由器、交换机或接入点（例如使用 NTP 服务器地址编程的 D-Link）会将请求发送到 Stratum 3 或 Stratum XNUMX 服务器。
Chromium 项目可能是出于好意，在 DNS 问题中复制了 NTP 问题，向互联网的根服务器加载了它们从未打算处理的请求。
有希望快速解决
Chromium 项目有一个开源的 ，这需要默认禁用 Intranet Redirect Detector 才能解决此问题。 我们必须归功于 Chromium 项目：bug 被发现了 前威瑞信 (Verisign) 的马特·托马斯 (Matt Thomas) 如何通过他的 在 APNIC 博客上。 该漏洞于 XNUMX 月被发现，但直到 Thomas 发表文章后才被遗忘。 禁食后，他开始受到严密监视。
希望这个问题很快得到解决，根 DNS 服务器将不再需要每天响应估计 60 亿个虚假查询。
由于宣传
史诗级服务器 - 或具有强大的 AMD EPYC 系列处理器和非常快的 Intel NVMe 驱动器的 Linux。 赶快下单吧！
来源： habr.com