はじめに
Webサービスにアクセスする時、ドメイン名（例: www.example.com）を指定します。
コンピュータは DNS（Domain Name System） でドメイン名をIPアドレスに変換する(名前解決)ことでwebサービスにアクセスができます。
この記事では、DNSの名前解決 について現実の社員のやりとりのアナグラムでみてみようと思います。
なんとなくのイメージです。厳密なものではないです
登場人物（社員と部署）
| 役割 | 社内での例 | 略称 |
|---|---|---|
| クライアント | A支店の社員 a | 社員a |
| リゾルバDNS | A支店の事務部 | 事務部A |
| ルートDNS | 全国事務部 | 全国事務 |
| TLD DNS | Bの所属する地方の事務部 | 地方事務 |
| 権威DNS | B支店窓口 | 事務部B |
| IPアドレス | 社員bの連絡先 |
名前解決の流れ
各段階において、すでに知って（キャッシュ）いれば、とばすことが可能
社員aは事務部Aに問い合わせ
- 「社員bの連絡先を知っていますか？」と確認
- なければ、上位部署へ問い合わせ
- (キャッシュがあればここで終了)
事務部Aは全国事務に問い合わせ
- 「社員bはどの地方に所属していますか？」と確認
- 地方事務（TLD DNS）を案内してもらう
事務部Aは地方事務に問い合わせ
- 「社員bはどの支店にいますか？」と確認
- 事務部B（権威DNS）を紹介してもらう
事務部Aは事務部Bに問い合わせ
- 事務部Bから社員bの連絡先を取得
社員aに連絡先を返す
- 事務部Aが社員aに社員bの連絡先を伝える
- 社員aは社員bに直接連絡できるようになる
かいてみてもらったけど、ぐちゃぐちゃになってしまって、いっそ無い方がいい図
ポイントまとめ
- 過去にやりとり（キャッシュ）があればすぐ解決
- わからないときは「大きな窓口 → 担当窓口」と範囲を狭めていく
- ルートやTLDは社員b本人を知っているわけではなく、「次にどこへ聞けばいいか」を案内する役割
さいごに
アナロジーを通して、なんとなく流れがわかった気がします。