DNS-over-HTTPS（DoH）

Google Public DNS は、次のエンドポイントで 2 つの異なる DoH API を提供します。

• https://dns.google/dns-query – RFC 8484（GET と POST）
• https://dns.google/resolve? – JSON API（GET）

セキュア トランスポートの概要ページでは、両方の API を使用する curl コマンドラインの例と、TLS の詳細、DNS over TLS（DoT）と DoH の両方に共通するその他の機能について説明します。

DoH は、IPv6 専用の Google Public DNS64 サービスでもサポートされています。

Google Public DNS では、API 呼び出しに対して安全でない http: URL の使用はサポートされていません。

HTTP メソッド

GET

GET メソッドを使用すると、キャッシュがより効率的に保存されるため、レイテンシを短縮できます。RFC 8484 GET リクエストには、Base64Url でエンコードされた DNS メッセージを含む ?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 Public DNS DoH は、次の HTTP ステータス コードを返します。

成功

200 OK

HTTP 解析と DNS リゾルバとの通信が成功しました。レスポンスの本文の内容は、クエリ エンドポイント、Accept ヘッダー、GET パラメータに応じて、バイナリまたは JSON エンコードの DNS レスポンスになります。

リダイレクト

301 恒久的に移動しました

クライアントは、Location: ヘッダーで指定された URL で再試行する必要があります。元のクエリが POST リクエストの場合、新しい URL で dns GET パラメータ引数が指定されている場合のみ、クライアントは GET で再試行する必要があります。それ以外の場合は、クライアントは POST で再試行する必要があります。

302 Found、307 Temporary Redirect、308 Permanent Redirect などの他のコードは、今後使用する可能性があります。DoH クライアントは 4 つのコードをすべて処理する必要があります。

永続的なコード 301 と 308 を含むレスポンスは無期限にキャッシュに保存してください。必要に応じて、新しい URL を使用して元の構成を更新するよう求めるメッセージが表示されることがあります。

307 または 308 レスポンスを受け取った POST リクエストは常に POST で再試行する必要があります。

エラー

エラー レスポンスの本文では、HTTP ステータスの説明が HTML または書式なしテキストで示されます。

400 不正なリクエスト

GET パラメータの解析に関する問題、または無効な DNS リクエスト メッセージの。GET パラメータが不適切な場合は、HTTP 本文でエラーを説明します。無効な DNS メッセージの大半は、FORMERR とともに 200 OK を受け取ります。質問セクションのないメッセージの文字化け、返信を示す QR フラグ、またはバイナリ DNS 解析エラーを含むその他の意味不明なフラグの組み合わせに対して、HTTP エラーが返されます。

413 ペイロードが大きすぎる

RFC 8484 POST リクエスト本文が最大メッセージ サイズ（512 バイト）を超えました。

414 URI が長すぎる

GET クエリ ヘッダーが大きすぎるか、dns パラメータの Base64Url でエンコードされた DNS メッセージが 512 バイトの最大メッセージ サイズを超えています。

415 Unsupported Media Type（サポートされていないメディアタイプ）

POST 本文に application/dns-message Content-Type ヘッダーがありませんでした。

429 Too Many Requests（リクエスト数が多すぎる）

クライアントが一定時間内に送信したリクエストの数が多すぎます。クライアントは、Retry-After ヘッダーで指定された時間（秒単位の相対時間）までリクエストの送信を停止する必要があります。

500 Internal Server Error（内部サーバーエラー）

Google Public DNS 内部 DoH エラー。

501 未実装

GET メソッドと POST メソッドのみが実装されており、他のメソッドではこのエラーが発生します。

502 Bad Gateway（不正なゲートウェイ）

DoH サービスが Google Public DNS リゾルバに接続できませんでした。

502 レスポンスの場合は、別の Google Public DNS アドレスで再試行すると解決する可能性がありますが、より効果的なフォールバック レスポンスとして、別の DoH サービスを試すか、従来の UDP または TCP DNS（8.8.8.8）に切り替えることをおすすめします。

DoH のメリット

TLS 暗号化だけでなく HTTPS を使用すると、次のような実用的メリットが得られます。

• 広く利用でき、適切にサポートされている HTTPS API により、Google Public DNS 自体と潜在的なクライアントの両方の実装を簡素化できます。
• HTTPS サービスを使用すると、ウェブアプリからすべての DNS レコードタイプにアクセスできます。これにより、通常はホストからアドレスへのルックアップのみをサポートする既存のブラウザと OS の DNS API の制限を回避できます。
• QUIC UDP ベースの HTTPS サポートを実装するクライアントは、TCP トランスポートの使用時に発生する可能性のあるヘッドオブライン ブロックなどの問題を回避できます。

DoH のプライバシーのベスト プラクティス

DoH アプリケーションのデベロッパーは、RFC 8484 で概説されている、以下に拡張されたプライバシー ベスト プラクティスを考慮する必要があります。

• HTTP ヘッダーの使用を制限する

  HTTP ヘッダーは、クライアントの DoH 実装に関する情報を示し、クライアントの匿名化に使用できます。Cookie、User-Agent、Accept-Language などのヘッダーは最も邪魔な要素ですが、送信されたヘッダーのセットでさえ明らかになる可能性があります。このリスクを最小限に抑えるため、DoH に必要な HTTP ヘッダー（Host、Content-Type（POST の場合））のみを送信し、必要に応じて Accept を送信します。開発バージョンまたはテスト バージョンにユーザー エージェントを含める必要があります。

• EDNS パディング オプションを使用する

  EDNS パディング オプションの使用に関する RFC 8467 のガイダンスに従って、トラフィック分析から保護するために、DoH クエリをいくつかの一般的な長さにパディングします。HTTP/2 パディングも使用できますが、EDNS パディングとは異なり、DoH サーバーからのレスポンスにパディングは引き出されません。

• RFC 8484 POST は、プライバシーに配慮が必要なアプリケーションまたはブラウザモードにのみ使用する

  DoH クエリに POST を使用すると、レスポンスのキャッシュ可能性が低下し、DNS のレイテンシが増加する可能性があるため、通常はおすすめしません。ただし、プライバシーに配慮が必要なアプリではキャッシュを減らすことがおそらく望ましいことであり、ユーザーが最近アクセスしたドメインを特定しようとするウェブアプリからのタイミング攻撃から保護される可能性があります。

問題

バグの報告または新機能のリクエストについては、DoH の問題をオープンしてください。