DNS｜コンピュータネットワーク

🎓 レベル：基礎　|　重要度：A（必須） 📎 前提：UDP

要点（BLUF）

DNSは www.example.com のような名前を、通信に必要なIPアドレスへ変換する分散データベースです。
ルート→TLD（.com）→権威サーバ、と階層をたどって目的のレコードに到達します。
一度引いた結果はTTLの間キャッシュされ、毎回ルートから引かずに済みます。普段はUDP53番を使います。

なぜDNSが要るのか

人は名前で覚え、機械はIPで通信します。さらにIPは引っ越し（サーバ移転・冗長化）で変わります。名前とIPを切り離し、名前は固定のままIPだけ差し替えられるようにするのがDNSの価値です。電話帳のように「名前を引けば今の番号が分かる」仕組みです。

階層構造と名前解決の流れ

ドメインは右から左へ階層化されています（www.example.com. の末尾ドットがルート）。

graph TD
  R["ルートサーバ（.）"]
  T["TLDサーバ（.com）"]
  A["権威サーバ（example.com）"]
  C["フルサービスリゾルバ（キャッシュ）"]
  C -->|"1. .comはどこ?"| R
  C -->|"2. example.comはどこ?"| T
  C -->|"3. wwwのAレコードは?"| A

再帰問い合わせ：クライアント →リゾルバへ「最終的な答えをちょうだい」と丸投げ。
反復問い合わせ：リゾルバ →各サーバへ「次はどこに聞けばいい?」と段階的に辿る。

クライアントは普段、再帰でリゾルバに任せ、リゾルバが反復で世界を辿ります。

主なレコードタイプ

レコード	役割
A	名前 → IPv4アドレス
AAAA	名前 → IPv6アドレス
CNAME	別名 → 正規名（エイリアス）
MX	メールの配送先サーバ
NS	そのゾーンの権威サーバ
PTR	IP → 名前（逆引き）
TXT	任意テキスト（SPF・所有確認等）

キャッシュとTTL

各レコードには**TTL（生存時間）**があり、リゾルバやOSはその間答えを再利用します。TTLが長いほど問い合わせは減りますが、IP変更の反映が遅れます。サーバ移転前にTTLを短くしておくのは運用の定石です。

# Linux/Windows での名前解決の確認
nslookup www.example.com
dig www.example.com A +short

他層との関係

DNSの問い合わせは小さく1往復で済むため、コネクション確立の往復が無駄なUDPが基本（53番）。応答が大きい（512バイト超）場合やゾーン転送はTCPへフォールバックします。名前解決は通信の最初の一歩で、ここが詰まると「ネットにつながらない」体感になります（実際は到達性はあるのに名前が引けないだけ、ということも多い）。

なぜ分散・階層なのか（設計の直観）

全世界の名前を1台で管理したら、負荷・障害・管理権限のすべてが破綻します。階層化して各組織が自分のゾーンだけを管理し、キャッシュで負荷を分散すれば、地球規模でもスケールします。これはIPアドレスの階層化（集約）と同じ「分割して各自が責任を持つ」思想です。

⚠️ よくある誤解

「DNSはIPを決める/割り当てる」ではない。DNSは名前とIPの対応を引くだけ。IPの割り当てはDHCP（[[05-03_DHCP]]）の仕事です。
「pingが通らないのは経路障害」ではない。名前解決の失敗（DNS）と経路の失敗（ルーティング）は別。ping 8.8.8.8 は通るのに ping example.com が通らないなら、疑うのはDNSです。
「CNAMEはどこでも使える」ではない。ゾーン頂点（apex）やMXの宛先にCNAMEは使えない等の制約があります。

対応 lab

なし（実機/OSの nslookup・dig での観察を推奨）