キャッシュと bailiwick — どこまでを信じてよいか
referral・glue・bailiwick を分け、どこまでを cache に入れてよいか整理する。
前章のおさらい: 第 1 章では、shared recursive resolver の cache に偽の RRset が残ると、利用者全体に同じ誤答が配られる構図を確認しました。本章では、その「resolver が何を cache に入れてよいか」を判断する基準として、referral / glue / bailiwick を整理します。
委任では「最終 answer」ではなく「次の行き先」が返る
recursive resolver は、いきなり最終答えだけを受け取るわけではありません。親ゾーンは child zone の NS を示す referral を返し、resolver はその道案内を使って次の authoritative server へ進みます。
| 場所 | よく入るもの | 考え方 |
|---|---|---|
| ANSWER | 最終 RRset | 本当に欲しい名前・型の答えか |
| AUTHORITY | NS / SOA | referral か否定応答か |
| ADDITIONAL | glue / 補助アドレス | 次へ進む足場か、無関係な追加データか |
小問 2-1 — glue は橋渡し用の足場
in-bailiwick な NS 名に対する A / AAAA が Additional にあると、resolver は child zone へ辿り着きやすくなります。
Q1. 親ゾーン example.com が shop.example.com を ns1.shop.example.com へ委任し、referral の Additional に ns1.shop.example.com A 192.0.2.53 が入っていました。この追加情報の説明として最も近いものはどれですか。
子ゾーンへ到達するための「足場」かどうかを考えます。
これは子ゾーンへ辿るための in-bailiwick glue です。委任を進める補助情報として役に立ちますが、一般の最終 answer と同じ強さで扱うわけではありません。
Q2. delegation の NS 群が dig の出力で主に現れる場所はどこですか。
referral は「最終 answer」より「次の行き先」を示します。
delegation の NS 群は dig では主に AUTHORITY セクションに現れます。ANSWER は最終 RRset、ADDITIONAL は glue や補助アドレス、QUESTION は問い合わせた名前・型・クラスが入るセクションです（dig の出力は HEADER / QUESTION / ANSWER / AUTHORITY / ADDITIONAL の 5 セクション構成です）。
bailiwick 判定の 3 つのシナリオ
Additional にあるレコードをどう扱うかは、そのレコードが referral している委任範囲の内側（in-bailiwick）か外側（out-of-bailiwick）かで変わります。
ここでの判定は概念学習用です。実装ごとに細部は違っても、「委任の足場」と「無関係な追加データ」を分けて考える視点が大切です。
out-of-bailiwick additional は慎重に扱う
referral の Additional に unrelated なデータを混ぜられると危険です。そのため resolver 実装は、どの範囲の glue をどう信じるかを厳しく扱います。この文脈でよく出てくるのが bailiwick です。
bailiwick の語源: 元々は中世英語法における「bailiff（執行官）の管轄区域」を指す法律用語で、「ある主体が責任を持つ範囲」という含意があります。DNS の文脈ではこれを転用し、「委任元のゾーンが責任を持つ名前空間の範囲内かどうか」を判断する考え方として使います。referral の Additional に現れたレコードが、その委任の範囲（bailiwick）の内側にあれば in-bailiwick、外側にあれば out-of-bailiwick と呼びます。
小問 2-2 — out-of-bailiwick additional は慎重に扱う
referral の Additional に unrelated なデータを混ぜられると危険です。bailiwick は、どの範囲の glue をどう信じるかを制限する考え方です。
Q3. example.com から ns.partner.net への referral に ns.partner.net A 198.51.100.10 が Additional で付いてきました。最も保守的な扱いはどれですか。
その追加 A は example.com の支配下かどうかを確認します。
out-of-bailiwick の追加情報は、権威データとして全面的に信じ込まず、必要ならその名前自体を別途解決するのが安全側です。bailiwick の考え方は無関係な追加データの混入を抑えるためにあります。
Q4. bailiwick という考え方の主目的として最も近いものはどれですか。
「どの範囲の紹介状なら受け取り方を厳しくするか」を考えます。
bailiwick は、referral に便乗して混ぜ込まれた無関係な追加データの受理を抑えるための考え方です。これにより resolver は glue の扱いを限定できます。
Q5. Additional の glue について正しいものはどれですか。
glue は便利ですが、役割は「橋渡し」です。
glue は delegation を辿る補助情報です。「扱いを限定する」とは具体的に、(1) in-bailiwick glue のみを委任の足場として使う、(2) out-of-bailiwick の Additional は権威データとして信じず、必要なら別途解決する、(3) Additional のレコードを利用者が問い合わせた名前の最終 answer として扱わない、という 3 点に分けて考えることを意味します。
第 2 章のまとめ
- delegation の NS は主に AUTHORITY、足場の glue は ADDITIONAL に現れる
- in-bailiwick glue と out-of-bailiwick additional は同じ強さで信じない
- bailiwick は、無関係な追加データの混入を抑えるための視点