網路面試：什麼是 DNS over HTTPS，什麼時候該使用？

題目與適用場景

這道題適合網路、安全、後端、SRE 和售前工程職位。強回答要把 DNS over HTTPS（DoH）當作協定邊界，而不是「替 DNS 加上憑證」。DoH 把 DNS 查詢與回應放進 HTTPS 交換中。它能隱藏受保護鏈路上的查詢內容，但選定的解析器仍會收到查詢並可能記錄或過濾。選擇取決於誰需要看到 DNS、需要哪些策略控制，以及用戶端能否穩定存取解析器。

面試官考察點

• 能否區分 DNS 訊息語意與 HTTP 狀態、傳輸行為。
• 能否說清隱私邊界：到指定解析器的加密不等於匿名。
• 是否理解 GET、POST、內容型別、快取行為和啟動解析。
• 能否按部署方、可觀測性、延遲和策略比較 DoH、DoT 與普通 DNS。
• 能否定義降級和測試，而不是認為加密自動改善所有結果。

回答前需要澄清的問題

先確認用戶端和解析器由誰管理，企業過濾或稽核策略是否必須繼續生效，網路是否阻斷外連 HTTPS 或 UDP/TCP DNS，以及目標是隱藏本地網路觀察、提供應用程式 API，還是防篡改。確認由瀏覽器、作業系統解析器還是管理代理程式發起查詢。還要問延遲預算、強制入口網站、分流 DNS、DNSSEC 驗證、日誌保留和解析器不可達時的可接受回退。這些答案可能讓企業託管解析器、應用程式 DoH、DoT 或普通 DNS 更合適。

30 秒回答框架

DoH 把每個 DNS 查詢回應映射為 HTTPS 請求回應，通常使用 application/dns-message 承載 DNS wire format。它加密用戶端到解析器的鏈路，並可穿過允許 HTTPS 的網路，但解析器仍能看到查詢，企業策略也可能要求固定端點。GET 更容易重用 HTTP 快取；POST 不把編碼後的查詢放進 URL，更適合敏感請求。我會在明確需要隱私或應用程式 API 時選擇 DoH；若託管解析器和專用傳輸邊界更重要，則比較 DoT，並先定義啟動解析、快取、分流 DNS、降級、日誌最小化和驗證方案。

分步深入解答

1. 畫清協定分層

DNS 問題本身仍是 DNS 訊息。RFC 8484 把一次查詢回應映射為一次 HTTP 交換，並定義 application/dns-message 二進位表示。HTTPS 提供 TLS 機密性與完整性，HTTP 提供方法、狀態碼、連線重用和快取控制。DNS 的 NXDOMAIN 或 SERVFAIL 仍是 DNS 回應碼，可以放在 HTTP 2xx 中；HTTP 4xx 或 5xx 表示 HTTP 交換失敗，不包含原始 DNS 答案，因此用戶端要分開處理兩層錯誤。

2. 有意識地選擇 GET、POST 和快取

RFC 8484 要求 DoH 服務端為該媒體型別支援 GET 與 POST。GET 把 Base64URL 編碼的 DNS 訊息放進 dns 查詢參數，可能提高普通 HTTP 快取重用率，但也會讓查詢進入 URL 日誌、中間設備或瀏覽器歷史，除非這些表面都受控。POST 把二進位訊息放入請求本文並設定內容型別。敏感網域優先使用 POST，或使用嚴格治理的 GET 路徑；減少請求標頭，並確保快取不會用自己的新鮮度規則覆蓋 DNS TTL。Google 同時提供 RFC 8484 端點和獨立 JSON 端點，兩者是不同的 API 契約。

3. 定義隱私和策略邊界

DoH 能阻止本地觀察者讀取受保護鏈路上的明文 DNS 封包，但解析器仍可看到查詢、用戶端中繼資料、時間特徵和策略上下文。HTTPS 不會自行驗證 DNS 答案；解析器的 DNSSEC 行為和用戶端信任模型仍然重要。企業託管環境可能需要批准的解析器、分類過濾、分流區域、保留策略和稽核證據。允許應用程式任意選擇公共解析器，可能繞過這些控制，即使流量已加密。

4. 處理啟動解析、故障和回退

用戶端必須先取得 DoH 伺服器位址，才能透過同一服務解析該伺服器。啟動解析可以使用設定的 IP、可信解析器或其他設定通道；每條路徑都要做憑證校驗和輪換。區分 HTTP 錯誤、DNS 回應錯誤、逾時、強制入口網站攔截和策略拒絕。解析器故障可以回退到批准的傳輸，但靜默切到不受信任解析器會違反隱私或企業策略。預設不保留完整查詢內容，只記錄回答所用的解析器和傳輸。

5. 比較部署選擇並驗證

傳統 DNS 簡單且網路營運方可見，但明文傳輸會暴露鏈路上的查詢。DoT 透過專用 TLS 服務加密 DNS，通常適合作業系統解析器。DoH 把 DNS 融入 HTTPS，可重用 HTTP 基礎設施、瀏覽器 API 和 443 埠可達性，但會增加 HTTP 層策略與可觀測性複雜度。用受控抓包、解析器側 DNS 與 HTTP 狀態日誌、快取命中和 TTL、分流 DNS、DNSSEC 失敗、強制入口網站、解析器故障、憑證輪換和回退策略驗證選擇。測量 p50/p95/p99、錯誤類別和查詢洩露，不只看平均延遲。

高品質示範回答

DoH 是把 DNS 查詢回應放進 HTTPS 交換的協定。DNS 訊息保持原有含義；HTTPS 保護用戶端到指定解析器的鏈路，HTTP 提供方法、狀態碼、連線重用和快取行為。NXDOMAIN 可以放在 HTTP 2xx 中，HTTP 5xx 則表示沒有 DNS 答案的傳輸或服務失敗。我會在需要應用程式級 API 或隱藏本地網路查詢、且能指定批准解析器時使用 DoH。敏感網域優先 POST，減少請求標頭，並明確解析器策略、DNSSEC、分流區域和日誌保留。啟動解析要透過設定或可信路徑完成，回退必須符合策略。上線前測試快取和 TTL、GET 的 URL 日誌暴露、強制入口網站、憑證輪換、解析器故障、DNSSEC 錯誤，以及是否有查詢繞過指定解析器。

常見錯誤

• 說「HTTPS 讓 DNS 匿名」 → 指定解析器仍能看到查詢和中繼資料 → 說明具體加密鏈路與解析器信任邊界。
• 把 DNS NXDOMAIN 當 HTTP 錯誤 → DNS 回應碼可以在 HTTP 2xx 中 → 分開解析 HTTP 與 DNS 狀態層。
• 使用 GET 傳敏感查詢卻不討論 URL 日誌 → 編碼後的查詢可能進入歷史或中間日誌 → 使用 POST 或受控快取與日誌策略。
• 說 DoH 永遠優於 DoT → 部署方、策略、可達性和可觀測性不同 → 先比較實際環境。
• 透過同一個尚未解析的解析器啟動 DoH 主機名 → 形成循環依賴 → 預置位址或可信啟動路徑。
• 逾時後回退到任意公共解析器 → 可能繞過隱私和企業過濾 → 限制批准的傳輸與端點。
• 只測平均延遲 → 故障、快取未命中和洩露被隱藏 → 分段看 p95/p99、錯誤類別、TTL 與解析器身分。

追問及應對

DoH 會驗證 DNS 答案是真的嗎？

不會。TLS 驗證的是用戶端選擇的 HTTPS 伺服器。答案真實性取決於解析器的驗證行為以及用戶端對解析器的信任；DNSSEC 和 HTTPS 是兩件事。設計應明確是否強制驗證，以及驗證失敗如何呈現。

為什麼 HTTP 200 裡可能是失敗的 DNS 查詢？

因為 HTTP 交換本身成功並傳輸了合法 DNS 訊息。DNS 訊息可能帶有 NXDOMAIN、SERVFAIL 等回應碼。用戶端必須解析兩層，不能把合法的 DNS 負面答案當 HTTP 失敗重試。

什麼時候 DoT 更合適？

當作業系統或企業解析器控制傳輸、需要專用 DNS 埠和清晰網路策略、又不需要面向瀏覽器的 HTTP API 時，DoT 很合適。需要現有 HTTPS 可達性或應用程式 API 時可選 DoH。依據應是所有權和策略，而不是「加密一定更好」。

強制入口網站下 DoH 解析器不可達怎麼辦？

偵測入口網站或反覆 TLS/HTTP 失敗，停止重試放大，然後按設定策略使用批准的回退、暫停解析並提示恢復，或僅在允許時暫時使用網路提供的 DNS。上線前必須測試，因為盲目回退會洩露所有查詢。