要約

  • fdbs は同じ事件に関する複数のデータベース参照を運べるが、その同一性はまずリゾルバーの主張であり、記録同士の一致や真正性を保証しない。
  • アプリはローカルなレジストリ写しで URI テンプレートを展開し、信頼する運営者だけを選ぶ。参照の送信、ページの取得、事件の証明は別の状態である。

一つの DNS エラーに二つの参照が付いていた。片方のデータベースは裁判所の命令を理由に挙げ、もう片方は通信事業者の自主方針だと記した。対象日も一致しなかった。

同じ事件を説明するはずの二つのページが、別の責任主体を示していた。

draft-ietf-dnsop-filtering-transparency-00 は、名前解決中の政策介入を単なる故障と誤認させないための参照方式を提案する。ただし、複数の参照を運べることは、複数の独立証明を得たことと同じではない。

第00版は2026年8月1日付で、2027年2月2日に失効する。DNSOPワーキンググループの活発な Standards Track Internet-Draft であり、RFCでも、稼働中の IANA レジストリでも、ブラウザ方針でも、導入実績でもない。依存する構造化 DNS エラー仕様も作業中である。

リゾルバーは参照を選ぶ

DNS Filtering Database Entry は db と id を持つ。前者は事件データベース運営者、後者は事件レコードを識別する。fdbs 配列には複数のエントリを入れられるが、すべて同じ基礎事件に関係しなければならない。

どのデータベースを列挙するかはリゾルバーが決める。したがって、配列は世界の全資料を表す索引ではない。リゾルバーが採用した情報源の集合である。

アプリごとに対応する運営者は異なる。複数を送るのは、少なくとも一つを利用できる可能性を高めるためだ。二件あれば二票、三件あれば三票という設計ではない。

同一事件という条件も、暗号学的な結合ではない。リゾルバーが関連ありと判断して同じ配列に置く。アプリがその判断を検証する仕組みは別途必要になる。

任意 URL を拒むための間接化

ネットワークが自動設定するリゾルバーは、利用者が選んだ主体とは限らない。そこから任意の URL や表示文をアプリ画面へ注入できれば、公共 Wi-Fi が偽の説明ページを作ることもできる。

草案は二つの抽象 ID に制限する。アプリは DNS Filtering Database Registry のローカル写しを保持し、運営者 ID に対応する Level 1 または Level 2 の URI テンプレートへ事件 ID を代入する。

リゾルバーが宛先全体を支配しない点は重要である。しかし間接化は事件を認証しない。既存の正しい運営者 ID と、実際に開ける事件 ID を別の名前解決へ流用できる。

ページが存在することは、当該 DNS 応答との因果関係を証明しない。参照可能性と真正性は別の評価軸である。

レジストリは薄い調整面である

提案されるレジストリにはデータベース名、連絡先、運営者 ID、解決テンプレートが入る。登録は先着順を基本とし、IANA は欺瞞的または見せかけの申請を拒める。

これは名前空間の衝突を避ける仕組みであり、認定制度ではない。記録の正確性、法的専門性、訂正手続、政治的独立性、保存方針を審査しない。

アプリはローカル写しを使い、毎回 IANA に問い合わせてはならない。中央への漏えいを抑えられる反面、テンプレート変更とクライアント更新の間に時間差が生じる。

同じ db と id でも、古い写しと新しい写しは異なる URL を作り得る。監査には、使用したレジストリ版とテンプレートのハッシュが必要である。

食い違いを一文に溶かさない

複数ページが異なる説明をした場合、アプリは出典を残して並べる、ローカル方針で一つを優先する、あるいは統合を拒むことができる。

避けるべきなのは、差異を消して「公式理由」として一文にまとめることだ。日付、命令主体、対象範囲の違いは、利用者が知るべき不確実性である。

一致も注意が必要である。同じ上流資料を複数のデータベースがコピーしていれば、独立性は増えない。件数は証拠の系譜を示さない。

透明性の画面は、誰が何を主張したかを見せるべきで、主張の数から真偽を自動計算すべきではない。

読み込みは新しいプライバシー事象になる

事件ページを取得すると、利用者の IP アドレスと、特定のフィルタ済みドメインを調べた事実がデータベース運営者へ渡り得る。地域によっては重大な危険である。

信頼する運営者を選んでも経路観測者は残る。接続先、時刻、パスや固有 ID から内容を推測できる。プライバシー保護プロキシは直接のアドレスを隠せるが、新しいログ保持者になる。

草案は、保護機構がない場合に利用者の明示操作なしで URL を自動取得してはならないとする。リンクプレビュー、脅威スキャン、先読み、メタデータ展開も自動取得に含めて扱う必要がある。

表示しただけというログでは足りない。構築、表示、操作、プロキシ選択、送信、リダイレクト、応答を分離しなければ、操作前の漏えいを見つけられない。

固有 ID は相関装置になり得る

事件 ID は要求ごとに固有でもよく、共有でもよい。リゾルバーとデータベースが協力すれば、DNS で配った固有トークンが後でどれだけ取得されたかを観測できる。

同一事業者が両方を運営する場合も同じである。説明のための参照が、DNS 意図と Web アクセスをつなぐビーコンになる。

利用者が運営者を信頼しても、ID の粒度や保存期間までは証明されない。アプリは、事件単位、名前単位、ネットワーク単位、利用者単位、照会単位のどれで発行されるかを監視する必要がある。

プロキシはトークンを消さない。相関の観測者を変えるだけかもしれない。

アプリまで届かない場合がある

ホスト環境が DNS 応答の詳細をアプリへ渡さないことがある。リゾルバーが正しく fdbs を送っても、OS が一般的な失敗へ縮約すれば表示不能である。

送信、到着、ホスト公開、解析、レジストリ認識、方針受理、提示、操作、取得は別段階である。最初の成功から最後の成功を推定してはならない。

データベースへのアクセスがない理由は、送信なしだけではない。未対応、古い写し、拒否方針、利用者の拒否、ネットワーク失敗がある。欠測をゼロとして扱うと、誤った責任追及になる。

事件ページは判決文ではない

草案自身が、参照された情報と利用者が経験した事件との結合を認証しないと述べる。攻撃者は実在するページを再利用し、存在しないフィルタリングを主張できる。

リゾルバーは関連性を主張し、レジストリは経路を提供し、データベースは記録を書く。HTTP 成功は経路の結果であって、事件の証明ではない。

画面表示も「リゾルバー報告」「登録済み運営者」「取得済み記録」「認証済み事件」を区別すべきである。最後のラベルを得る材料はこの仕組みだけでは足りない。

透明性は不確実性を隠さない

提案の価値は、一主体に表示内容を委ねない点にある。リゾルバーは限定参照、レジストリはテンプレート、アプリは信頼、利用者は取得を制御する。

全登録者を自動許可し、全ページを先読みし、複数記録を一つの説明に融合すれば、その分離は失われる。

DNS の政策介入を技術故障から区別することと、介入の法的・事実的正しさを証明することは別である。複数参照が示すべきなのは確信の量ではなく、主張の来歴と残る相違である。

出典