Chromium 的一項功能會為根 DNS 伺服器帶來巨大的負載

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 億個虛假查詢。

論廣告的權利

史詩級伺服器 - Windows 上的 VPS 或具有強大的 AMD EPYC 系列處理器和非常快速的 Intel NVMe 驅動器的 Linux。 趕快下單吧！

來源： www.habr.com