1. 結論：名前からIPアドレスを調べる仕組み
DNSは、人が使うドメイン名と、通信先を見つけるためのIPアドレスなどの情報を対応づける仕組みです。Webサイトに接続するとき、必要に応じて名前解決を行います。
ポイント：PCは通常、ルートDNSへ直接問い合わせません。PCのスタブリゾルバが再帰リゾルバに問い合わせ、再帰リゾルバが必要に応じて各DNSサーバーへ問い合わせます。
2. 登場人物と役割
- スタブリゾルバ：端末側の名前解決機能。設定されたDNSサーバーに問い合わせる。
- 再帰リゾルバ：必要な情報を調べ、回答を返す。キャッシュが使える場合は外部への問い合わせを省略できる。
- ルートDNS：対象TLDを担当するDNSの情報へ案内する。
- TLD DNS：
.comなどの管理を通じて委任先の情報を案内する。 - 権威DNS：担当ゾーンの正式なDNSデータを保持し、問い合わせに答える。
3. 図解：名前解決をステップ送りする
INTERACTIVE / WALKTHROUGH
example.com のAレコードを問い合わせる例
端末
→再帰DNS
→参照先DNS
端末のスタブリゾルバが再帰DNSに問い合わせます。
典型的な概念モデルです。実環境ではキャッシュ、委任、CNAME、DNSSEC、ローカル設定などによってやりとりが変わります。
4. キャッシュとTTL
再帰リゾルバが回答をキャッシュしていて有効期間内なら、ルートや権威DNSへの問い合わせを省略して回答できる場合があります。TTL（Time To Live）は、そのレコードをキャッシュに保持してよい最大の時間（秒）を示す値です。
TTLが短ければ更新が比較的反映されやすくなる反面、キャッシュが切れた後の問い合わせが増える可能性があります。TTLが長ければ外部への問い合わせは減りやすい一方、変更前の情報が残る時間も長くなり得ます。
5. コマンドで確かめる
# 通常の問い合わせ
$ dig example.com A
# 指定したサーバーへ問い合わせる
$ dig @1.1.1.1 example.com A
# 委任をたどる動きを確認する（概念上は反復問い合わせ）
$ dig +trace example.com Adig +traceは通常の再帰問い合わせと同じ流れをそのまま表示するコマンドではありません。委任経路をたどるため、動作の違いを理解して使うことが重要です。
6. 理解度チェック
Q1. PCが必ずルートDNSに直接問い合わせる？
答え：いいえ。通常は設定された再帰リゾルバに問い合わせます。
Q2. 再帰リゾルバに有効なキャッシュがあるとどうなる？
答え：外部への問い合わせを省略して回答できる場合があります。
Q3. dig +traceはPCの普段の問い合わせをそのまま再現する？
答え：いいえ。委任経路をたどるための別の問い合わせ手順です。
参考資料
RFC 1034 — Domain Names: Concepts and Facilities
特定の問題集からの転載ではなく、学習目的で独自に作成した説明です。