再帰問い合わせ — 答えに辿り着くまで
利用者からは再帰、外向きには iterative。キャッシュあり・なしで問い合わせ回数がどう変わるかを手で追う。
1 つの問い合わせに、2 つの顔がある
第 2 章で、DNS の責任が委任によってゾーンごとに分かれていることを見ました。この章では、その分かれた責任の連なりを、再帰リゾルバが実際にどう辿って最終答えに届くかを追います。
まず、1 つの名前解決には 2 つの顔があることを押さえてください。
「再帰問い合わせ」と呼ばれる処理の内側は、実は反復問い合わせの積み重ねです。この二層を分けて考えると、recursive / iterative という紛らわしい用語が一度で整理できます。
利用者の「一度で解決してほしい」という依頼の裏で、再帰リゾルバは referral を受け取りながら root → TLD → 権威と段階的に辿ります。
小問 3-1 — フルミス時の経路を手で追う
まずはキャッシュが空のとき（フルミス）の基本経路です。
Q11. 再帰リゾルバのキャッシュが空のとき、www.example.com A を解決する外向き問い合わせの順序として正しいものはどれですか。
フルミス時は名前の右端から辿ります。root で「.com はあちら」、.com の TLD サーバで「example.com はあちら」と referral を 2 回受け取り、最後に example.com の権威サーバから最終答えを得ます。
Q12. 再帰リゾルバが .com の NS と example.com の NS を有効なキャッシュとして持っているが、www.example.com A 自体は持っていないとします。最終答えを得るために追加で必要な外向き問い合わせは何回ですか。
root と .com へ聞く必要はもうありません。example.com の権威サーバへの 1 回だけで済みます。キャッシュは最終答えだけでなく、途中の referral（NS 情報）にも効く — ここがポイントです。
シミュレータで辿る
下のシミュレータは www.example.com A を解決する様子を再現します。キャッシュの有無を切り替えて、外向き問い合わせの回数がどう変わるかに注目してください。続く小問では、この差を自分で数えます。
シミュレータの動作概要（テキスト版）: キャッシュが空のフルミス時、再帰リゾルバはまず root サーバへ問い合わせて .com の NS への referral を受け取ります。次に .com の TLD サーバへ問い合わせて example.com の NS への referral を得ます。最後に example.com の権威サーバへ問い合わせ、www.example.com A の最終 RRset を得ます。外向き問い合わせは合計 3 回。一方、該当レコードが有効なキャッシュにあれば外向きは 0 回です。途中段階のキャッシュ（.com や example.com の NS）だけが残っている場合は、残っている分だけ問い合わせが省略されます。
小問 3-2 — キャッシュで何回減るか
再帰リゾルバは多くの利用者に共有されます。1 回目と 2 回目以降の差を数字で確かめます。
Q13. 再帰リゾルバに有効なキャッシュが残っているとき、同じ名前・型の問い合わせに対する root / TLD / 権威サーバへの外向き問い合わせはどうなりますか。
有効なキャッシュがあるあいだ、再帰リゾルバは外部に一切問い合わせず手元の答えを返せます。外向き 0 回。世界の DNS トラフィックの大部分がこのキャッシュヒットで吸収されています。
Q16. 20 人の利用者が同じ再帰リゾルバを共有しています。最初の 1 人だけフルミスで、残る 19 回は TTL の内側で同じ www.example.com A を引きました。root / TLD / 権威サーバへの外向き問い合わせは合計何回ですか。
フルミスの 1 回分（root + TLD + 権威 = 3 回）だけです。残り 19 回は全部キャッシュヒットで外向き 0 回。共有キャッシュの効果は人数に比例して大きくなります。
返答は 3 + 1 種類に分けて読む
ここまでで、DNS の返答には「最終答え」以外のものがあると分かりました。整理すると、返答は次の 3 種類 + 否定応答に分けられます。第 1 章の合言葉「この答えは誰のどんな答えか」が、ここで具体的になります。
| 返答の種類 | 意味 | どう見えるか |
|---|---|---|
| referral | 「自分は最終答えを持たないが、次の行き先は知っている」 | AUTHORITY / ADDITIONAL に NS や glue が載る |
| authoritative answer | 担当ゾーンの正規データそのもの | ANSWER に最終 RRset が載る |
| cached answer | 以前得たデータの TTL 内での再利用 | 利用者からは最終答えに見えるが、権威から直送されたとは限らない |
| 否定応答 | 「その名前はない」または「その型のデータはない」 | NXDOMAIN、または NOERROR で ANSWER が空（NODATA） |
否定応答の 2 つは特に混同しやすいので、言葉にしておきます。NXDOMAIN は「その名前自体が存在しない」、NODATA は「名前はあるが、聞かれた型のデータがない」。たとえば MX しか持たない名前に A を聞くと NODATA になります。障害調査でこの 2 つを言い分けられるだけで、原因の絞り込みが大きく進みます。
小問 3-3 — referral と NXDOMAIN / NODATA を見分ける
「名前がないのか、型がないのか、担当が違うだけなのか」。この 3 つを分けられると、調査が一気に速くなります。
Q14. root や TLD のサーバが返すものとして最も典型的なのはどれですか。
root や TLD は膨大な配下の最終データを持ちません。持っているのは「どのゾーンをどの NS に委任したか」であり、返すのは referral です。第 2 章の zone cut が、ここで問い合わせの動きとして現れます。
Q15. mail.example.com という名前は存在し、MX はあるが A はないとします。mail.example.com A を引いた結果として最も近いものはどれですか。
「名前が存在しない（NXDOMAIN）」と「名前はあるがその型のデータがない（NODATA）」は別物です。後者はステータスこそ NOERROR ですが ANSWER が空になります。この違いは第 6 章で dig の出力として実際に確かめます。
この章で持ち帰ること
- 利用者は再帰リゾルバに最終答えを丸投げし、再帰リゾルバは外の世界をreferral を頼りに一歩ずつ辿る
- キャッシュは最終答えにも途中の referral にも効き、ヒットすれば外向き問い合わせは 0 回になる
- 返答は referral / 権威応答 / キャッシュ / 否定応答に分けて読む。NXDOMAIN と NODATA は別物
次章では「問いの型」を掘り下げます。同じ名前でも、A と MX と TXT では返るものがまったく違います。