要約

  • 提案中の ECS オプトインは、クライアントが公開アドレスを知らなくても、再帰リゾルバーに許すプレフィックス長を指定できる。
  • DoT、DoH、DoQ はクライアントとリゾルバーの間の改ざんを抑えるが、リゾルバーの申告を真実にしたり、権威側へ届いたビット数を証明したりはしない。

暗号化されていない経路で、攻撃者が上限を 16 から 32 に書き換える。応答側の値も 16 に戻しておけば、クライアントから見ると希望どおりである。再帰リゾルバーは 32 ビットを権威サーバーへ送り、画面上の記録だけが安全な物語を残す。

暗号化すれば、この攻撃の重要な部分は止められる。経路上の第三者は選択肢を追加したり、値を引き上げたり、応答を偽造したりしにくくなる。だが、リゾルバー自身が 32 ビットを送り、16 と報告する行為までは止まらない。

2026 年 8 月 20 日付の Client Opt-In Signaling for EDNS Client Subnet は、この証拠境界を明記している。これは個人提出の Internet-Draft であり、DNSOP ワーキンググループ採択文書でも RFC でもない。想定状態は Experimental と書かれ、オプションコードは TBD のままである。導入済みの標準として扱う根拠はない。一方で、暗号化と誠実性を混同しない設計資料としては明快である。

公開アドレスを知らないクライアント

RFC 7871 の EDNS Client Subnet は、再帰リゾルバーがクライアントのネットワークアドレスの一部を権威サーバーへ送る仕組みである。権威側はプレフィックスを使い、ネットワークに合わせた応答を返せる。利便性と引き換えに、位置やネットワークに関する情報が再帰リゾルバーの外へ広がる。

従来の ECS では、クライアントは SOURCE PREFIX-LENGTH を 0 にしてオプトアウトできる。0 ではない短い上限を指定する場合、ECS オプションは、そのビットを切り出すアドレスも要求する。NAT、CGNAT、VPN の背後にいる端末は、リゾルバーが観測する公開アドレスを知らないことがある。

新提案は、許可とアドレス指定を分離する。クライアントは 1 オクテットで許容する最大ビット数だけを示せる。リゾルバーは観測した送信元アドレスを選び、クライアント上限、併存する ECS 上限、リゾルバー自身の最大キャッシュ可能長、アドレス族上限のうち最小値を有効長とする。

データなしの形式は、オプトインではあるがクライアント上限を置かない。リゾルバーの最大値に委ねるため、厳密な最小化ではない。何も許可しないクライアントはオプションを省略するのが基本である。明示的な 0 でも転送は止まるが、暗号化されていない経路では実装の存在を知らせる。

応答が届いても実装確認にはならない

未知の EDNS オプションは無視される。未対応リゾルバーは新オプションを捨て、従来どおり応答できる。名前解決の成功は、上限の受理を証明しない。互換性のための仕様が、同時に「成功応答をコンプライアンス証明に使えない」という制約を生む。

対応リゾルバーは有効プレフィックス長を応答に入れる。0 は何も転送しないという申告、N は最大 N ビットという申告になる。オプションがない場合、未対応か、途中で削除された可能性が残る。しかも未対応リゾルバーは自身の設定で ECS を利用しているかもしれない。

したがって、クライアントが保存すべきなのは二値の「成功」ではない。送信した形式、接続先、暗号化状態、返された値、過去の能力確認を別に持つ必要がある。能力を記憶するなら、暗号化された経路で確認しなければ、偽造された一度の応答を長期信頼へ変えてしまう。

DNSSEC が署名するのは別の対象

応答中の OPT レコードは DNSSEC 署名の対象ではない。ドメイン名に対する RRset が正しく検証されても、「リゾルバーが何ビット転送したか」という申告は認証されない。DNSSEC 有効という表示を ECS 上限の保証へ拡張してはいけない。

同じく、DoT、DoH、DoQ は輸送路を守る。クライアントが意図した値が途中で変更されず、想定したリゾルバーまで届いたという証拠を強める。しかしリゾルバーの内部動作や上流送信は、その暗号化セッションの外側にある。

実際の開示を確かめるには、権威サーバー側または同等の監査点で受信した ECS を観測する必要がある。クライアントの要求、暗号化された受領、リゾルバーの申告、権威側の観測は四つの異なる記録である。一つを他の代用にすると、責任主体が消える。

同意は上流へコピーされない

提案オプションは非推移的である。再帰リゾルバーはそれを権威サーバー向けのクエリへ入れてはならず、上流クエリへ単純に複写してもならない。EDNS はホップごとの拡張であり、この指示はクライアントから直接受け取ったリゾルバーに向けられている。

フォワーディングリゾルバーは、次の再帰サービスに対しては一人のクライアントになる。自身のオプトインを送ることはできるが、元のクライアントが示した上限を超えてはならない。自ら ECS を構成するなら元クライアントのアドレスを何ビット送ったか報告する。上流にアドレス選択を任せれば、送られるのはフォワーダー自身のアドレスであり、元クライアントのビット数は 0 と報告する。

この規則は、同意を携帯可能な証明書にしない。各ホップは自分が制御する行為についてだけ判断し、受け取った上限を厳しく保つ。通常の ECS オプションだけでは元のユーザー意思を示せない。フォワーダーが追加できるからである。

キャッシュにも来歴が要る

対応リゾルバーは、ECS を使って得た応答を、シグナルを送っていないクライアントへ返してはならない。各キャッシュエントリが ECS 由来かどうかを判定できる必要がある。

来歴がなければ、別のネットワーク向けに調整された応答が、同意していない利用者へ渡る。キャッシュヒット時に新しいプレフィックス送信は起きなくても、過去の開示の成果が文脈を越える。応答パケットには調整済みであることを示す印がないため、受信者は違反を発見できない。

シグナルありとなしでキャッシュを分ける方法もあれば、エントリに来歴と適用条件を保持する方法もある。重要なのは実装形態ではなく、判断可能性である。名称、TTL、応答だけを保存して ECS 取得の事実を失えば、提案の同意モデルは実行できない。

シグナルを送るクライアントには RFC 7871 の最長プレフィックス照合が続く。現在の上限より長い SOURCE PREFIX-LENGTH のエントリでも、キャッシュから返すだけなら新たなアドレス情報を転送しないため利用できる場合がある。開示上限とキャッシュ利用資格は別の制御である。

有効上限と実際の使用量

revision 00 は、キャッシュヒットでも応答に有効上限を返す。これは「この問い合わせで最大何ビットまで許されるか」を示すが、「この応答を得るために今回何ビット送ったか」とは一致しない。キャッシュヒットなら新規送信は 0 であり得る。

草案自身が、実際に使われたビット数を報告すべきかを未解決事項として挙げる。この選択は監視の意味を変える。政策上限をイベント実績として保存すれば、正確に見える数字が誤った説明を生む。

短いプレフィックスも匿名ではない。ECS を受け取る複数の権威サーバーと、暗号化されていない上流を観測できる主体に届き得る。短さは精度を下げるだけで、主体との関連を消すわけではない。

将来コードが IANA 登録されても、同じ境界は残る。コード割当はソフトウェア間の衝突を避ける調整であり、誠実な申告、キャッシュ分離、実環境の普及を保証しない。Experimental という表記も、実験目的や成功条件が定義されなければ結果証明にはならない。

暗号化は必要な防御である。しかし、それを全体保証に膨らませないことが、より重要な運用規律になる。経路が守られたこと、リゾルバーが申告したこと、キャッシュが来歴を保ったこと、権威側で観測されたことを別々に検証して初めて、上限の意味が残る。

出典