DNSの仕組み（名前解決）
私たちは example.com のような名前でアクセスしますが、通信に使われるのはIPアドレスです。この名前をIPアドレスへ変換する仕組みがDNSで、変換処理を「名前解決」と呼びます。問い合わせはまずキャッシュDNSサーバへ送られ、必要に応じてルートから順にたどって答えを得ます。Linuxでは参照先サーバが /etc/resolv.conf に書かれています。
私たちがブラウザに打ち込むのは example.com のような覚えやすい名前ですが、実際にネットワークでデータを届けるのに使われるのはIPアドレスという数値です。人間に優しい名前と、機械に必要な番号——この2つの世界を橋渡しする仕組みがDNS（Domain Name System）で、名前からIPアドレスを求める処理を名前解決（あるいは単に「解決」）と呼びます。IPアドレスは覚えづらく、とくにIPv6ともなれば人間が暗記するのは現実的ではありません。DNSがあるおかげで、私たちは番号を意識せずに直感的な名前でサービスを利用でき、サーバ側もアドレスが変わったときに名前との対応を更新するだけで済みます。インターネットの電話帳のような存在だと考えると分かりやすいでしょう。名前解決を担当するソフトウェアやサービスはリゾルバとも呼ばれます。
ドメイン名の階層構造
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レコードがあります。このように頂点のルートから階層を順にたどって答えを得る方式（再帰的な問い合わせ）と、一度得た答えを一定時間覚えておくキャッシュの組み合わせによって、世界規模の名前解決が現実的な速さで成り立っています。覚えておく時間（キャッシュの有効期間）はレコードごとに決められており、サーバのアドレスを変更したときに、世界中のキャッシュが入れ替わるまでに少し時間がかかるのはこのためです。
/etc/resolv.conf と参照先サーバ
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 で実際に確かめる方法を扱います。