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 over DNS（DoT）と DoH に共通の TLS やその他の機能の詳細が記載されています。

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

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

HTTP メソッド

YouTube の最新情報
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 Not Implemented エラーが返されます。

HTTP ステータス コード

Google Public DNS DoH は、次の HTTP ステータス コードを返します。

成功

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

ルート検索

301 Moved Permanently（恒久的な移動）
クライアントは、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 が返されます。HTTP エラーは、Question セクションのない不明化されたメッセージ、返信を示す QR フラグ、またはバイナリ DNS 解析エラーを含むその他の意味のないフラグの組み合わせに対して返されます。
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 Not Implemented（未実装）
GET メソッドと POST メソッドのみが実装されていますが、他のメソッドではこのエラーが発生します。
502 Bad Gateway（不正なゲートウェイ）
DoH サービスが Google Public DNS リゾルバにアクセスできませんでした。

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

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 などのヘッダーは最も不快なものですが、送信されたヘッダーのセットも明らかになることがあります。このリスクを最小限に抑えるには、ホスト、Content-Type（POST 用）に必要な DoH にのみ HTTP ヘッダーを送信し、必要に応じて [Accept] を送信します。 User-Agent は開発バージョンまたはテスト バージョンが対象となります。

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

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

  • RFC 8484 POST は、プライバシーに配慮したアプリケーションやブラウザモードの場合にのみ使用してください

    DoH クエリで POST を使用すると、レスポンスのキャッシュ保存が抑制され、DNS のレイテンシが増加するため、通常はおすすめしません。ただし、プライバシー重視のアプリケーションではキャッシュの削減が望ましいでしょう。また、ユーザーが最近アクセスしたドメインを特定しようとするウェブアプリのタイミング攻撃から保護することもできます。

Issues

バグを報告したり、新しい機能をリクエストしたりするには、DoH の問題を開いてください。