DNS プライバシー：DoH、DoT、DoQ および ODoH

クライアントが DNS を HTTPS に変更しても、ローカルネットワークはクエリ名を直接読み取ることができませんが、再帰解決サーバーは誰が何をクエリしているかを知っています。ODoH はさらに、クライアントの送信元とクエリ内容を異なる役割に分割します。これらのプロトコルを比較する際に最も有用な質問は、「どの観察者に対して何を非表示にするか」であり、次にポート番号や往復時間（RTT）がきます。

信頼の境界を最初に描く

DoT、DoH、DoQ は主に、クライアントから選択したサーバーまでの伝送を保護します。サーバーは暗号化を終了し、DNS メッセージを読み取って処理する必要があります。これにより、送信元、名前、時刻、結果を記録し続けることができます。ブラウザ、ローカルのマルウェア、または企業管理コンポーネントも、暗号化の前にクエリを閲覧する可能性があります。

再帰サーバーから権威サーバーへのクエリは別のリンクであり、その可視性と暗号化ポリシーは独立しています。ネットワーク観察者は、宛先 IP、接続タイムスタンプ、トラフィックサイズを可視でき、後続のウェブサイト接続と組み合わせて行動を推測する可能性があります。暗号化 DNS は直接の露出を減らしますが、すべてのアクセスメタデータを隠すわけではありません。RFC 9076: DNS プライバシーに関する考慮事項

DNSSEC は DNS データの認証を行います。TLS 接続が特定の解決者を正しく認証しても、その解決者が提供するデータが DNSSEC 検証済みであることを意味するものではありません。DNSSEC Secure レスポンスも、クエリ名を自動的に非表示にするものではありません。

DoT: DNS/TCP フレミングを保持し、TLS を追加

DoT はデフォルトで TCP 853 接続を使用し、TLS を確立した後、2バイトのビッグエンディアン長と DNS メッセージを送信します。長さはプレフィックス自体を含みません。複数のクエリは接続を共有し、パイプライン処理できます。レスポンスはクエリの順序どおり返されるとは限らず、クライアントは ID とコンテキストに基づいてマッチングを行います。RFC 7858: DoT

TLS のバージョン、接続の再利用、リジュームはハンドシェイクのコストに影響します。ECH は DoT の組み込み必須オプションではなく、TLS と基盤となる TCP の接続確立コストをすべて消し去るものでもありません。専用ポートはサービスタイプの識別に便利ですが、実際の許可と到達性はネットワークポリシーによって決定されます。

サーバーアドレスと認証名は異なる概念です。ある IP に接続した後でも、信頼できる設定に基づいて期待されるサービスIDを検証する必要があります。Strict Privacy 設定と Opportunistic モデルは、認証と失敗処理が異なります。ハンドシェイクの失敗時に平文にフォールバックすると、プライバシーの目標も変化します。RFC 8310: DNS プライバシーの使用における構成

DoH: HTTP の成功と DNS の成功を別々に判断

RFC 8484 のバイナリ形式は application/dns-message です。POST は DNS ワイヤーメッセージをリクエストボディに直接配置します。GET は dns パラメータを使用し、値はパディングを除く Base64url エンコードです。これは IDNA ワイヤーフォーマットではなく、DNS/TCP の2バイト長さプレフィックスを追加する必要もありません。RFC 8484: DoH

例えば、33 バイトの DNS クエリは Base64url エンコードで44文字になります。POST の DNS ボディは引き続き33バイトであり、HTTP/TLS/QUIC のオーバーヘッドは別途計算されます。JSON クエリ API は特定サービスによって別途定義されたインターフェースであり、application/dns-json を標準的な DoH クライアントがサポートしなければならないネゴシエーション結果と見なすことはできません。

DoH クライアントは通常、DNS ID をゼロに設定して HTTP キャッシュの親和性を高め、関連付けは HTTP 交換によって提供されます。これは、UDP 上でランダム ID のみに依存する使用状況とは異なります。HTTP キャッシュは DNS TTL と調整する必要があります。キャッシュレスポンスの Age が 20 秒の場合、元の TTL=60 秒を「今から再び完全な 60 秒」として扱うことはできません。

DoH は HTTP/2 または HTTP/3 を使用できます。HTTP/2 のストリーム多重化は依然として TCP の順序付きバイト配信を共有します。HTTP/3 は QUIC を使用しますが、HTTP/3 上の DoH と独立した DoQ は異なるアプリケーションマッピングであり、ALPN、メッセージ形式、ポートの使用は混同できません。

DoH とウェブサイトの HTTPS が同じ一般的なポートを使用しても、完全に区別できないわけではありません。サーバーアドレス、TLS 情報、トラフィックパターン、または管理された端末ポリシーによって、対応するサービスを識別・制限できる可能性があります。GET パラメータは TLS ネットワークパス上で平文の URL として表示されませんが、HTTPS を終了するサーバーやログシステムはそれを記録する可能性があります。

DoQ: 各交換で1つのクライアント双方向ストリーム

DoQ は ALPN doq をネゴシエーションし、通常 UDP 853 を使用します。クライアントは各 DNS クエリに対して1つの双方向ストリームを開き、送信方向に2バイトの長さ、DNS メッセージを書き込み、その方向を終了します。サーバーは同じストリーム上で、長さ付きのレスポンスを逆方向に返し、終了します。DNS ID はゼロでなければならず、クエリのマッチングはストリームに依存します。RFC 9250: DoQ

クライアント双方向ストリームの ID は 0、4、8、12... です。下位2ビットは同じであり、番号が4増えることで発信元と方向タイプは変化しません。QUIC ストリーム自体はバイトストリームであり、FIN/オフセットが存在しても、DoQ 仕様が長さプレフィックスを不要にするわけではありません。受信側は依然として分割読み取りとメッセージ長さの検証を処理する必要があります。

クエリ A のストリームにギャップがある場合、クエリ B の完全なレスポンスは別のストリームで配信できますが、これらは依然として接続の輻輳制御とリソースを共有します。1つのパケットに2つのストリームのデータが含まれている場合、損失は両方のストリームに影響し、すべての待機を無条件に消除することはできません。

0-RTT は、利用可能なリジュームステータスが必要であり、拒否される可能性があります。これは最初の DoQ クエリでデフォルトのゼロハンドシェイクを意味するものではありません。特定の種類のリクエストを early data に許可するかどうか、および拒否された後の処理は、DoQ とアプリケーションセマンティクスに従う必要があり、プロトコル名をリプレイ攻撃からの安全性の証明として扱うことはできません。

ODoH: プロキシは送信元を、ターゲットは内容を見る

クライアントはまずターゲットの ODoH 公開鍵設定を取得し、HPKE を使用して DNS クエリを保護してから、HTTPS を介してプロキシに送信し、プロキシがターゲットに転送します。ターゲットはクエリを復号して処理し、レスポンスは対応するキーコンテキストで保護された状態でプロキシ経由で返されます。RFC 9230: ODoH

この分離を維持するには、クライアントのアドレスをターゲットに直接通知する追加メタデータを付与してはいけません。クライアントはターゲットの設定を信頼できる方法で取得し、キーローテーションを処理する必要があります。クエリ内容自体が識別可能な名前を含んでいる場合、または攻撃者が両側のトラフィックタイムスタンプを観察できる場合、依然としてユーザーを関連付ける可能性があります。

ODoH はグローバル匿名性を保証するものではなく、単なる「HTTPS の追加レイヤー」でもありません。内側のメッセージ保護により、プロキシは外側の TLS を終了してもクエリを直接読み取ることができません。追加のプロキシジャンプ、ターゲット処理、接続の再利用、および設定取得がコストを決定し、すべてのデプロイメントに対して2 RTT と固定することはできません。

2つの観察記録を組み合わせるとどうなるか？

これはプロトコル機能の比較表ではなく、信頼仮定に対する操作です。片側の記録のみを使用する場合、結合情報は1列不足しています。両側が協力すると、共通イベントによって2つの列が接続されます。実際の関連付けには明示的なラベルが必要とは限らず、タイムスタンプやメッセージ特徴が手がかりを提供する可能性があります。

遅延比較: コールド接続とホット接続を分離

クライアントからサーバーまでの RTT=30 ms、サービスが回答をキャッシュしており、パケット損失がなく、処理およびサーバーアドレスの解決時間を無視すると仮定します。利用可能な暗号化接続が既に存在する場合、1回のクエリ/レスポンスには約1 RTT、つまり 30 ms かかり、プロトコルが以前に何ステップのハンドシェイクを使用していたかには関係ありません。

コールド TCP + TLS 1.3 の簡略化された順序予算は、TCP 1 RTT、TLS 1 RTT、クエリ/レスポンス 1 RTT で、合計約 90 ms です。コールド QUIC の一般的なハンドシェイク後のクエリ予算は約2 RTT、つまり 60 ms となります。実装の送信タイミング、回復、Retry、および証明書伝送は結果を変更しますが、これらはプロトコル保証値ではありません。

ODoH の外側接続が既に存在する場合、クライアントからプロキシまでの RTT=20 ms、プロキシからターゲットまでの RTT=30 ms とします。リクエストの直列転送と往復が対称である簡略化モデルでは、通信部分は約 50 ms となり、処理と再帰クエリが加算されます。これは、「別の地理的場所のサーバーへの直接接続 RTT=80 ms」のパスと、プロトコル名だけで比較することはできません。

キャッシュミスによるアップストリームの反復、テールパケット損失、および接続のアイドル回収は、ヘッダーバイトの差よりも重要であることがよくあります。再現不可能な速度ランキングを1つだけ列挙するのではなく、コールドスタート、ホットキャッシュ、アップストリームミス、および失敗回復を別々に統計する必要があります。

誘導と失敗戦略もプライバシーの一部

https://dns.example/dns-query を使用する前に、サーバーIPを知る必要があり、この名前を検証する必要があります。アドレスは、プリセット、既存の誘導解決、または対応する発見メカニズムによって取得できます。「アドレスがない暗号化解決者のみに依存して自分自身を解決する」ことを要求し、起動ソリューションを提供しないことはできません。

ブラウザが独立した DoH を使用する場合でも、システムリゾルバーは別のパスをたどる可能性があります。VPN、ルーティングDNS、検索ドメイン、およびローカルサービス発見は、実際のクエリに影響を与えます。検証は、アプリケーションが実際に使用する解決パスに沿って観察する必要があり、DoH 接続が1つ見えるだけで、マシン全体に平文クエリがないと宣言することはできません。

これらは構成可能な製品動作であり、DoH/DoT/DoQ の名前からは推論できません。採用すべきは実際のニーズに基づいて構成および検証し、インフラストラクチャの章でデプロイメントと観察について引き続き解説します。

ローカルエンコーディングの対照

import base64
import struct
qname = bytes.fromhex('03777777076578616d706c6503636f6d00')
query = struct.pack('!6H',0,0x0100,1,0,0,0)+qname+struct.pack('!HH',1,1)
assert len(query)==33
# DoH POST ボディには DNS/TCP の2バイトプレフィックスがない。
post_body = query
get_value = base64.urlsafe_b64encode(query).rstrip(b'=')
assert len(get_value)==44
assert base64.urlsafe_b64decode(get_value+b'='*((-len(get_value))%4))==query
# DoT/DoQ の単一メッセージフレミングはすべてこのプレフィックスを保持する。
framed = struct.pack('!H',len(query))+query
assert len(framed)==35 and int.from_bytes(framed[:2],'big')==33
assert framed[2:]==post_body
assert [index<<2 for index in range(4)]==[0,4,8,12]
assert max(0,60-20)==40
assert 3*30==90 and 2*30==60 and 20+30==50
print('DoH エンコーディング、DoT/DoQ プレフィックス、双方向ストリーム番号、キャッシュ Age、および遅延予算が通過')

これはメッセージマッピングと明確な仮定に基づく予算チェックであり、実際の DNS サービスへの接続、HPKE 暗号化/復号の実行、またはシステムプライバシー設定の変更は行いません。

参照

• DNS プロトコルと解決：DNS ワイヤーメッセージとキャッシュ。
• DNSSEC と DNS セキュリティ：データ認証と AD の信頼境界。
• DNS インフラストラクチャ：構成の役割、誘導、ルーティング、および障害特定。
• UDP と QUIC：ストリーム、ハンドシェイク、およびパケット保護。