APNIC 註冊商，負責亞太地區 IP 位址的分配， 對根 DNS 伺服器 a.root-servers.net 之一進行流量分佈分析的結果。 45.80% 的根伺服器請求與基於 Chromium 引擎的瀏覽器執行的檢查有關。 因此，幾乎一半的根 DNS 伺服器資源都用於執行 Chromium 診斷檢查，而不是處理來自 DNS 伺服器的請求以確定根區域。 鑑於 Chrome 佔據網頁瀏覽器市場 70% 的份額，此類診斷活動每天會導致約 60 億個請求發送到根伺服器。
Chromium 中使用診斷檢查來偵測服務提供者是否正在使用將不存在名稱的請求重新導向至其處理程序的服務。 一些提供者正在實施類似的系統，將流量引導至輸入錯誤的網域 - 通常，對於不存在的網域，頁面會顯示錯誤警告，提供可能正確的名稱清單和廣告。 而這種行為完全破壞了瀏覽器判斷內網主機的邏輯。
處理在網址列中輸入的搜尋查詢時，如果僅輸入一個不帶點的單詞，則瀏覽器首先 確定 DNS 中的給定單字，假設使用者可能嘗試訪問內部網路上的 Intranet 站點，而不是向搜尋引擎發送查詢。 如果提供者將查詢重新導向到不存在的域名，使用者就會遇到問題 - 在網址列中輸入的任何單字搜尋查詢都會開始重新導向到提供者的頁面，而不是傳送到搜尋引擎。
為了解決這個問題，Chromium開發者在瀏覽器中加入了 ，如果偵測到重新導向，則會變更網址列中處理請求的邏輯。
每次啟動、變更 DNS 設定或變更 IP 位址時，瀏覽器會傳送三個 DNS 請求，其中包含很可能不存在的隨機一級網域名稱。 這些名稱包括 7 到 15 個拉丁字母（不含點），用於偵測提供者將不存在的網域重定向到其主機。 如果在處理三個具有隨機名稱的 HTTP 請求時，兩個請求收到到同一頁面的重定向，則 Chromium 認為使用者已被重新導向到第三方頁面。
非典型的一級網域大小（7 到 15 個字母）和查詢重複因子（名稱每次隨機生成且不重複）被用作將 Chromium 活動與根 DNS 伺服器上的一般請求流隔離的標誌。
在日誌中，先過濾不存在網域的請求（78.09%），然後選擇重複不超過51.41次的請求（7%），然後過濾包含15到45.80個字母的網域（21.91%） 。 有趣的是，只有 XNUMX% 的根伺服器請求與現有網域的定義相關。
該研究還研究了根伺服器 a.root-servers.net 和 j.root-servers.net 上不斷增長的負載對 Chrome 日益普及的依賴性。
在 Firefox 中，DNS 重定向檢查 定義重定向到身份驗證頁面（強制門戶）和 с 修復子網域名稱“Detectportal.firefox.com”，無需請求一級網域。 此行為不會在根 DNS 伺服器上產生額外的負載，但有可能 有關使用者 IP 位址的機密資料外洩（每次啟動時都會要求「detectportal.firefox.com/success.txt」頁面）。 若要在 Firefox 中停用掃描，可以使用「network.captive-portal-service.enabled」設置，可以在「about:config」頁面上變更該設定。
來源： opennet.ru