5. HTTP 統合 (HTTP Integration)

5.1. キャッシュとの相互作用 (Cache Interaction)

DoH 交換は HTTP キャッシュ [RFC7234] と互換性があります。DoH レスポンスの指定された新鮮度ライフタイムは、DNS レスポンスの Answer セクションの最小 TTL 以下でなければなりません (MUST)。そうでなければ、キャッシュは DNS が定義するよりも古いレスポンスを提供する可能性があります。

DoH クエリから派生した HTTP キャッシュキーには、URI とリクエストメディアタイプ（例：「application/dns-message」の Content-Type リクエストヘッダーフィールド）のみを含めなければなりません (MUST)。

DoH クライアントは Vary レスポンスヘッダーフィールド [RFC7231] を処理できなければなりません (MUST)。

5.2. HTTP/2

HTTP/2 [RFC7540] の使用により、DoH クライアントと DoH サーバー間の接続を多重化でき、追加の DNS クエリのオーバーヘッドを削減してパフォーマンスを向上させます。並行してクエリできる数はサーバーの HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS パラメーターと等しくなります。

5.3. サーバープッシュ (Server Push)

HTTP/2 サーバープッシュにより、DoH サーバーはクライアントのリクエストの前に DoH クライアントに DNS レスポンスを提供できます。これによりパフォーマンスが向上する場合があります。例えば、クライアントが名前の A レコードをクエリする場合、サーバーは同じ名前の AAAA レコードをプッシュできます。

DoH クライアントはサーバーからプッシュされたレスポンスを受信できなければなりませんが (MUST)、それらを使用する必要はありません。

5.4. コンテンツネゴシエーション (Content Negotiation)

他のフォーマットの可能性を許可するために、DoH クライアントは HTTP Accept リクエストヘッダーフィールドに HTTP Accept ヘッダーフィールドを含めることができます。このようなリクエストには DoH との最小限の相互運用性を確保するために「application/dns-message」メディアタイプを含めるべきです (SHOULD)。

HTTP Accept ヘッダーフィールドを使用する場合、DoH サーバーは少なくとも「Accept」を含む値を持つ Vary レスポンスヘッダーフィールドを返すべきです (SHOULD)。