引言
每次你在瀏覽器中輸入網站位址時，在任何內容載入之前都會發生一次隱形的對話。你的裝置會詢問網際網路：「我在哪裡可以找到這個網站？」這個問題及其答案傳統上都是以明文形式傳送的，任何監控你網路的人都能看到。這就像在搭乘私人計程車之前，在擁擠的房間裡大聲喊出你的目的地。
DNS over HTTPS (DoH) 從根本上改變了這種動態，它加密這些查詢，將它們包裝在保護你的密碼和信用卡資訊的相同安全協定中。最初作為隱私增強功能出現的技術，已經演變成一項有爭議的技術，它挑戰了數十年的網路管理實務，引發了關於中心化的問題，並迫使我們重新考慮隱私與控制之間的平衡。
本文將探討 DoH 的工作原理、出現的原因、帶來的好處，以及它給網際網路生態系統帶來的複雜挑戰。
理解 DNS：網際網路的通訊錄
在深入了解 DoH 之前，我們需要理解它在保護什麼。網域名稱系統（DNS）是網際網路的基礎協定之一，它將人類可讀的網域名稱（如「example.com」）轉換為電腦用於通訊的 IP 位址（如「93.184.216.34」）。
傳統 DNS 透過 UDP 埠 53（或 TCP 用於較大回應）運作，以明文形式傳送查詢和回應。當你造訪網站時，你的裝置會向解析器傳送 DNS 查詢——通常由你的 ISP 或像 Google DNS 或 Cloudflare 這樣的公共服務提供。解析器要麼回傳快取的答案，要麼查詢權威 DNS 伺服器以找到正確的 IP 位址。
🔍 傳統 DNS 流程
- 使用者輸入 URL：瀏覽器需要網域的 IP 位址
- 傳送查詢：裝置向設定的解析器傳送 DNS 查詢（埠 53，明文）
- 解析器搜尋：檢查快取或查詢權威伺服器
- 回傳回應：IP 位址回傳給裝置（明文）
- 建立連線：瀏覽器連線到 IP 位址
這個過程的每一步都對網路觀察者可見。
隱私問題
傳統 DNS 缺乏加密會造成幾個隱私和安全漏洞：
- 監控：ISP、政府和網路營運商可以看到你查詢的每個網域
- 操縱：攻擊者可以攔截和修改 DNS 回應（DNS 欺騙）
- 審查：網路營運商可以透過過濾 DNS 查詢來阻止存取
- 追蹤：即使網站使用 HTTPS，DNS 查詢也會暴露瀏覽模式
- 資料洩漏：DNS 查詢暴露有關內部網路結構的資訊
雖然 HTTPS 加密了你的網頁瀏覽內容，但 DNS 查詢仍然可見，造成了重大的隱私缺口。觀察者無法看到你在網站上做什麼，但他們確切地知道你正在造訪哪些網站。
DNS over HTTPS 的工作原理
DNS over HTTPS 透過將 DNS 查詢隧道化到 HTTPS 連線中來解決這些漏洞，這與保護網路流量的加密協定相同。這個看似簡單的改變對隱私和網路架構有著深遠的影響。
技術架構
DoH 將 DNS 查詢封裝在 HTTPS 請求中，通常使用 HTTP/2 或 HTTP/3 以提高效率。DoH 用戶端不是向埠 53 傳送查詢，而是向 DoH 伺服器的端點（通常是埠 443）傳送 HTTPS POST 或 GET 請求。
🔐 DoH 請求流程
傳統 DNS 查詢：
用戶端 → DNS 解析器（埠 53，UDP/TCP）
查詢：「example.com 的 IP 是什麼？」
回應：「93.184.216.34」（網路可見所有內容）
**DoH 查詢：**
用戶端 → DoH 伺服器（埠 443，HTTPS）
包含 DNS 查詢的加密 POST 請求
包含 IP 位址的加密回應
（網路只能看到加密的 HTTPS 流量）
協定規範
DoH 在 RFC 8484 中標準化，定義了如何在 HTTP 請求和回應中編碼 DNS 查詢。該協定支援兩種方法：
POST 方法：
- DNS 查詢編碼在請求本體中
- Content-Type：
application/dns-message - 二進位 DNS 訊息格式
- 首選隱私保護（查詢不在 URL 中）
GET 方法：
- DNS 查詢編碼在 URL 參數中
- 查詢參數：
?dns=<base64url-encoded-query> - 可能被 HTTP 中介軟體快取
- 適用於簡單查詢
💡 線路格式相容性
DoH 使用與傳統 DNS 相同的二進位 DNS 訊息格式，這使得現有 DNS 軟體可以透過新增 HTTPS 包裝器輕鬆支援 DoH。DNS 協定本身沒有改變——只有傳輸機制改變了。
DoH 與 DNS over TLS (DoT) 的對比
DoH 不是唯一的加密 DNS 協定。DNS over TLS (DoT) 在 RFC 7858 中標準化，也加密 DNS 查詢，但使用專用埠（853）和直接的 TLS 而不是 HTTPS。
| 特性 | DoH（埠 443） | DoT（埠 853） | 傳統 DNS（埠 53） |
|---|---|---|---|
| 加密 | 是（HTTPS） | 是（TLS） | 否 |
| 埠 | 443（HTTPS） | 853（專用） | 53（UDP/TCP） |
| 可見性 | 看起來像網路流量 | 清楚可識別 | 清楚可識別 |
| 阻擋 | 困難（阻擋所有 HTTPS） | 容易（阻擋埠 853） | 容易（阻擋埠 53） |
| 網路控制 | 有限 | 可能 | 完全 |
| 快取 | 可能 HTTP 快取 | 無 HTTP 快取 | 僅 DNS 快取 |
關鍵區別：DoH 流量與常規 HTTPS 網路流量無法區分，使得在不阻擋所有 HTTPS 的情況下幾乎不可能阻擋它。DoT 使用專用埠，使其易於識別和控制。
驅動因素：DoH 出現的原因
推動加密 DNS 的努力並非憑空發生。幾個匯聚的因素創造了對 DoH 採用的需求和動力。
隱私擔憂和監控
2013 年史諾登的揭露暴露了大規模監控計畫的範圍，包括 DNS 查詢監控。這引發了科技產業更廣泛的隱私運動，導致 HTTPS 的廣泛採用。然而，DNS 仍然是一個未加密的弱點，削弱了 HTTPS 帶來的隱私收益。
隱私倡導者認為，DNS 查詢揭示了有關使用者興趣、健康問題、政治觀點和個人關係的敏感資訊。即使 HTTPS 保護網站內容，DNS 查詢也會建立詳細的線上行為地圖。
🕵️ 監控能力
DNS 查詢揭示的內容：
- 醫療狀況（健康網站查詢）
- 政治立場（新聞網站、競選網站）
- 財務狀況（銀行網站、投資平台）
- 個人關係（約會網站、社群網路）
- 地理位置（本地商業查詢）
- 工作模式（基於時間的查詢模式）
這些中繼資料對於使用者畫像通常比內容更有價值。
ISP 行為和貨幣化
網際網路服務提供商越來越多地透過各種方式將 DNS 資料貨幣化：
- 廣告：在 DNS 錯誤頁面中注入廣告
- 追蹤：向廣告商出售 DNS 查詢資料
- 重新導向：將失敗的查詢重新導向到帶有廣告的搜尋頁面
- 分析：從瀏覽模式建構使用者畫像
這些做法雖然通常在服務條款中披露，但引發了對使用者隱私和同意的擔憂。DoH 消除了 ISP 對 DNS 查詢的可見性，消除了這些貨幣化機會，並引發了 ISP 的強烈反對。
審查和操縱
世界各地的政府和網路營運商使用 DNS 過濾進行審查，透過阻止 DNS 解析來阻止存取網站。雖然一些過濾服務於合法目的（阻擋惡意軟體、兒童剝削），但它也被用來壓制政治異議和控制資訊存取。
DNS 操縱攻擊（DNS 欺騙、快取投毒）可以將使用者重新導向到惡意網站或阻止存取合法資源。這些攻擊利用了 DNS 缺乏身分驗證和加密的特點。
DoH 使 DNS 過濾和操縱變得更加困難，將控制權從網路營運商轉移到 DNS 解析器營運商和應用程式開發人員。
瀏覽器供應商倡議
主要瀏覽器供應商——特別是 Mozilla 和 Google——將 DoH 作為更廣泛隱私倡議的一部分進行推廣。Mozilla 在 Firefox 中預設啟用了 DoH（2020 年），而 Chrome 新增了使用者控制的 DoH 支援。這些決定將 DoH 帶給了數億使用者，儘管遭到 ISP 和網路管理員的反對，但仍加速了採用。
瀏覽器供應商認為，使用者預設應該享有隱私，不應該需要技術專業知識來保護他們的 DNS 查詢。批評者反駁說，瀏覽器越權並破壞了網路管理。
優勢：DoH 採用的理由
DoH 採用帶來了切實的隱私和安全優勢，儘管它引發了爭議，但這些優勢證明了其採用的合理性。
增強隱私
DoH 的主要優勢是防止網路中間人對 DNS 查詢的監控。ISP、公共 WiFi 營運商和其他網路觀察者無法再看到使用者正在查詢哪些網域。這種隱私擴展到：
- 家庭網路：室友和家庭成員無法監控彼此的瀏覽
- 公共 WiFi：咖啡店營運商無法追蹤客戶瀏覽
- 企業網路：雇主對員工瀏覽的可見性降低（有爭議）
- ISP 監控：服務提供商無法從 DNS 資料建構畫像
🔒 隱私層次
沒有 DoH：
- ISP 看到：DNS 查詢（造訪的網域）
- 網站看到：你的 IP 位址和瀏覽行為
有 DoH：
- ISP 看到：到 DoH 伺服器的加密 HTTPS 流量，然後到目標的加密流量
- DoH 提供商看到：DNS 查詢（信任轉移）
- 網站看到：你的 IP 位址和瀏覽行為
DoH 不提供完全匿名——它將信任從 ISP 轉移到 DoH 提供商。
防止操縱
加密 DNS 查詢可以防止修改 DNS 回應的中間人攻擊。公共 WiFi 網路、受損路由器或惡意 ISP 上的攻擊者無法透過 DNS 操縱將使用者重新導向到釣魚網站或阻止存取合法資源。
DNSSEC（DNS 安全擴充）提供 DNS 回應的加密身分驗證，但採用緩慢且不提供機密性。DoH 透過新增加密來補充 DNSSEC，建立更完整的安全解決方案。
規避審查
對於生活在網際網路審查國家的使用者，DoH 提供了繞過基於 DNS 的阻擋的工具。透過使用審查國家以外的 DoH 伺服器，使用者可以存取被阻擋的網站，而無需像 VPN 這樣的複雜規避工具。
🌍 抗審查
傳統 DNS 阻擋：
- 政府控制本地 DNS 解析器
- 阻擋對被禁網域的查詢
- 使用者看到「找不到網域」錯誤
有 DoH：
- 使用者設定瀏覽器使用外國 DoH 伺服器
- DNS 查詢加密並傳送到外部伺服器
- 阻擋需要阻擋所有 HTTPS（不切實際）
這種能力使 DoH 在網際網路控制嚴格的國家具有政治爭議性。
改善安全態勢
DoH 減少了基於 DNS 的威脅的攻擊面：
- DNS 欺騙：加密查詢無法被攔截和修改
- 快取投毒：更難注入虛假 DNS 記錄
- DNS 隧道偵測：加密流量使惡意 DNS 隧道更難偵測（雙面刃）
- 憑證竊取：防止攻擊者重新導向登入頁面
使用受信任解析器的 DoH 組織可以防止繞過傳統安全控制的基於 DNS 的攻擊。
效能最佳化
現代 DoH 實作利用 HTTP/2 和 HTTP/3 功能來提高效能：
- 多工：透過單一連線進行多個 DNS 查詢
- 連線重用：減少連線建立的延遲
- HTTP 快取：中間快取可以儲存回應（有隱私考量）
- 0-RTT：HTTP/3 為重複查詢啟用零往返時間
挑戰和爭議
DoH 的優勢伴隨著重大挑戰，使其成為近年來最具爭議的網際網路協定之一。
網路管理和可見性
網路管理員依賴 DNS 可見性來實現合法目的：
- 安全監控：偵測惡意軟體通訊、資料外洩
- 內容過濾：阻擋惡意網站、執行可接受使用政策
- 故障排除：診斷網路問題、識別設定錯誤的系統
- 合規性：滿足內容過濾的監管要求
DoH 透過加密 DNS 查詢破壞了這些能力，迫使組織實施替代監控方法或完全阻擋 DoH。
⚠️ 企業擔憂
DoH 導致的能力喪失：
- 基於 DNS 的威脅偵測（惡意軟體網域、C2 伺服器）
- 家長控制和內容過濾
- 網路使用分析
- 遵守資料保留法規
- DNS 解析問題故障排除
緩解策略：
- 部署帶有日誌記錄的內部 DoH 伺服器
- 使用端點安全代理程式獲得可見性
- 實施 TLS 檢查（有爭議）
- 阻擋外部 DoH 伺服器（軍備競賽）
中心化擔憂
傳統 DNS 高度分散，由 ISP、組織和公共服務營運的數千個解析器。DoH 採用使 DNS 流量集中在少數大型提供商中：
- Cloudflare (1.1.1.1)：最受歡迎的 DoH 提供商之一
- Google (8.8.8.8)：龐大的 DoH 使用者群
- Quad9：注重隱私的替代方案
- 瀏覽器預設值：Mozilla 與 Cloudflare 合作，集中流量
這種中心化引發了擔憂：
- 單點故障：中斷影響數百萬使用者
- 監控風險：集中資料建立有吸引力的監控目標
- 市場力量：少數提供商控制關鍵基礎設施
- 地緣政治影響：DNS 流量流經特定司法管轄區
🏛️ 中心化與隱私權衡
分散式 DNS（傳統）：
- 許多小型營運商（ISP、本地解析器）
- 查詢對本地網路營運商可見
- 對單一提供商故障具有彈性
- 更容易在本地監管
中心化 DoH：
- 少數大型提供商
- 查詢對本地網路隱藏但對 DoH 提供商可見
- 容易受到提供商中斷的影響
- 更難監管（跨境）
兩種模型都不明顯優越——每種都涉及不同的信任假設。
分割視界 DNS 和內部網路
許多組織使用分割視界 DNS，其中內部網域在企業網路上的解析與在公共網際網路上的解析不同。像「intranet.company.local」這樣的內部資源只能在公司網路上解析。
當用戶端使用外部 DoH 伺服器時，DoH 會破壞分割視界 DNS。內部網域查詢會傳送到無法解析它們的公共解析器，從而破壞對內部資源的存取。組織必須：
- 阻擋外部 DoH：防止員工使用公共 DoH 伺服器
- 部署內部 DoH：需要基礎設施投資和設定
- 使用發現機制：實施 DoH 伺服器發現協定（仍在成熟中）
效能開銷
雖然 DoH 可以利用 HTTP 最佳化，但它也引入了開銷：
- 連線建立：HTTPS 握手為第一個查詢增加延遲
- 加密開銷：加密/解密查詢的 CPU 成本
- HTTP 框架：與原始 DNS 相比的額外位元組
- 連線管理：維護持久連線
對於大量 DNS 使用者，這種開銷可能是可測量的。然而，連線重用和 HTTP/2 多工減輕了大部分影響。
法律和監管挑戰
DoH 使圍繞合法攔截、內容過濾和資料保留的法律框架變得複雜：
- 合法攔截：執法部門失去對 DNS 查詢的可見性
- 內容過濾授權：要求 ISP 級過濾的國家無法執行
- 資料保留：要求 DNS 查詢日誌記錄的法規變得更難執行
- 管轄權：DNS 流量流向不同法律管轄區的提供商
一些國家已經考慮或實施了對 DoH 的限制以維持監管控制。英國的網際網路觀察基金會表達了對 DoH 破壞兒童保護工作的擔憂。
實施方法
組織和使用者有幾種實施 DoH 的選項，每種都有不同的權衡。
基於瀏覽器的 DoH
現代瀏覽器包含內建的 DoH 支援，允許使用者在不進行系統級變更的情況下啟用加密 DNS：
Firefox：
- 在某些地區預設啟用 DoH
- 預設使用 Cloudflare 或 NextDNS
- 使用者可以設定自訂 DoH 伺服器
- 尊重企業政策以停用 DoH
Chrome/Edge：
- 如果系統 DNS 解析器支援，則啟用 DoH
- 在可用時將現有 DNS 升級到 DoH
- 尊重系統 DNS 設定
- 可以透過企業政策停用
Safari：
- 透過系統級設定支援 DoH
- 沒有內建的 DoH 伺服器預設值
- 需要手動設定或設定檔
🔧 瀏覽器 DoH 設定
優勢：
- 使用者易於啟用
- 不需要系統級變更
- 每個瀏覽器控制
劣勢：
- 僅保護瀏覽器流量
- 其他應用程式仍使用傳統 DNS
- 可能與網路政策衝突
系統級 DoH
作業系統越來越多地在系統級支援 DoH，保護所有應用程式：
Windows 11：
- DNS 用戶端中的原生 DoH 支援
- 透過設定或登錄檔設定
- 支援回退到傳統 DNS
macOS：
- 透過設定檔支援 DoH
- 需要手動設定或 MDM 部署
- 系統範圍保護
Linux：
- systemd-resolved 支援 DoH
- 各種第三方 DoH 用戶端可用
- 需要設定
Android/iOS：
- 私人 DNS 設定支援 DoH
- 基於 VPN 的 DoH 應用程式可用
- 每個網路設定可能
企業 DoH 部署
部署 DoH 的組織面臨獨特的要求：
🏢 企業 DoH 策略
選項 1：內部 DoH 伺服器
- 在企業網路內部署 DoH 伺服器
- 維護 DNS 可見性和控制
- 支援分割視界 DNS
- 需要基礎設施投資
選項 2：託管 DoH 服務
- 使用企業 DoH 提供商（Cisco Umbrella、Cloudflare for Teams）
- 集中管理和日誌記錄
- 維護安全可見性
- 訂閱成本
選項 3：混合方法
- 企業裝置的內部 DoH
- 允許 BYOD 的外部 DoH
- 基於政策的路由
- 複雜設定
DoH 伺服器選擇標準
選擇 DoH 提供商涉及評估幾個因素：
| 標準 | 考量因素 |
|---|---|
| 隱私政策 | 日誌記錄實務、資料保留、第三方共享 |
| 效能 | 延遲、可靠性、地理分布 |
| 安全性 | 惡意軟體阻擋、威脅情報整合 |
| 過濾 | 內容過濾選項（家長控制、惡意軟體） |
| 合規性 | 資料駐留、監管合規 |
| 成本 | 免費與付費層級、企業定價 |
| 透明度 | 公開稽核、透明度報告 |
現實世界的採用和影響
自 2018 年以來，DoH 採用顯著增長，對網際網路隱私和網路管理產生了可衡量的影響。
採用統計
- Firefox：2020 年為美國使用者預設啟用 DoH，擴展到其他地區
- Chrome：2020 年 DoH 支援，在可用時自動升級
- Cloudflare：每天處理數十億次 DoH 查詢
- Google Public DNS：DoH 流量顯著增長
- 企業：採用混合，許多組織阻擋外部 DoH
案例研究
💼 Mozilla 的 DoH 推出
方法：
- 從美國開始逐步推出（2020 年）
- 與 Cloudflare 合作作為預設提供商
- 受信任遞迴解析器（TRR）計畫用於提供商審查
- 企業政策覆蓋企業網路
結果：
- 數百萬使用者預設受到保護
- ISP 和網路營運商的強烈反對
- 迫使企業 DoH 解決方案的開發
- 提高了對 DNS 隱私問題的認識
🌐 Cloudflare 1.1.1.1
提供：
- 免費公共 DoH 解析器
- 注重隱私（最少日誌記錄）
- 高效能（全球任播網路）
- 惡意軟體阻擋變體（1.1.1.2）
影響：
- 成為最大的 DoH 提供商之一
- 展示了注重隱私的 DNS 的可行性
- 引發了對中心化的擔憂
- 影響其他提供商提供 DoH
對網路安全的影響
安全團隊報告了對 DoH 的不同體驗：
積極影響：
- 減少來自外部網路的基於 DNS 的攻擊
- 防止 ISP 級操縱
- 改善遠端工作者的隱私
消極影響：
- 失去基於 DNS 的威脅偵測
- 難以執行內容政策
- 安全監控複雜性增加
- 需要替代偵測方法
組織透過實施基於端點的安全、TLS 檢查（有爭議）和帶有日誌記錄的內部 DoH 伺服器來適應。
未來方向
DoH 繼續發展，幾個趨勢塑造了其未來發展。
發現和設定
當前的 DoH 部署需要手動設定或瀏覽器預設值。新興標準旨在改善這一點：
- 指定解析器發現（DDR）：RFC 9462 啟用 DoH 伺服器的自動發現
- DHCP/RA 選項：網路提供的 DoH 伺服器設定
- DNS SVCB 記錄：透過 DNS 本身宣傳 DoH 支援
- 加密 ClientHello（ECH）：透過加密 SNI 補充 DoH
這些機制使 DoH 採用無縫，同時尊重網路政策。
不經意 DoH（ODoH）
不經意 DoH（RFC 9230）透過分離查詢可見性和 IP 位址可見性來解決 DoH 的信任集中問題：
🔐 ODoH 隱私模型
傳統 DoH：
- DoH 提供商同時看到你的 IP 位址和查詢
- 單一信任點
不經意 DoH：
- 代理看到你的 IP 但看不到查詢（加密）
- 目標看到查詢但看不到你的 IP（來自代理）
- 需要串通才能連結 IP 和查詢
- 更強的隱私保證
ODoH 仍處於採用早期，但代表了 DNS 隱私的下一個演變。
與零信任架構整合
DoH 越來越多地整合到零信任安全模型中：
- 身分感知 DNS：DoH 查詢與使用者/裝置身分綁定
- 政策執行：基於使用者情境的 DNS 政策
- 威脅情報：與 DoH 整合的即時威脅來源
- 條件存取：基於安全態勢的 DNS 解析
這種整合在不犧牲隱私的情況下實現安全。
監管演變
政府和監管機構正在為加密 DNS 制定框架：
- 合法存取：執法部門存取 DoH 日誌的機制
- 內容過濾：DoH 提供商實施過濾的要求
- 資料本地化：DNS 資料留在境內的要求
- 透明度：DoH 提供商實務的強制報告
這些法規將塑造 DoH 的演變以及哪些提供商在不同司法管轄區營運。
效能最佳化
減少 DoH 開銷的持續工作：
- HTTP/3 採用：基於 QUIC 的傳輸減少延遲
- 0-RTT 恢復：消除重複連線的握手延遲
- 自適應 TTL：基於查詢模式的智慧快取
- 預取：對可能查詢的預測性 DNS 解析
結論
DNS over HTTPS 代表了網際網路隱私的根本轉變，加密了幾十年來一直可見的協定。透過將 DNS 查詢包裝在 HTTPS 中，DoH 防止了網路中間人的監控、操縱和審查。優勢是明確的：增強隱私、防止攻擊和規避基於 DNS 的阻擋。
然而，DoH 的採用一直存在爭議，挑戰了既定的網路管理實務，並引發了對中心化、企業安全和監管控制的擔憂。網路管理員失去了他們依賴的安全監控和故障排除的可見性。DNS 流量集中在少數大型提供商中，造成了新的風險。組織必須調整其安全策略以在沒有 DNS 可見性的情況下保持保護。
圍繞 DoH 的辯論反映了網際網路治理中更廣泛的緊張關係：隱私與控制、中心化與分散、使用者自主權與網路管理。沒有完美的解決方案——每種方法都涉及權衡和不同的信任假設。
對於個人而言，DoH 以最小的努力提供有意義的隱私保護。基於瀏覽器的 DoH 或系統級設定提供即時好處，特別是在不受信任的網路上。從 ISP 到 DoH 提供商的信任轉移通常是有利的，因為 DoH 提供商通常有更強的隱私承諾並面臨更多的公眾監督。
對於組織而言，DoH 需要仔細考慮。阻擋外部 DoH 並部署內部 DoH 伺服器可以在提供加密優勢的同時保持安全可見性。託管 DoH 服務提供了一個中間地帶，提供具有日誌記錄和過濾等企業功能的加密。關鍵是調整安全策略以在不僅僅依賴 DNS 可見性的情況下工作。
展望未來，DoH 將繼續發展。不經意 DoH 透過分離查詢可見性和 IP 位址可見性來解決中心化問題。發現機制將使 DoH 採用無縫，同時尊重網路政策。與零信任架構的整合將在不犧牲隱私的情況下實現安全。監管框架將出現，塑造 DoH 在不同司法管轄區的運作方式。
更廣泛的含義是明確的：網際網路正在向預設加密邁進。DNS 是最後一個以明文傳輸的主要協定之一。DoH 彌補了這一差距，將 HTTPS 的隱私保護擴展到網際網路命名的基礎層。這種轉變是不可逆轉的——隱私優勢太重要了，技術部署太廣泛了，無法回滾。
對於那些評估 DoH 的人來說，問題不是是否採用加密 DNS，而是如何以平衡隱私、安全和營運要求的方式這樣做。該技術已經成熟，得到廣泛支援，並且越來越成為預設。理解其影響並深思熟慮地實施它對於任何管理網路或關心網際網路隱私的人來說都是必不可少的。
DNS 的未來是加密的。DoH 正在建構這個未來，一次一個查詢。
親自嘗試
想看看 DoH 的實際效果嗎？試試我們的 DNS over HTTPS 查詢工具，透過 Cloudflare、Google 或 Quad9 執行加密 DNS 查詢。查詢多種記錄類型，親身體驗隱私優勢。
參考資料和資源
- RFC 8484：DNS Queries over HTTPS (DoH) - IETF RFC 8484
- RFC 7858：Specification for DNS over Transport Layer Security (DoT) - IETF RFC 7858
- RFC 9230：Oblivious DNS over HTTPS - IETF RFC 9230
- RFC 9462：Discovery of Designated Resolvers (DDR) - IETF RFC 9462
- Cloudflare 1.1.1.1：https://1.1.1.1/
- Google Public DNS：https://developers.google.com/speed/public-dns
- Quad9：https://www.quad9.net/
- Mozilla 受信任遞迴解析器計畫：https://wiki.mozilla.org/Security/DOH-resolver-policy