Chromium是Google為了開發Chrome瀏覽器而發起的免費開源軟體專案，其具備一項稱為「omnibox」的功能，使用者可以在這個欄位裡輸入網站名稱、網址或是關鍵字查找所需資料。當Chromium無法判斷使用者輸入的字串（以「marketing」為例）到底是網站名稱或是關鍵字時，Chromium會優先將其視為關鍵字，倘若DNS（Domain Name System）可以查找到對應的IP（Internet Protocol）位址時，也會一併提供建議的連結網址，例如詢問使用者「您是否要搜尋http://marketing/？」。
然而，某些網路服務提供者企圖藉由使用者輸入不正確或不存在的網址所導致的查詢錯誤來獲利；他們會截取Chromium提供的建議連結網址，改為提供與其服務有關的連結，此項做法稱為「NXDomain 劫持」（NXDomain hijacking）。因此，Chromium設計了探查功能，藉以確認可否信任網路將提供未被攔截的回應。
在Chromium的原始碼當中，包含了一個名為「intranet_redirect_detector.c.」的檔案，用於隨機產生3組字元長度在7到15之間的主機名稱（2014年2月之前的版本為10個字元），每次瀏覽器啟動，以及系統/設備的IP位址或DNS配置更改時，都會執行「內部網路重定向檢測功能」（intranet redirect detector functions）。執行的結果，如果其中至少有2組是定向到相同的主機名稱，即代表發生「NXDomain 劫持」。
依據本文作者的觀察，在Chromium增加了探查功能以來的十多年間，DNS根伺服器流量的一半很可能都是來自這項探查的結果，相當於一天之內向根伺服器系統進行600億次左右的查詢。一般在正常操作的情況之下，根伺服器系統如果有一半的流量來自單一函數庫，且位於單個瀏覽器平臺上，其唯一目的只是為了檢測DNS攔截，這與分散式阻斷服務攻擊（Distributed Denial of Service Attack，DDoS）幾乎無法區分。
文末作者提出了幾項或可減少對根伺服器系統探測查詢的建議做法，更有效的則包括採用主動性NSEC（Next Secure）快取（RFC 8198）、Qname最小化（RFC 7816），以及NXDomain Cut（RFP 8020）等技術層面的解決方案，然而這些方案均需要遞迴解析器的操作人員採取相關行動，可惜的是，他們對於部署及支援這些技術的動機都相當有限。
原文連結：https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/
圖片來源：APNIC網站
