要約

  • 認証された暗号化DNSセッションが立証するのは、クライアントからリゾルバーまでの通信路の性質であり、復号後のデータ取扱いではない。
  • RFC 8932のRPSは運用者の主張を比較しやすくするが、通信、処理、保存とアクセス、外部送信には、それぞれ期限と範囲を持つ証拠が要る。

出張先のホテルで、端末が選択済みのDNSサービスへ暗号化接続を張る。ホテルのネットワークからは問い合わせ名が簡単には読めず、途中の攻撃者も応答へ介入しにくくなる。端末は相手のサービスを認証できる。この改善は大きい。

ところが、再帰リゾルバーに届いた問い合わせは処理のために復号される。リゾルバーはキャッシュを調べ、必要ならDNSSECを検証し、さらに権威サーバーへ質問する。運用者は原理上、問い合わせと通信識別子を見ることができる。何を記録し、いつ消し、誰に見せ、別のセッションと結び、どの応答を変え、上流へ何を渡すかも決められる。

通信路の鍵は、その判断の証人ではない。

RFC 8932「DNSプライバシーサービス運用者への勧告」は、この境界を曖昧にしない。2020年10月にBCP 232として公開され、著者はSara Dickinson、Benno Overeinder、Roland van Rijswijk-Deij、Allison Mankinの4人である。IETF DatatrackerのDickinsonのページにはRFCが8件掲載され、RFC 8932とDNS over QUICを定めるRFC 9250も含まれる。Privacy Enhancements and Assessments Research Groupの議長であることも記録されている。RIPE LabsはSinodun ITの共同創業者として紹介する。ここから言えるのは継続的な共同作業への参加であり、暗号化DNSを一人で発明したということでも、個々のサービスを支配しているということでもない。

RFC 8932は運用上の勧告とともに、Recursive operator Privacy Statement（RPS）という公開様式を示す。すべての運用者に同一方針を課すのではなく、約束と現行実務を近い順序で説明させ、読者が測定可能な性質と申告された性質を見分けられるようにする。RPSは法律助言でも、自動的な認証票でもない。

プライバシーの証拠は、まず四つに分ける必要がある。

第一はクライアントからリゾルバーまでの通信記録だ。接続先、認証名、方式、証明書の検証結果、TLSまたはQUICの版、パディング、稼働状況、失敗時のフォールバックを残す。RFC 8310はDNS over TLSの利用プロファイルを扱い、RFC 8484はDNS over HTTPS、RFC 9250は専用QUIC接続上のDNSを定める。どれもこの区間を保護する。復号後の問い合わせを保存しないことまでは規定しない。

DNSSECの証明も別物である。RFC 8932は、暗号化通信とDNSSECが異なる問題を解く独立した仕組みだと明記する。端末自身が検証しない場合、認証済みの暗号化接続があっても、リゾルバーがDNSSEC検証を実行したとは証明できない。端末はリゾルバーのADビットを信じているだけかもしれない。TLS証明書が示すのは通信相手であり、返されたDNSデータの検証履歴ではない。

第二はリゾルバー内部の処理記録だ。どの検証モードが動いたか。キャッシュから答えたか。脅威対策、例外、ブロックリストが応答を変えたか。IPアドレス、セッション再開、HTTPヘッダー、TLSの特徴、問い合わせパターンを用いて複数の接続を結び付けたか。RFC 9076は、入口で暗号化されたDNS通信でも、リゾルバーから平文で出る問い合わせとの時間的な相関が可能な場合があると指摘する。

同じ暗号化リゾルバーをどのネットワークでも使えば、誰に問い合わせを見せるかは分かりやすい。一方で、その運用者がネットワークを移動する同一利用者を追いやすくなることもある。途中の観察者を減らすことと、到着点での相関を減らすことは両立すべきだが、同じ制御ではない。

応答のフィルタリングも処理記録に含める。RFC 8932は、ネットワーク安全、拘束力のある法的命令、自主的な法務リスク管理、商業上の理由、その他の理由による変更をRPSで説明するよう求める。リストの作成方法や外部の供給元も対象だ。暗号化された通信路から、加工された応答が返ることはあり得る。「セキュアDNS」という一語だけでは二つの判断を区別できない。

第三は保存とアクセスの記録である。RFC 8932は保存を最小化し、可能なら避けることを勧める。残す必要がある場合は暗号化し、可能な範囲で集約、仮名化、匿名化を用いる。ログ期間はサービス維持と適用される規制上の必要に限り、閲覧できる人も職務上必要な範囲へ絞る。

「7日で削除する」という方針は約束の証拠であって、削除実行の証拠ではない。ライフサイクル処理の結果が特定の削除を示す。権限表は誰が閲覧できるべきかを示し、アクセスログは誰が実際に開いたかを示す。保存領域の暗号化は外部コピーが存在しないことを証明しない。仮名化も匿名化と同義ではない。安定した代替IDは長期間の行動を結び付け、対応表や方式が分かれば元へ戻せる場合がある。

第四はリゾルバーから外へ出る情報の記録だ。RFC 8932はQNAME最小化を勧め、各段階へ必要な名前部分だけを送る。RFC 9156はその手順を更新した。EDNS Client Subnet（ECS）は使わないか、必要なら運用可能な最短プレフィックスにし、実際の方針を公開することも求める。

外部観測は、ある時刻にある名前が最小化され、ECSが付かなかったことを確認できる。その限定性こそ大切だ。同じ結果が全ドメイン、全フォワーダー、全例外で成立するとは限らない。保存済みログの後日の共有は外から見えない。最初の区間を完全に暗号化しても、次の区間で余分な情報を渡す余地は残る。

RPSの項目が細かいのはそのためだ。IPアドレスを個人データとして扱うか。何を収集、保存、共有、販売、貸与するか。例外は何か。関連組織や資金源はどこか。他の個人情報と相関するか。どのように応答を変えるか。実務編では、現在の接続方式と認証、上流側の機能、一時的・恒久的な方針逸脱、問い合わせ窓口、処理情報を示す。

優れたRPSは証拠への索引になる。「QNAMEを最小化する」という文は設定と独立測定につながる。保存期間はライフサイクル設定と削除結果へ、アクセス制限は役割と監査イベントへ、第三者提供は受領者、目的、項目、条件、終了日へつながる。透明性報告や第三者監査も、対象期間と範囲を明示すれば索引を強くできる。

ただし索引は実行そのものではない。監査には期間と標本があり、測定には観測地点があり、報告には作成者の閲覧範囲がある。RPSが実設定より古いこともある。だからプライバシーが検証不能なのではない。主張ごとに適切な証人を選び、どこから先は言えないかを記録すべきなのである。

Dickinsonらの枠組みが残したものは、新しい鍵の絵柄ではない。問い合わせ到着後の運用判断を、外部から問い直せる言葉にしたことだ。評価は「経路が暗号化されているか」で終わらない。「到着後に誰が何を決め、その判断を何が裏付け、証拠はいつ期限切れになるか」まで続く。

出典