要約

  • EDNS(0)のオプション12は、暗号化DNSメッセージへ可変長の余白を加える。標準化されるのは格納形式であって、プライバシー効果ではない。問い合わせ128オクテット、応答468オクテットという単位はRFC 8467の実験的な方針である。
  • 効果は共同制作物だ。クライアントが問い合わせを埋め、サーバーが応答方針を決め、TLS・HTTP・QUICが外側の形を作り、経路が負荷と断片化を制約する。時刻、端点、問答回数は残る。

「Padding有効」と表示する二つのDoTサービスを考える。一方は問い合わせを128、応答を468の倍数に丸める。もう一方は常に16バイトだけ足す。どちらもRFC 7830に従ったメッセージを出せるが、後者では元のサイズ差がそのまま残る。既知の16を引けば輪郭を戻せる。

暗号化はクライアントとサーバーの間の内容を守る。暗号文の長さは通常、経路から観測できる。名前、RR種別、応答集合の組み合わせによっては、問い合わせと応答のサイズ対が特徴になる。既知の平文サンプルを持つ観測者は、名前を復号せず照合を試せる。

RFC 7830の仕組みは意図的に小さい。EDNSのOPT疑似RRにオプションコード12を置く。1メッセージに一度だけ現れ、長さ欄は追加オクテット数を示す。ゼロ長も有効だが、オプション見出し自体は4オクテットを使う。送信側は通常ゼロを入れ、受信側は別の値も受理しなければならない。余白にDNSの意味はない。

仕様は量を決めない。共通構文と現場の判断を分離したからだ。RFC 8467は後に複数の方策を比べ、問い合わせを最寄りの128倍、応答を468倍にそろえるブロック方式を実験的に推奨した。多くの元サイズを少数の見える箱へ集める。

箱は無情報ではない。単位が公開なら、256オクテットの問い合わせから元の範囲と下限を推定できる。送信時刻、間隔、方向、問答数も変わらない。暗号化とPaddingを併用してもDNSらしさが残る場合がある。カバートラフィックや遅延の揺らぎは別の信号を狙う別の仕組みだ。

クライアントの要求は無制限の命令でもない。Padding付き問い合わせを受けた応答側は、許容UDPサイズを超えない限り応答も埋める。PaddingがなくてもEDNS対応が示されていれば追加できるが、EDNS未対応の相手には送れない。与えられるのは容量内の狭い許可であり、有効なブロック長まで指定する権限ではない。

経路はプライバシー方針を配送問題に変える。Paddingは他のEDNSオプションの後に適用し、残りを使う。TCPの2オクテット長フィールドは計算から外す。これを含めると、UDPからTCPへ移っただけで別の箱になり、元の長さを示す手掛かりになる。MTU近くの大きな単位はUDP断片化を増やし、MTUを超えれば必ず断片化する。RFC 7830は平文DNSでの使用を禁じ、増幅への悪影響も警告する。

DoHとDoQでは権限の場所が変わる。DoHは認証済みHTTPS内でEDNS Paddingを使えるが、HTTPヘッダー、Cookie、接続再利用、時刻が別の相関を生む。DoQはDNSメッセージを埋めるほか、QUIC APIが対応すれば、ACKやフロー制御を含むQUICパケット全体を少数のサイズにそろえられる。

結果を一者が所有することはできない。クライアントは問い合わせとresolverを、サーバーは応答を、transport libraryは外側の形を、network pathは到達可能なサイズを支配する。IANAの登録は共通語彙の証拠であり、実装、設定、効果の証拠ではない。

running codeの試験はチェックボックスではなく分布である。前後のサイズ、各箱に入った元サイズの数、Padding要求に対する応答、増加バイト、断片化、損失、retry、fallbackを測る。そこで初めて、飾りではなくanonymity setが広がったと言える。