DNSの仕組み（名前解決）
私たちは example.com のような名前でアクセスしますが、通信に使われるのはIPアドレスです。この名前をIPアドレスへ変換する仕組みがDNSで、変換処理を「名前解決」と呼びます。問い合わせはまずキャッシュDNSサーバへ送られ、必要に応じてルートから順にたどって答えを得ます。Linuxでは参照先サーバが /etc/resolv.conf に書かれています。
私たちがブラウザに打ち込むのは example.com のような覚えやすい名前だ。だが実際にネットワークでデータを届けるのに使われるのは、IPアドレスという数値である。
人間に優しい名前と、機械に必要な番号。この2つの世界を橋渡しする仕組みがDNS（Domain Name System）で、名前からIPアドレスを求める処理を名前解決（あるいは単に「解決」）と呼ぶ。
IPアドレスは覚えづらく、とくにIPv6ともなれば人間が暗記するのは現実的ではない。DNSがあるおかげで、私たちは番号を意識せずに直感的な名前でサービスを利用でき、サーバ側もアドレスが変わったときに名前との対応を更新するだけで済む。
インターネットの電話帳のような存在だと考えると分かりやすい。この名前解決を担当するソフトウェアやサービスはリゾルバとも呼ばれる。
🗂 1台のサーバが抱え込まなくて済む仕組み
世界には何億ものドメイン名がある。もし1台のサーバがそのすべてを抱えていたら、たちまちパンクするだろう。これをさばく鍵は、名前の「形」にある。
www.example.com のような文字列はFQDN（完全修飾ドメイン名）と呼ばれ、ドットで区切られた階層構造を持つ。いちばん右の com の部分をトップレベルドメイン（TLD）といい、その左の example、さらに左の www と、右から左へ階層が下りていく。
住所でいえば、右側が国や都道府県のような大きな区分、左側が番地や建物名のような細かい区分にあたる。
そしてこの階層ごとに担当するDNSサーバが分かれて存在しており、ひとつのサーバが世界中の名前をすべて抱え込むのではなく、責任を分散して管理している。だからこそ、何億とあるドメイン名を破綻なくさばける。階層の頂点にはルートDNSサーバがあり、ここを起点に下の階層へとたどっていく構造になっている。
🧭 知らない名前を突き止める旅
一度も問い合わせたことのない名前のIPアドレスは、どうやって突き止めるのか。その旅をたどってみよう。
アプリが名前で接続しようとすると、まずその要求は身近なキャッシュDNSサーバ（リゾルバ）へ送られる。このサーバが答えを知っていれば（過去に問い合わせた結果を一時的に覚えていれば）すぐに返すが、知らない場合は階層をたどって調べに行く。
具体的には、まず頂点にあるルートDNSサーバに「com を担当するサーバはどこか」を尋ね、次にcomを担当するサーバに「example.com を担当するサーバはどこか」を尋ね、最後にそのサーバへ「www.example.com のアドレスは何か」と問い合わせて、ようやくIPアドレスを得る。
こうして得た答えはしばらくキャッシュに保存され、次回以降は同じ問い合わせを高速に返せるようになる。名前とIPv4アドレスの対応はDNSのAレコードという記録に書かれており、IPv6用にはAAAAレコードがある。
このように頂点のルートから階層を順にたどって答えを得る方式（再帰的な問い合わせ）と、一度得た答えを一定時間覚えておくキャッシュの組み合わせによって、世界規模の名前解決が現実的な速さで成り立っている。
覚えておく時間（キャッシュの有効期間）はレコードごとに決められている。サーバのアドレスを変更したときに、世界中のキャッシュが入れ替わるまでに少し時間がかかるのは、このためだ。
📇 そもそも、誰に尋ねているのか
ここまで「キャッシュDNSサーバに尋ねる」と書いてきたが、自分の端末はそのサーバの居場所をどこで知るのか。
Linuxの端末が「どのDNSサーバに問い合わせるか」は、/etc/resolv.conf という設定ファイルに書かれている。このファイルの nameserver で始まる行に、参照するDNSサーバのIPアドレスが指定される。たとえば nameserver 192.168.1.1 とあれば、名前解決の問い合わせはまずこのアドレスのサーバへ送られる。
多くの環境では、このファイルはDHCPなどによって自動的に生成・更新されるため、手で編集する場面はそれほど多くない。だが名前解決がうまくいかないトラブルの調査では、まずこのファイルに正しいDNSサーバが書かれているかを確認するのが定石だ。中身が空だったり、到達できないアドレスが書かれていたりすると、名前解決そのものが成立しない。
端末のネットワーク設定で手動指定する項目（IPアドレス・サブネットマスク・デフォルトゲートウェイ）と並んで、このDNSサーバの指定も基本設定の一つである。
ここで前のトピックの知識が静かに効いてくる。DNSの問い合わせは、ふだんはUDPの53番ポートでやり取りされる。これは1回の問い合わせと応答が小さく、速さが優先されるためで、前のトピックで学んだポートとプロトコルの知識（DNS=53番、UDP=軽量・高速）がここで結びつく。
名前解決の調子を確かめるには dig コマンドが便利で、詳しくは次のトピックで扱う。dig example.com とすればANSWER欄に対応するIPアドレスが表示され、出力末尾には実際に答えてくれたDNSサーバも示される。手軽に引きたいときは nslookup example.com でも同様に名前解決ができる。
⚠ つまずいたら、まずここ
DNSを意識するのは、多くの場合「つながらない」トラブルの切り分けだ。ここに、原因を一瞬で絞り込む鮮やかな手がある。
IPアドレスを直接指定すれば通信できるのに、名前を指定すると失敗する。この状況なら、ネットワークの経路そのものは生きていて、疑うべきは名前解決、つまりDNS側だと判断できる。逆に名前でもIPアドレスでも届かないなら、経路やゲートウェイなどより下の層を疑う。
このように、名前解決という一段を切り分けの軸に据えることで、原因の所在を素早く絞り込める。
DNSは普段は意識せず使えてしまうぶん、いざ不調になると「なぜか特定のサイトだけ開けない」といった分かりにくい症状になりがちだ。その正体が名前とアドレスの変換役であることを理解しておくと、落ち着いて対処できる。
なお、名前解決は1台のサーバに頼っているわけではなく、参照先のキャッシュDNSサーバ、その先の各階層のサーバ、そして手元の /etc/resolv.conf の設定という複数の要素が連携して成り立っている。トラブル時にはこのどこが詰まっているのかを意識すると、調査の見通しが立てやすくなる。次のトピックでは、この名前解決が正しく動いているかを dig や nslookup で実際に確かめる方法に踏み込む。