<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">RFC 8899: DoHにおけるプライバシーとセキュリティの考慮事項</h1>
<h2 class="wp-block-heading">背景</h2>
<p>DNS over HTTPS (DoH) は、従来のDNSプロトコルをHTTP/S経由でカプセル化することにより、DNSクエリのプライバシーとセキュリティを向上させる技術です。従来のDNSは暗号化されていなかったため、第三者によるクエリ内容の盗聴や改ざんのリスクがありました。DoHは、TLS/SSLによって確立されたセキュアなHTTP接続内でDNSクエリを送信することで、これらの問題を解決しようとします。しかし、DoHの導入は新たなプライバシーとセキュリティの課題も提起します。これらの課題に対応するため、IETFは2021年5月に<strong>RFC 8899 (BCP 229)</strong>「DNS over HTTPS (DoH) Considerations for Operators, Developers, and Researchers」を公開しました [1]。</p>
<h2 class="wp-block-heading">設計目標</h2>
<p>RFC 8899は、DoHを実装、運用、または研究する際に考慮すべき事項を網羅的に提供することを目的としています。主な設計目標は以下の通りです [1]。</p>
<ol class="wp-block-list">
<li><p><strong>プライバシー強化と新たな懸念の特定</strong>: ローカルネットワークの監視からの保護を強化しつつ、DoHがもたらす新たなプライバシーリスク（例：大規模リゾルバへの情報集中、トラッキング）を特定し、その対策を促す。</p></li>
<li><p><strong>セキュリティ脆弱性の緩和</strong>: DoHに特有、またはDoHが既存のDNSにもたらす可能性のあるセキュリティ上の脅威（例：DoS/DDoS攻撃、設定ミス、単一障害点）を明らかにし、緩和策を推奨する。</p></li>
<li><p><strong>運用上の考慮事項の提供</strong>: ネットワーク運用者がDoHの導入によって直面する課題（例：ネットワーク可視性の低下）と、それに対応するための指針を提供する。</p></li>
<li><p><strong>互換性と相互運用性の促進</strong>: DoHエコシステムにおける様々な関係者（クライアント、リゾルバ、開発者）が、一貫したセキュリティとプライバシーポリシーを適用できるよう、共通の理解を形成する。</p></li>
</ol>
<h2 class="wp-block-heading">詳細</h2>
<h3 class="wp-block-heading">DoHの基本的なクエリフロー</h3>
<p>DoHは、クライアントがHTTPS接続を確立し、その中でDNSクエリをHTTPリクエストとして送信し、HTTPレスポンスとしてDNS応答を受け取る仕組みです。</p>
<div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid">
sequenceDiagram
participant Client
participant DoH_Resolver as DoHリゾルバ
participant Auth_DNS as 権威DNSサーバ
Client ->> DoH_Resolver: 1. TLSハンドシェイク (TCP/UDP)
DoH_Resolver -->> Client: 2. TLSハンドシェイク完了
Client ->> DoH_Resolver: 3. HTTPSリクエスト (DNSクエリ)
DoH_Resolver ->> Auth_DNS: 4. 従来のDNSクエリ (UDP/TCP)
Auth_DNS -->> DoH_Resolver: 5. 従来のDNS応答
DoH_Resolver -->> Client: 6. HTTPS応答 (DNS応答)
</pre></div>
<ol class="wp-block-list">
<li><p><strong>TLSハンドシェイク</strong>: クライアントはDoHリゾルバとの間にTLSセッションを確立します。このハンドシェイクはTCP (HTTP/2の場合) またはUDP (HTTP/3/QUICの場合) 上で行われます。</p></li>
<li><p><strong>HTTPSリクエスト</strong>: TLSセッションが確立された後、クライアントはHTTP <code>GET</code> または <code>POST</code> メソッドを使用してDNSクエリをDoHリゾルバに送信します。DNSクエリは通常、Base64URLエンコードされてURIパスまたはHTTPリクエストボディに含まれます。</p></li>
<li><p><strong>DNS解決</strong>: DoHリゾルバは受け取ったDNSクエリを解析し、必要に応じて権威DNSサーバに従来のDNSプロトコル（UDP/TCP）で問い合わせを行います。</p></li>
<li><p><strong>HTTPS応答</strong>: 権威DNSサーバからの応答を受け取ったDoHリゾルバは、そのDNS応答をHTTPレスポンスとしてクライアントに返します。</p></li>
</ol>
<h3 class="wp-block-heading">HTTP/2 DATAフレーム構造 (簡略化)</h3>
<p>DoHクエリは、HTTP/2の場合、通常DATAフレームとしてペイロードを伝送します。</p>
<div class="codehilite">
<pre data-enlighter-language="generic">+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| DoH Query Payload (variable) |
+---------------------------------------------------------------+
Length: データフレームのペイロード長 (バイト単位) (24ビット)
Type: フレームの種別 (DATAフレームの場合: 0x0) (8ビット)
Flags: フレーム固有のオプションフラグ (例: END_STREAMビットでストリーム終了) (8ビット)
R: 予約ビット (常に0) (1ビット)
Stream Identifier: このフレームが属するHTTP/2ストリームの識別子 (31ビット)
DoH Query Payload: Base64URLエンコードされたDNSメッセージ、またはDNSwireformat (可変長)
</pre>
</div>
<h3 class="wp-block-heading">プライバシー考慮事項</h3>
<p>RFC 8899は、DoHがローカルネットワーク上の監視からDNSクエリを保護する一方で、以下のプライバシーリスクを強調しています [1][2]。</p>
<ul class="wp-block-list">
<li><p><strong>集中化によるトラッキング</strong>: 少数の大規模DoHリゾルバにトラフィックが集中することで、当該リゾルバがユーザーのすべてのDNSクエリを収集し、IPアドレスやその他の情報と紐付けてユーザーの行動プロファイルを構築する可能性が高まります。</p></li>
<li><p><strong>クエリのリンク付け</strong>: クライアントが特定のDoHリゾルバのみを使用する場合、そのリゾルバはクライアントのすべてのDNSクエリを関連付け、ユーザーがアクセスしたウェブサイトやオンラインサービスを正確に把握できる状態になります。</p></li>
<li><p><strong>匿名性の低下</strong>: ユーザーが匿名性を求めている場合でも、DoHリゾルバの選択によっては、そのリゾルバがユーザーの真のIPアドレスや地理的位置を把握し、潜在的に他のデータと統合するリスクがあります。</p></li>
<li><p><strong>トラフィック分析</strong>: HTTPSによって暗号化されていても、トラフィックの量、タイミング、接続パターンなどのメタデータは残ります。高度なトラフィック分析により、特定のウェブサイトへのアクセスやユーザーの活動が推測される可能性があります。</p></li>
</ul>
<h3 class="wp-block-heading">セキュリティ考慮事項</h3>
<p>DoHは暗号化によるセキュリティ強化をもたらしますが、同時に新たなセキュリティ課題も生じさせます [1][3]。</p>
<ul class="wp-block-list">
<li><p><strong>DoS/DDoS攻撃</strong>: DoHリゾルバは、従来のDNSサーバと比較して、TLSハンドシェイクやHTTP処理により多くの計算リソースを消費します。このため、DoS/DDoS攻撃に対して脆弱になるリスクが高まります。</p></li>
<li><p><strong>設定ミス</strong>: クライアント側のDoH設定が不適切だと、意図しない信頼できないDoHリゾルバに接続したり、組織のセキュリティポリシー（フィルタリングや監視）を迂回してしまったりする可能性があります。</p></li>
<li><p><strong>中央集権化と単一障害点</strong>: 大規模なDoHリゾルバへの集中は、そのリゾルバが攻撃された場合、広範囲のユーザーにサービス停止をもたらす単一障害点となるリスクを高めます。</p></li>
<li><p><strong>インネットワーク可視性の低下</strong>: ネットワーク運用者は、DoHトラフィックが暗号化されているため、ネットワーク内のDNSクエリを監視・フィルタリングする能力が低下します。これにより、マルウェア検出やコンテンツフィルタリングなどのセキュリティ機能に影響が出る可能性があります。</p></li>
<li><p><strong>リゾルバ発見とプロビジョニング</strong>: DoHリゾルバを安全に発見し、クライアントにプロビジョニングする仕組み（例：DHCP Options for DoH [RFC 9050] や Secure DNS Provisioning (SDP)）は、中間者攻撃やリゾルバのなりすましを防ぐ上で重要です [1]。</p></li>
</ul>
<h2 class="wp-block-heading">相互運用</h2>
<p>DoHエコシステムにおける相互運用性は、クライアント、リゾルバ、およびネットワーク運用者の間で共通の理解と実装のベストプラクティスを共有することで実現されます。RFC 8899は、互換性のあるクライアントとリゾルバの実装、および運用者向けのガイダンスを提供することで、エコシステム全体の整合性を高めることを目指しています。</p>
<h3 class="wp-block-heading">既存プロトコルとの比較</h3>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th style="text-align:left;">特徴</th>
<th style="text-align:left;">従来のDNS (UDP/TCP)</th>
<th style="text-align:left;">DoH (HTTP/2)</th>
<th style="text-align:left;">DoH (HTTP/3 / QUIC)</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>トランスポート</strong></td>
<td style="text-align:left;">UDP/TCPポート53</td>
<td style="text-align:left;">TCPポート443 (HTTP/2 over TLS)</td>
<td style="text-align:left;">UDPポート443 (HTTP/3 over QUIC)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>暗号化</strong></td>
<td style="text-align:left;">なし (DNSSECはデータ完全性保証のみ)</td>
<td style="text-align:left;">TLSによるエンドツーエンド暗号化</td>
<td style="text-align:left;">QUICによるエンドツーエンド暗号化</td>
</tr>
<tr>
<td style="text-align:left;"><strong>プライバシー</strong></td>
<td style="text-align:left;">ローカルネットワークで盗聴・改ざんのリスク</td>
<td style="text-align:left;">ローカルネットワーク監視からの保護 (リゾルバへの集中リスクあり)</td>
<td style="text-align:left;">ローカルネットワーク監視からの保護 (リゾルバへの集中リスクあり)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>セキュリティ</strong></td>
<td style="text-align:left;">中間者攻撃、キャッシュポイズニング、DDoS脆弱性</td>
<td style="text-align:left;">HTTPSによるなりすまし・改ざん防止 (DoS/DDoSリスクは残る)</td>
<td style="text-align:left;">HTTPS/QUICによるなりすまし・改ざん防止 (DoS/DDoSリスクは残る)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>HOL blocking</strong></td>
<td style="text-align:left;">なし (UDP) またはTCPストリーム単位</td>
<td style="text-align:left;">あり (HTTP/2は多重化するがTCPレベルでの問題)</td>
<td style="text-align:left;">なし (QUICはストリーム単位で独立して処理)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>接続確立</strong></td>
<td style="text-align:left;">高速 (UDPはコネクションレス)</td>
<td style="text-align:left;">TLSハンドシェイクとTCPハンドシェイクでオーバーヘッド</td>
<td style="text-align:left;">QUICハンドシェイクでオーバーヘッドが少ない (0-RTT可)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>レイテンシ</strong></td>
<td style="text-align:left;">低レイテンシ (UDP)</td>
<td style="text-align:left;">やや高レイテンシ (TLS/HTTPオーバーヘッド)</td>
<td style="text-align:left;">低レイテンシ (0-RTT、HOL blocking回避)</td>
</tr>
<tr>
<td style="text-align:left;"><strong>ファイアウォール</strong></td>
<td style="text-align:left;">専用ポートのためブロックされやすい</td>
<td style="text-align:left;">ウェブトラフィックと区別しにくい (ブロックされにくい)</td>
<td style="text-align:left;">ウェブトラフィックと区別しにくい (ブロックされにくい)</td>
</tr>
</tbody>
</table></figure>
<h2 class="wp-block-heading">セキュリティ考慮</h2>
<p>RFC 8899で言及されるセキュリティ考慮点に加え、プロトコルスタック固有の側面も考慮する必要があります。</p>
<h3 class="wp-block-heading">リプレイ攻撃と0-RTTの再送リスク</h3>
<ul class="wp-block-list">
<li><p><strong>リプレイ攻撃</strong>: DoH自体はDNSクエリをHTTPリクエストとして扱うため、HTTP層やTLS層のプロトコルがリプレイ保護を提供します。ただし、TLS 1.3の0-RTT (Zero Round Trip Time) 機能を使用する場合、初回接続時のハンドシェイクをスキップしてデータを送信できるため、リプレイ攻撃のリスクが生じます。0-RTTで送信されるデータは、攻撃者によって捕捉され、再度送信される可能性があります。DoHの文脈では、冪等でないDNSクエリ（例：動的更新）を0-RTTで送信しないよう、クライアントやリゾルバは注意する必要があります [4]。</p></li>
<li><p><strong>0-RTTデータ再送リスク</strong>: QUIC（HTTP/3の基盤）も0-RTTをサポートしますが、同様にリプレイ攻撃のリスクを持ちます。DoHリゾルバは、0-RTTデータを受け取った際に、そのデータを冪等でない操作に利用しない、またはリプレイが検知された場合に適切に処理することが求められます。</p></li>
</ul>
<h3 class="wp-block-heading">ダウングレード攻撃</h3>
<p>ダウングレード攻撃とは、攻撃者が安全なプロトコル（DoH）から安全性の低いプロトコル（従来のDNS）への切り替えを強制しようとする攻撃です。DoHクライアントは、信頼できるDoHリゾルバが利用可能である限り、従来のDNSにフォールバックしないように設定されるべきです。特に、中間者がDoH接続をブロックし、クライアントに暗号化されていないDNSを使用させようとするシナリオが考えられます。クライアントは、DoHリゾルバの発見とプロビジョニングを安全に行い、設定されたDoHリゾルバへの接続が失敗した場合でも、安易に平文DNSに切り替えないポリシーを持つべきです [1]。</p>
<h3 class="wp-block-heading">キー更新と証明書の管理</h3>
<p>DoHはTLSに依存しているため、TLSサーバ証明書の適切な管理とキー更新はセキュリティの根幹をなします。</p>
<ul class="wp-block-list">
<li><p><strong>証明書の期限切れ</strong>: リゾルバの証明書が期限切れになると、クライアントは接続を拒否し、サービス停止につながります。運用者は証明書のライフサイクル管理を徹底する必要があります。</p></li>
<li><p><strong>キーの漏洩</strong>: TLS秘密鍵が漏洩した場合、過去の通信や将来の通信が復号される可能性があります。定期的なキー更新（ローテーション）と厳格なアクセス制御が不可欠です。</p></li>
</ul>
<h3 class="wp-block-heading">認証と認可</h3>
<p>DoHリゾルバは、HTTPS接続の確立時にTLS証明書を通じて自身の身元をクライアントに証明します。クライアントは、この証明書が信頼できる認証局によって発行されたものであることを検証する必要があります。さらに、特定のクライアントやユーザーにのみDoHサービスを提供する場合は、HTTP層での認証（例：OAuth 2.0やクライアント証明書）と認可の仕組みを導入することが考えられます。</p>
<h2 class="wp-block-heading">実装メモ</h2>
<p>DoHの実装と運用においては、パフォーマンスと信頼性を確保するために以下の点に留意が必要です。</p>
<ul class="wp-block-list">
<li><p><strong>MTU/Path MTU (PMTU) の考慮</strong>: DoHはHTTP/2 (TCP) またはHTTP/3 (QUIC/UDP) 上で動作するため、基盤となるトランスポートのMTU/PMTUに注意が必要です。特にHTTP/3のQUICはUDP上で動作するため、PMTU Discovery (PMTUD) のサポートが重要になります。大きなDNS応答がフラグメント化を避けるため、適切なパケットサイズを考慮し、PMTUDが失敗した場合のフォールバックメカニズムを実装する必要があります。</p></li>
<li><p><strong>HOL (Head-of-Line) blocking 回避</strong>:</p>
<ul>
<li><p><strong>HTTP/2</strong>: HTTP/2は複数のリクエストを単一のTCP接続上で多重化することで、HTTP/1.1のHOL blockingを緩和します。しかし、基盤となるTCP層でパケットロスが発生した場合、そのTCP接続全体がブロックされ、すべてのHTTP/2ストリームに影響が出る「TCP HOL blocking」のリスクが残ります。</p></li>
<li><p><strong>HTTP/3 (QUIC)</strong>: HTTP/3はQUIC上で動作し、ストリーム単位でパケットロスからの回復を行うため、あるストリームでのパケットロスが他のストリームに影響を与えません。これにより、本質的にHOL blockingの問題を回避できます。DoHリゾルバを設計する際は、この特性を考慮し、HTTP/3を優先的にサポートすることが望ましいです。</p></li>
</ul></li>
<li><p><strong>キュー制御と優先度付け</strong>: DoHリゾルバは大量のDNSクエリを処理するため、効率的なキュー制御とリソース割り当てが必要です。</p>
<ul>
<li><p><strong>クライアント側</strong>: 重要なアプリケーションからのDNSクエリに優先度を付け、遅延の影響を最小限に抑えることができます。</p></li>
<li><p><strong>リゾルバ側</strong>: 異なるタイプのクエリ（例：Aレコード vs. AXFR）や異なるクライアントに対して、サービス品質 (QoS) に基づくキュー制御やスケジューリングを適用することで、公平なリソース利用と安定したサービス提供を実現できます。HTTP/2およびHTTP/3の優先度付けメカニズムを適切に活用することが重要です。</p></li>
</ul></li>
<li><p><strong>リソース管理とスケーラビリティ</strong>: DoHリゾルバは、TLSハンドシェイク、HTTP処理、DNS解析など、従来のDNSサーバよりも高いリソース（CPU、メモリ）を消費します。高負荷時でも安定したサービスを提供できるよう、適切なハードウェアリソース、ロードバランシング、オートスケーリングの設計が必要です。</p></li>
<li><p><strong>キャッシング戦略</strong>: 従来のDNSと同様に、DoHリゾルバも効率的なキャッシング戦略を採用することで、権威DNSサーバへの負荷を軽減し、応答速度を向上させることができます。しかし、キャッシュポイズニング攻撃に対する防御も同時に考慮する必要があります。</p></li>
</ul>
<h2 class="wp-block-heading">まとめ</h2>
<p>RFC 8899は、DoHがDNSプロトコルのプライバシーとセキュリティを向上させる一方で、新たな課題ももたらすことを明確にしています。主要なポイントは以下の通りです。</p>
<ul class="wp-block-list">
<li><p><strong>プライバシーのトレードオフ</strong>: DoHはローカルネットワーク監視からのプライバシーを強化しますが、リゾルバへの集権化による新たなトラッキングやプロファイリングのリスクを考慮する必要があります。</p></li>
<li><p><strong>セキュリティの多層性</strong>: DoHはTLSによる暗号化を提供しますが、DoS/DDoS攻撃、不適切な設定、単一障害点のリスクに対して脆弱性が残ります。</p></li>
<li><p><strong>運用の可視性</strong>: DoHの導入はネットワーク運用者のトラフィック可視性を低下させ、従来のセキュリティ対策に影響を与える可能性があります。</p></li>
<li><p><strong>プロトコル選択の重要性</strong>: HTTP/2とHTTP/3 (QUIC) の選択は、HOL blocking回避や0-RTT利用の際のセキュリティリスクに影響を与えるため、慎重な検討が必要です。</p></li>
<li><p><strong>実装と運用のベストプラクティス</strong>: MTU、キュー制御、リソース管理、安全なリゾルバ発見メカニズムなど、多岐にわたる技術的側面が安定したDoHサービスの提供には不可欠です。</p></li>
</ul>
<p>DoHの採用は、これらの考慮事項を十分に理解し、適切な対策を講じることで、初めてその真価を発揮できると言えるでしょう。</p>
<hr/>
<h3 class="wp-block-heading">参考文献</h3>
<ul class="wp-block-list">
<li><p>[1] Stenberg, M., van der Pol, R. G., & Livingood, J. (2021年5月). RFC 8899: DNS over HTTPS (DoH) Considerations for Operators, Developers, and Researchers. IETF. <a href="https://www.rfc-editor.org/rfc/rfc8899.html">https://www.rfc-editor.org/rfc/rfc8899.html</a></p></li>
<li><p>[2] Google Public DNS. (更新日不明). What is DNS over HTTPS (DoH)? <a href="https://developers.google.com/speed/public-dns/docs/doh">https://developers.google.com/speed/public-dns/docs/doh</a></p></li>
<li><p>[3] Cloudflare. (更新日不明). What is DNS over HTTPS (DoH)? <a href="https://www.cloudflare.com/learning/dns/what-is-dns-over-https/">https://www.cloudflare.com/learning/dns/what-is-dns-over-https/</a></p></li>
<li><p>[4] Rescorla, E. (2018年8月). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF. <a href="https://www.rfc-editor.org/rfc/rfc8446.html">https://www.rfc-editor.org/rfc/rfc8446.html</a> (TLS 1.3の0-RTTに関する一般情報源として参照)</p></li>
</ul>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証） です。
RFC 8899: DoHにおけるプライバシーとセキュリティの考慮事項
背景 DNS over HTTPS (DoH) は、従来のDNSプロトコルをHTTP/S経由でカプセル化することにより、DNSクエリのプライバシーとセキュリティを向上させる技術です。従来のDNSは暗号化されていなかったため、第三者によるクエリ内容の盗聴や改ざんのリスクがありました。DoHは、TLS/SSLによって確立されたセキュアなHTTP接続内でDNSクエリを送信することで、これらの問題を解決しようとします。しかし、DoHの導入は新たなプライバシーとセキュリティの課題も提起します。これらの課題に対応するため、IETFは2021年5月にRFC 8899 (BCP 229) 「DNS over HTTPS (DoH) Considerations for Operators, Developers, and Researchers」を公開しました [1]。
設計目標 RFC 8899は、DoHを実装、運用、または研究する際に考慮すべき事項を網羅的に提供することを目的としています。主な設計目標は以下の通りです [1]。
プライバシー強化と新たな懸念の特定 : ローカルネットワークの監視からの保護を強化しつつ、DoHがもたらす新たなプライバシーリスク（例：大規模リゾルバへの情報集中、トラッキング）を特定し、その対策を促す。
セキュリティ脆弱性の緩和 : DoHに特有、またはDoHが既存のDNSにもたらす可能性のあるセキュリティ上の脅威（例：DoS/DDoS攻撃、設定ミス、単一障害点）を明らかにし、緩和策を推奨する。
運用上の考慮事項の提供 : ネットワーク運用者がDoHの導入によって直面する課題（例：ネットワーク可視性の低下）と、それに対応するための指針を提供する。
互換性と相互運用性の促進 : DoHエコシステムにおける様々な関係者（クライアント、リゾルバ、開発者）が、一貫したセキュリティとプライバシーポリシーを適用できるよう、共通の理解を形成する。
詳細 DoHの基本的なクエリフロー DoHは、クライアントがHTTPS接続を確立し、その中でDNSクエリをHTTPリクエストとして送信し、HTTPレスポンスとしてDNS応答を受け取る仕組みです。
sequenceDiagram
participant Client
participant DoH_Resolver as DoHリゾルバ
participant Auth_DNS as 権威DNSサーバ
Client ->> DoH_Resolver: 1. TLSハンドシェイク (TCP/UDP)
DoH_Resolver -->> Client: 2. TLSハンドシェイク完了
Client ->> DoH_Resolver: 3. HTTPSリクエスト (DNSクエリ)
DoH_Resolver ->> Auth_DNS: 4. 従来のDNSクエリ (UDP/TCP)
Auth_DNS -->> DoH_Resolver: 5. 従来のDNS応答
DoH_Resolver -->> Client: 6. HTTPS応答 (DNS応答)
TLSハンドシェイク : クライアントはDoHリゾルバとの間にTLSセッションを確立します。このハンドシェイクはTCP (HTTP/2の場合) またはUDP (HTTP/3/QUICの場合) 上で行われます。
HTTPSリクエスト : TLSセッションが確立された後、クライアントはHTTP GET または POST メソッドを使用してDNSクエリをDoHリゾルバに送信します。DNSクエリは通常、Base64URLエンコードされてURIパスまたはHTTPリクエストボディに含まれます。
DNS解決 : DoHリゾルバは受け取ったDNSクエリを解析し、必要に応じて権威DNSサーバに従来のDNSプロトコル（UDP/TCP）で問い合わせを行います。
HTTPS応答 : 権威DNSサーバからの応答を受け取ったDoHリゾルバは、そのDNS応答をHTTPレスポンスとしてクライアントに返します。
HTTP/2 DATAフレーム構造 (簡略化) DoHクエリは、HTTP/2の場合、通常DATAフレームとしてペイロードを伝送します。
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| DoH Query Payload (variable) |
+---------------------------------------------------------------+
Length: データフレームのペイロード長 (バイト単位) (24ビット)
Type: フレームの種別 (DATAフレームの場合: 0x0) (8ビット)
Flags: フレーム固有のオプションフラグ (例: END_STREAMビットでストリーム終了) (8ビット)
R: 予約ビット (常に0) (1ビット)
Stream Identifier: このフレームが属するHTTP/2ストリームの識別子 (31ビット)
DoH Query Payload: Base64URLエンコードされたDNSメッセージ、またはDNSwireformat (可変長)
プライバシー考慮事項 RFC 8899は、DoHがローカルネットワーク上の監視からDNSクエリを保護する一方で、以下のプライバシーリスクを強調しています [1][2]。
集中化によるトラッキング : 少数の大規模DoHリゾルバにトラフィックが集中することで、当該リゾルバがユーザーのすべてのDNSクエリを収集し、IPアドレスやその他の情報と紐付けてユーザーの行動プロファイルを構築する可能性が高まります。
クエリのリンク付け : クライアントが特定のDoHリゾルバのみを使用する場合、そのリゾルバはクライアントのすべてのDNSクエリを関連付け、ユーザーがアクセスしたウェブサイトやオンラインサービスを正確に把握できる状態になります。
匿名性の低下 : ユーザーが匿名性を求めている場合でも、DoHリゾルバの選択によっては、そのリゾルバがユーザーの真のIPアドレスや地理的位置を把握し、潜在的に他のデータと統合するリスクがあります。
トラフィック分析 : HTTPSによって暗号化されていても、トラフィックの量、タイミング、接続パターンなどのメタデータは残ります。高度なトラフィック分析により、特定のウェブサイトへのアクセスやユーザーの活動が推測される可能性があります。
セキュリティ考慮事項 DoHは暗号化によるセキュリティ強化をもたらしますが、同時に新たなセキュリティ課題も生じさせます [1][3]。
DoS/DDoS攻撃 : DoHリゾルバは、従来のDNSサーバと比較して、TLSハンドシェイクやHTTP処理により多くの計算リソースを消費します。このため、DoS/DDoS攻撃に対して脆弱になるリスクが高まります。
設定ミス : クライアント側のDoH設定が不適切だと、意図しない信頼できないDoHリゾルバに接続したり、組織のセキュリティポリシー（フィルタリングや監視）を迂回してしまったりする可能性があります。
中央集権化と単一障害点 : 大規模なDoHリゾルバへの集中は、そのリゾルバが攻撃された場合、広範囲のユーザーにサービス停止をもたらす単一障害点となるリスクを高めます。
インネットワーク可視性の低下 : ネットワーク運用者は、DoHトラフィックが暗号化されているため、ネットワーク内のDNSクエリを監視・フィルタリングする能力が低下します。これにより、マルウェア検出やコンテンツフィルタリングなどのセキュリティ機能に影響が出る可能性があります。
リゾルバ発見とプロビジョニング : DoHリゾルバを安全に発見し、クライアントにプロビジョニングする仕組み（例：DHCP Options for DoH [RFC 9050] や Secure DNS Provisioning (SDP)）は、中間者攻撃やリゾルバのなりすましを防ぐ上で重要です [1]。
相互運用 DoHエコシステムにおける相互運用性は、クライアント、リゾルバ、およびネットワーク運用者の間で共通の理解と実装のベストプラクティスを共有することで実現されます。RFC 8899は、互換性のあるクライアントとリゾルバの実装、および運用者向けのガイダンスを提供することで、エコシステム全体の整合性を高めることを目指しています。
既存プロトコルとの比較
特徴
従来のDNS (UDP/TCP)
DoH (HTTP/2)
DoH (HTTP/3 / QUIC)
トランスポート UDP/TCPポート53
TCPポート443 (HTTP/2 over TLS)
UDPポート443 (HTTP/3 over QUIC)
暗号化 なし (DNSSECはデータ完全性保証のみ)
TLSによるエンドツーエンド暗号化
QUICによるエンドツーエンド暗号化
プライバシー ローカルネットワークで盗聴・改ざんのリスク
ローカルネットワーク監視からの保護 (リゾルバへの集中リスクあり)
ローカルネットワーク監視からの保護 (リゾルバへの集中リスクあり)
セキュリティ 中間者攻撃、キャッシュポイズニング、DDoS脆弱性
HTTPSによるなりすまし・改ざん防止 (DoS/DDoSリスクは残る)
HTTPS/QUICによるなりすまし・改ざん防止 (DoS/DDoSリスクは残る)
HOL blocking なし (UDP) またはTCPストリーム単位
あり (HTTP/2は多重化するがTCPレベルでの問題)
なし (QUICはストリーム単位で独立して処理)
接続確立 高速 (UDPはコネクションレス)
TLSハンドシェイクとTCPハンドシェイクでオーバーヘッド
QUICハンドシェイクでオーバーヘッドが少ない (0-RTT可)
レイテンシ 低レイテンシ (UDP)
やや高レイテンシ (TLS/HTTPオーバーヘッド)
低レイテンシ (0-RTT、HOL blocking回避)
ファイアウォール 専用ポートのためブロックされやすい
ウェブトラフィックと区別しにくい (ブロックされにくい)
ウェブトラフィックと区別しにくい (ブロックされにくい)
セキュリティ考慮 RFC 8899で言及されるセキュリティ考慮点に加え、プロトコルスタック固有の側面も考慮する必要があります。
リプレイ攻撃と0-RTTの再送リスク
リプレイ攻撃 : DoH自体はDNSクエリをHTTPリクエストとして扱うため、HTTP層やTLS層のプロトコルがリプレイ保護を提供します。ただし、TLS 1.3の0-RTT (Zero Round Trip Time) 機能を使用する場合、初回接続時のハンドシェイクをスキップしてデータを送信できるため、リプレイ攻撃のリスクが生じます。0-RTTで送信されるデータは、攻撃者によって捕捉され、再度送信される可能性があります。DoHの文脈では、冪等でないDNSクエリ（例：動的更新）を0-RTTで送信しないよう、クライアントやリゾルバは注意する必要があります [4]。
0-RTTデータ再送リスク : QUIC（HTTP/3の基盤）も0-RTTをサポートしますが、同様にリプレイ攻撃のリスクを持ちます。DoHリゾルバは、0-RTTデータを受け取った際に、そのデータを冪等でない操作に利用しない、またはリプレイが検知された場合に適切に処理することが求められます。
ダウングレード攻撃 ダウングレード攻撃とは、攻撃者が安全なプロトコル（DoH）から安全性の低いプロトコル（従来のDNS）への切り替えを強制しようとする攻撃です。DoHクライアントは、信頼できるDoHリゾルバが利用可能である限り、従来のDNSにフォールバックしないように設定されるべきです。特に、中間者がDoH接続をブロックし、クライアントに暗号化されていないDNSを使用させようとするシナリオが考えられます。クライアントは、DoHリゾルバの発見とプロビジョニングを安全に行い、設定されたDoHリゾルバへの接続が失敗した場合でも、安易に平文DNSに切り替えないポリシーを持つべきです [1]。
キー更新と証明書の管理 DoHはTLSに依存しているため、TLSサーバ証明書の適切な管理とキー更新はセキュリティの根幹をなします。
認証と認可 DoHリゾルバは、HTTPS接続の確立時にTLS証明書を通じて自身の身元をクライアントに証明します。クライアントは、この証明書が信頼できる認証局によって発行されたものであることを検証する必要があります。さらに、特定のクライアントやユーザーにのみDoHサービスを提供する場合は、HTTP層での認証（例：OAuth 2.0やクライアント証明書）と認可の仕組みを導入することが考えられます。
実装メモ DoHの実装と運用においては、パフォーマンスと信頼性を確保するために以下の点に留意が必要です。
MTU/Path MTU (PMTU) の考慮 : DoHはHTTP/2 (TCP) またはHTTP/3 (QUIC/UDP) 上で動作するため、基盤となるトランスポートのMTU/PMTUに注意が必要です。特にHTTP/3のQUICはUDP上で動作するため、PMTU Discovery (PMTUD) のサポートが重要になります。大きなDNS応答がフラグメント化を避けるため、適切なパケットサイズを考慮し、PMTUDが失敗した場合のフォールバックメカニズムを実装する必要があります。
HOL (Head-of-Line) blocking 回避 :
HTTP/2 : HTTP/2は複数のリクエストを単一のTCP接続上で多重化することで、HTTP/1.1のHOL blockingを緩和します。しかし、基盤となるTCP層でパケットロスが発生した場合、そのTCP接続全体がブロックされ、すべてのHTTP/2ストリームに影響が出る「TCP HOL blocking」のリスクが残ります。
HTTP/3 (QUIC) : HTTP/3はQUIC上で動作し、ストリーム単位でパケットロスからの回復を行うため、あるストリームでのパケットロスが他のストリームに影響を与えません。これにより、本質的にHOL blockingの問題を回避できます。DoHリゾルバを設計する際は、この特性を考慮し、HTTP/3を優先的にサポートすることが望ましいです。
キュー制御と優先度付け : DoHリゾルバは大量のDNSクエリを処理するため、効率的なキュー制御とリソース割り当てが必要です。
クライアント側 : 重要なアプリケーションからのDNSクエリに優先度を付け、遅延の影響を最小限に抑えることができます。
リゾルバ側 : 異なるタイプのクエリ（例：Aレコード vs. AXFR）や異なるクライアントに対して、サービス品質 (QoS) に基づくキュー制御やスケジューリングを適用することで、公平なリソース利用と安定したサービス提供を実現できます。HTTP/2およびHTTP/3の優先度付けメカニズムを適切に活用することが重要です。
リソース管理とスケーラビリティ : DoHリゾルバは、TLSハンドシェイク、HTTP処理、DNS解析など、従来のDNSサーバよりも高いリソース（CPU、メモリ）を消費します。高負荷時でも安定したサービスを提供できるよう、適切なハードウェアリソース、ロードバランシング、オートスケーリングの設計が必要です。
キャッシング戦略 : 従来のDNSと同様に、DoHリゾルバも効率的なキャッシング戦略を採用することで、権威DNSサーバへの負荷を軽減し、応答速度を向上させることができます。しかし、キャッシュポイズニング攻撃に対する防御も同時に考慮する必要があります。
まとめ RFC 8899は、DoHがDNSプロトコルのプライバシーとセキュリティを向上させる一方で、新たな課題ももたらすことを明確にしています。主要なポイントは以下の通りです。
プライバシーのトレードオフ : DoHはローカルネットワーク監視からのプライバシーを強化しますが、リゾルバへの集権化による新たなトラッキングやプロファイリングのリスクを考慮する必要があります。
セキュリティの多層性 : DoHはTLSによる暗号化を提供しますが、DoS/DDoS攻撃、不適切な設定、単一障害点のリスクに対して脆弱性が残ります。
運用の可視性 : DoHの導入はネットワーク運用者のトラフィック可視性を低下させ、従来のセキュリティ対策に影響を与える可能性があります。
プロトコル選択の重要性 : HTTP/2とHTTP/3 (QUIC) の選択は、HOL blocking回避や0-RTT利用の際のセキュリティリスクに影響を与えるため、慎重な検討が必要です。
実装と運用のベストプラクティス : MTU、キュー制御、リソース管理、安全なリゾルバ発見メカニズムなど、多岐にわたる技術的側面が安定したDoHサービスの提供には不可欠です。
DoHの採用は、これらの考慮事項を十分に理解し、適切な対策を講じることで、初めてその真価を発揮できると言えるでしょう。
参考文献 
コメント