再帰問い合わせ — どうやって答えに辿り着くか
利用者からは再帰、外向きには iterative。キャッシュあり・なしの差を手で追う。
利用者からは再帰、外向きには iterative
第 2 章では委任により親ゾーンと子ゾーンに責任が分かれる仕組みを見ました。本章では、その階層構造を実際にどう辿って最終答えに届くか、問い合わせの流れ を追います。
ブラウザやアプリは、通常 root サーバへ直接問い合わせません。利用者側から見えるのは再帰リゾルバ（recursive resolver）であり、「最終答えを返してください」 と依頼する相手です。
一方で、再帰リゾルバが外へ出るときは root → TLD → 権威サーバと iterative（イテレーティブ ＝ 反復的）に辿っていく ことが多いです。この二層を分けて考えると、recursive（再帰的）と iterative（反復的）の言葉が整理しやすくなります。
利用者からは『一度で解決してほしい』再帰要求でも、裏では referral を受け取りながら段階的に辿ります。
小問 3-1 — フルミス時の経路を手で追う
まずは cache miss の基本経路を確認します。
Q11. 再帰リゾルバのキャッシュが空のとき、www.example.com A を辿る代表的な流れとして最も近いものはどれですか。
フルミス時には、再帰リゾルバが root で .com の行き先を知り、次に .com で example.com の権威サーバ群を知り、最後に権威サーバで最終 A を得ます。
Q12. 再帰リゾルバがすでに .com の NS と example.com の NS を有効なキャッシュとして持っているが、www.example.com A 自体は持っていないとします。この最終 A を得るために追加で必要な外向き問い合わせは何回ですか。
親方向の referral はすでにキャッシュされているので、追加で必要なのは権威サーバへの 1 回だけです。
シミュレータで辿る
下のシミュレータは www.example.com A を引く例です。キャッシュヒットを切り替えると、外向き問い合わせが一気に減ることが分かります。小問では、この差を数字で数えます。
シミュレータの動作概要（テキスト版）: キャッシュが空のフルミス時、再帰リゾルバはまず root サーバへ問い合わせて .com の NS への referral を受け取ります。次に .com の TLD サーバへ問い合わせて example.com の NS への referral を得ます。最後に example.com の権威サーバへ問い合わせ、www.example.com A の最終 RRset を得ます。これで外向き問い合わせは合計 3 回。一方、再帰リゾルバが該当 RRset をすでに有効なキャッシュとして持っている場合、外向き問い合わせは 0 回 で済みます。途中段階のキャッシュ（root / TLD / 親ゾーンの NS）が一部だけ残っているときは、その分だけ問い合わせ回数が減ります。
小問 3-2 — キャッシュがあると何回減るか
同じ resolver を共有するとき、1 回目と 2 回目以降の差が非常に大きくなります。
Q13. 再帰リゾルバに有効なキャッシュが残っているとき、同じ名前・型に対して root / TLD / 権威サーバへの外向き問い合わせはどうなりますか。
有効なキャッシュがある間は、再帰リゾルバは外部サーバへ出ずに 0 回で返せることがあります。
Q16. 20 人の利用者が同じ再帰リゾルバを共有し、最初の 1 回だけフルミス、その後の 19 回は TTL の内側で同じ www.example.com A を引いたとします。root / TLD / 権威サーバへの外向き問い合わせは合計何回ですか。
フルミス 1 回分の root / TLD / 権威サーバへの問い合わせだけで済むので、合計 3 回です。
referral と authoritative answer を区別する
root や TLD は、たいてい最終 A / AAAA を返しません。代わりに「その先はこの NS 群へ行ってください」という referral を返します。これに対して権威サーバは、自分の担当ゾーンの正規データを authoritative answer として返します。
| 返答の種類 | 意味 | 見え方 |
|---|---|---|
| referral | 自分は最終答えを持たないが、次の行き先は知っている | AUTHORITY / ADDITIONAL に NS や glue が見える |
| authoritative answer | 自分の担当ゾーンの正規データを返す | 最終 RRset が ANSWER に載る |
| cached answer | 以前得たデータを TTL のあいだ再利用する | 利用者からは最終答えに見えるが、権威直送とは限らない |
また、名前が存在しない NXDOMAIN と、名前はあるが特定の型だけない NODATA 相当の状態も分けて考える必要があります。
小問 3-3 — referral と NXDOMAIN / NODATA を見分ける
トラブルシュートでは『名前がないのか、型がないのか』を分けるだけで前に進みます。
Q14. root や TLD サーバが返しやすいものとして最も適切なのはどれですか。
root や TLD は多くの場合、最終の A / AAAA ではなく、次に問い合わせるべきゾーンの NS 群を示す referral を返します。
Q15. 名前 mail.example.com 自体は存在し、MX だけあって A はないとします。このとき mail.example.com A を引いた結果に最も近い説明はどれですか。
名前が存在しても特定の型が存在しないことはあります。この場合は一般に NOERROR だが A の Answer がない、いわゆる NODATA に近い挙動になります。
この章で持ち帰ること
- 利用者は 再帰リゾルバに最終答えを依頼 する
- 再帰リゾルバは root → TLD → 権威サーバへ iterative に辿る
- キャッシュヒット時は、その長い道のりが 丸ごと省略 される