要約

  • 送信元プレフィックス長 /0 は、再帰リゾルバにクライアントのアドレス情報を上流へ加えないよう求めるが、その選択を利用者へ提供する実装上の経路は別問題である。
  • ECS ではリゾルバが開示する送信元プレフィックスを決め、権威サーバが応答スコープを返してキャッシュを再利用できる範囲を決める。
  • プレフィックスは身元・同意・正確な地理を証明しない。RFC 7871 はプライバシーとキャッシュの負担を示し、RFC 8932 は回避、最小化、方針開示を勧告した。

/0 が止めるもの

スタブリゾルバは ECS の送信元プレフィックス長を 0 にできる。これを受けた再帰リゾルバは、後続の問い合わせへクライアントのアドレス情報を追加してはならない。ECS 自体を省くか、自分自身のアドレス情報を使うことはできる。転送リゾルバも、上流から渡された短い上限を勝手に広げることはできない。

規定は明快だが、RFC 7871 が記録した当時の実用面は明快ではなかった。利用者が設定を操作できるソフトウェアは限られていたという 2016 年時点の記述である。これは現在の採用状況を示す調査ではない。本稿の資料には、今日のアプリケーション、公開リゾルバ、事業者方針を数えるデータは含まれない。

この差はガバナンス上重要だ。プロトコルが拒否の値を持っていても、利用者がそれを送る経路を持たなければ、実際の開示方針は再帰サービス側に残る。

リゾルバが代理で作る問い合わせ

通常、トポロジーに応じて応答を変えたい権威サーバが見るのは再帰リゾルバの送信元アドレスであり、元のクライアントではない。集中型リゾルバが離れたネットワークの利用者をまとめて扱う場合、そのアドレスは利用者に適した応答を選ぶ手掛かりとして弱い。

RFC 7871 の ECS オプションは、中間リゾルバが起点ネットワークの一部を上流へ伝えられるようにした。フィールドはアドレスファミリ、送信元プレフィックス長、スコーププレフィックス長、可変長アドレスから成る。IPv4 と IPv6 のアドレスは、指定された有効ビットまで切り詰め、必要な最後のオクテットまでだけ埋める。

リゾルバはキャッシュ可能な最大長を設定し、完全なアドレスより短いプレフィックスを使うべきだとされた。問い合わせのスコープ長は 0 である。この時点で送っているのは応答範囲の主張ではなく、権威側が選択に使えるネットワークの手掛かりだ。

応答がキャッシュの境界を返す

権威サーバは応答で送信元長を問い合わせと一致させ、別にスコーププレフィックス長を返す。これは、先頭何ビットが一致するネットワークまで当該応答を使えるかを示す。短いスコープは広い再利用を、長いスコープはより限定された再利用を意味し得る。送信されたプレフィックスが選択には粗すぎたことを示す場合もある。

したがって ECS には二つの権限がある。再帰リゾルバは利用者ネットワークを何ビット開示するか決め、権威側はその結果がキャッシュでどこまで引き継がれるか決める。スコープは身元や場所の証明ではない。RFC 7871 は応答選択の方法を規定せず、ネットワーク上の近さと地理的な近さも同一視していない。

ECS 対応キャッシュは、まず名前・タイプ・クラスで探し、次にプレフィックス一致で RRset を選ぶ。ECS のない応答は通常スコープ /0、つまり全クライアント向けとして扱う。REFUSED が返れば、オプション拒否と同じコードの別用途を区別するため、ECS なしで再試行する。

共有キャッシュを分けるコスト

ネットワークごとの応答は、同じ名前・タイプ・クラスに複数のキャッシュ状態を作る。結果としてメモリが増え、再利用率が下がり、サーバ負荷が増える可能性がある。RFC 7871 は既定で無効にし、明確な便益がある場合に限り、保持するネットワーク数と応答数を制限するよう勧めた。送信するアドレスビットは、自らキャッシュできる範囲を超えてはならない。

問い合わせ識別フィールドと応答が一致しない場合に破棄する規則は、なりすましやキャッシュ汚染の経路を狭める。しかし一致したからといってクライアントのプレフィックスが認証されるわけではなく、権威側の選択品質も保証しない。

暗号化後にも残る上流方針

RFC 8932 は 2020 年、DNS プライバシーサービスの視点から ECS を扱った。クライアントとリゾルバの間を暗号化しても、リゾルバ自身は問い合わせを見て情報を上流へ送れる。同 RFC は /0 を尊重し、上流 ECS を避けるか、ECS を使わない代替サービスを提供するよう勧告する。利用するなら運用上可能な最短プレフィックスを選び、受信する上流をできれば限定し、実際の長さと方針を公表すべきだとする。

DNSSEC は別の制御である。RFC 7871 は多くの DNSSEC レコードを /0 で扱うよう勧め、RRSIG は署名対象の RRset に結び付く。検証は、リゾルバの開示判断、地理、権威側のローカリティ方針を認証しない。

歴史的な結論は限定される。ECS は、誰かの代わりにネットワーク情報を開示する判断と、その応答を他者へ再利用する範囲を、中間者の運用方針として定着させた。これは RFC の仕組みから導く編集上の分析であり、現在の導入効果を測った結論ではない。

出典