DNS-over-HTTPS (DoH)

Google 公用 DNS 會在下列端點提供兩個不同的 DoH API：

  • https://dns.google/dns-query – RFC 8484 (GET 和 POST)
  • https://dns.google/resolve? – JSON API (GET)

安全傳輸總覽頁面提供使用這兩種 API 的 curl 指令列範例，以及 DNS over TLS (DoT) 和 DoH 的常見傳輸層安全標準 (TLS) 和其他功能的詳細資料。

Google 公用 DNS64 服務也支援 DoH。

Google 公用 DNS 不支援不安全的 http: 網址，無法進行 API 呼叫。

HTTP 方法

GET
使用 GET 方法可以更有效率地快取，因此可以縮短延遲時間。RFC 8484 GET 要求必須包含 ?dns= 查詢參數，且其中含有以 Base64Url 編碼的 DNS 訊息。GET 方法是 JSON API 唯一支援的方法。
POST
POST 方法僅支援 RFC 8484 API，並在要求主體和 DoH HTTP 回應中使用含有 Content-Type application/dns-message 的二進位 DNS 訊息。
HEAD
目前不支援 HEAD，且會傳回 400 Bad Request 錯誤。

其他方法則會傳回 501「未執行」錯誤。

HTTP 狀態碼

Google 公用 DNS DoH 會傳回下列 HTTP 狀態碼：

成功

200 成功
成功與 DNS 解析器進行 HTTP 剖析與通訊，且回應主體內容是以二進位或 JSON 編碼形式的 DNS 回應，視查詢端點、Accept 標頭和 GET 參數而定。

重新導向

301 永久移動
用戶端應在 Location: 標頭中提供的網址重試。如果原始查詢是 POST 要求，用戶端應只在新網址指定 dns GET 參數引數時使用 GET 重試，否則用戶端應使用 POST 重試。

日後可能會使用其他代碼，例如 302 Found、307 暫時重新導向或 308 永久重新導向，而且 DoH 用戶端應處理全部四種代碼。

含有永久 301 和 308 程式碼的回應應無限期快取，如果可行，系統可能會提示使用者使用新網址更新原始設定。

收到 307 或 308 回應的 POST 要求應一律使用 POST 重試。

錯誤

錯誤回應會在內文中使用 HTML 或純文字說明 HTTP 狀態。

400 要求無效
剖析 GET 參數或 DNS 要求訊息無效。如果是錯誤的 GET 參數，HTTP 主體應說明錯誤。多數無效的 DNS 訊息會收到 200 OK 和 FORMERR。如果是沒有「問題」區段的亂碼訊息、QR 標記 (表示回覆)，或其他內含二進位 DNS 剖析錯誤的非意義旗標組合，系統就會傳回 HTTP 錯誤。
413 酬載過大
RFC 8484 POST 要求主體超過訊息大小上限 (512 位元組)。
414 URI 過長
GET 查詢標頭過大，或 dns 參數的 Base64Url 編碼 DNS 訊息超過訊息大小上限 (512 位元組)。
415 不支援的媒體類型
POST 主體沒有 application/dns-message Content-Type 標頭。
429 要求數量過多
用戶端在指定時間內傳送過多要求。用戶端應停止傳送要求，直到「重試後」標頭中指定的時間 (以秒為單位) 指定時間。
500 內部伺服器錯誤
Google 公用 DNS 內部 DoH 錯誤。
501 未執行
只有實作 GET 和 POST 方法，其他方法才會出現這個錯誤。
502 閘道錯誤
DoH 服務無法與 Google 公用 DNS 解析器聯絡。

如果是 502 回應，雖然重試替代 Google 公用 DNS 位址可能有所幫助，但更好的備援回應是嘗試其他 DoH 服務，或是改用 8.8.8.8 的傳統 UDP 或 TCP DNS。

DoH 的優點

使用 HTTPS 而非只使用 TLS 加密，能帶來以下實際好處：

  • 廣受使用且支援完整支援的 HTTPS API，可簡化 Google 公用 DNS 本身和潛在客戶的實作。
  • HTTPS 服務可讓網頁應用程式存取所有 DNS 記錄類型，藉此避免現有瀏覽器和 OS DNS API 的限制，而這類 API 通常僅支援主機與位址查詢。
  • 如果用戶端實作以 QUIC UDP 為基礎的 HTTPS 支援，則可避免在使用 TCP 傳輸時，發生行頭阻斷等問題。

DoH 的隱私權最佳做法

DoH 應用程式的開發人員應考慮 RFC 8484 中所述的隱私權最佳做法，並進一步擴展以下內容：

  • 限制使用 HTTP 標頭

    HTTP 標頭會顯示用戶端 DoH 實作的相關資訊，並可用於將用戶端去識別化。Cookie、User-Agent 和 Accept-Language 等標頭是最嚴重的違規者，但甚至可以揭露已傳送的標頭組合。為了盡可能降低這項風險，請僅傳送 DoH：主機、Content-Type (針對 POST) 所需的 HTTP 標頭，以及視需要接受。任何開發或測試版都必須包含使用者代理程式。

  • 使用 EDNS 邊框間距選項

    按照 RFC 8467 中的指南，使用 EDNS 邊框間距選項將 DoH 查詢填充到幾個常見的長度，以防止流量分析。您也可以使用 HTTP/2 邊框間距，但與 EDNS 邊框間距不同，並不會在 DoH 伺服器發出回應時產生邊框間距。

  • 僅針對隱私權敏感應用程式或瀏覽器模式使用 RFC 8484 POST

    針對 DoH 查詢使用 POST 會降低迴應的快取性並增加 DNS 延遲時間，因此通常不建議採取這種做法。不過，對於隱私權敏感的應用程式，減少快取可能是比較理想的做法，而且可能會在網頁應用程式嘗試判斷使用者最近造訪的網域時，避免時間攻擊。

問題

如要回報錯誤或提出新功能建議，請開啟 DoH 問題。