DNS
DNS ・ でぃーえぬえす
ドメイン名をIPアドレスなどに変換する、階層ごとに管理を委任した世界規模の分散データベース。
✦ 30秒で試す — 航海サーバを引っ越したのに、客がまだ旧居を訪ねてくるパソコンに古い住所が返り続けるのは、最長で？予想してみる概要
DNS（Domain Name System）は、人間が覚えやすい「example.com」のようなドメイン名を、通信に実際に必要な IPアドレスへ変換する仕組みです。ブラウザに URL を打ち込んだとき、最初に走るのがこの「名前解決」で、変換が終わって初めてサーバへの接続が始まります。電話帳にたとえられますが、実体は世界中のネームサーバが階層ごとに管理を分担する、インターネット最大級の分散データベースです。
Web サービスを公開する側にとっても、DNS は必ず触れる領域です。「ドメインを取得して A レコードを設定する」「レコードの伝播を待つ」「CNAME と A レコードのどちらを使うか」といった作業の中心に DNS があります。障害対応の格言に「原因は結局 DNS だった（It’s always DNS）」という冗談があるほど、静かに、しかし決定的にすべての通信を支えています。
なぜ生まれたか
初期のインターネット（ARPANET）では、名前とアドレスの対応表は「HOSTS.TXT」という1つのテキストファイルで管理され、スタンフォード研究所（SRI）のネットワーク情報センターが一元的に配布していました。接続する組織が数十のうちはそれで回りましたが、ホストが増えるにつれ、ファイルの肥大化、更新の反映の遅れ、名前の重複、配布元への負荷の集中と、一元管理の限界があらゆる面で表に出てきます。
そこで1983年、ポール・モカペトリスが DNS を設計しました（RFC 882・883、現行の基本仕様は1987年の RFC 1034・1035）。核心のアイデアは「名前空間を階層に区切り、各階層の管理を下へ委任する」ことです。com の下の example.com のことは example.com の管理者だけが責任を持ち、ほかの誰の承認もなくレコードを更新できます。中央の台帳を捨てて権限を分散したこの設計と、答えを一定時間使い回すキャッシュの組み合わせが、その後ホスト数が億の単位に増えても破綻しなかった理由です。
詳細
名前空間の木と「委任」
ドメイン名は右から左へ階層を表します。「www.example.com」なら、頂点のルート（名前の末尾に隠れた「.」）、その下の「com」（TLD: トップレベルドメイン）、その下の「example.com」という木構造です。木は「ゾーン」という管理の単位に切り分けられ、各ゾーンには、そのゾーンの情報に最終的な責任を持つ「権威サーバ」がいます。
親のゾーンは子のゾーンの中身を持ちません。持っているのは「example.com のことは ns1.example.com に聞いてください」という委任の情報（NS レコード）だけです。この委任の鎖をたどることで、誰でもどの名前の権威サーバにもたどり着けます。
問い合わせの流れ: 再帰と反復
利用者の PC が自力でこの木をたどるわけではありません。PC の OS にある「スタブリゾルバ」は、プロバイダや社内、あるいは 8.8.8.8 のような公開サービスの「フルリゾルバ（キャッシュ DNS サーバ）」に「最終的な答えをください」と頼むだけです。これを再帰問い合わせと呼びます。頼まれたフルリゾルバは、ルートから順に「知っていれば答えを、知らなければ次に聞く相手を」と尋ねていきます。各サーバは紹介（referral）を返すだけで代わりに調べてはくれないので、こちらは反復（非再帰）問い合わせと呼びます。
フルリゾルバは、途中で受け取った紹介（com の NS、example.com の NS）もキャッシュします。このため2回目以降は、ルートや TLD を飛ばして権威サーバへ直接聞きに行けますし、答えそのものがキャッシュにあれば、どこにも聞かずに即答します。問い合わせは通常、1往復で済む軽さを活かして UDP のポート53で行われます（応答が大きい場合やゾーン転送では TCP を使います）。
下の部品で、パソコンから名前を引いてフルリゾルバのキャッシュが埋まっていく様子を確かめてください。そのあと権威サーバのレコードを書き換えると、何が起きるでしょうか。
パソコンを押して www.example.com を引いてください。フルリゾルバのキャッシュは空なので、ルート → com → example.com の権威サーバへ順に聞きに行きます（反復問い合わせ）。
キャッシュと TTL: 「伝播待ち」の正体
毎回ルートから聞いていてはルートサーバが持ちません。DNS を実用にしているのは徹底したキャッシュです。各レコードには管理者が設定する TTL（Time To Live、キャッシュしてよい秒数）が付いていて、フルリゾルバはその間、権威サーバに聞き直さず手元の答えを返します。フルリゾルバだけでなく、OS やブラウザも独自に短いキャッシュを持っています。
これが実務でいう「伝播待ち」の正体です。レコードを変更しても、何かが世界中へ伝わっていくわけではありません。世界中のフルリゾルバが古い答えを抱えている間は古い答えが返り続け、TTL が切れたところから順に新しい答えに入れ替わるだけです。したがって、サーバを移転する前には TTL をあらかじめ短く（例: 300秒）しておき、切り替え後に戻すのが定石です。ここで大事なのは「前もって」の部分です。TTL を下げる変更そのものも、古い TTL が切れるまでは世界に届かないので、移転の少なくとも「古い TTL 1回ぶん」前に下げておく必要があります。
存在しない名前も、存在しないという答え（NXDOMAIN）ごとキャッシュされます。これをネガティブキャッシュと呼び、その寿命はゾーンの SOA レコードの設定で決まります（RFC 2308）。「新しいサブドメインを作ったのに、直前に打ち間違いで引いた人には見えない」という現象は、このネガティブキャッシュが原因です。
主要なレコードタイプ
DNS は IP アドレス以外にもさまざまな情報を名前に紐付けます。A レコードは名前から IPv4 アドレスへの対応（IPv6 は AAAA）。CNAME は「この名前は別の名前の別名」という参照で、CDN や PaaS（クラウドコンピューティングのうち、アプリの実行環境まで提供する形態）のホスト名に自分のサブドメインを向けるときの常套手段です。MX はメールの受け取り先で、SMTP のサーバはこれを引いて配送先を決めます。TXT は任意のテキストで、ドメイン所有権の確認や、メールの送信元を検証する SPF・DKIM の情報置き場に使われます。NS はここまで見てきた委任の情報そのものです。なお CNAME はドメインの頂点（example.com そのもの）には置けないという制約があり、各 DNS サービスが ALIAS などの独自拡張で回避しています。
インフラとしての DNS と落とし穴
DNS は単なる変換にとどまらず、トラフィックを振り分ける道具でもあります。1つの名前に複数の A レコードを持たせて応答の順番を巡回させる素朴な負荷分散（DNS ラウンドロビン）や、問い合わせ元の地域に応じて最寄りの拠点のアドレスを返す CDN の誘導がその代表です。ただし DNS の答えは TTL の間キャッシュされるので、壊れたサーバをすぐに外すことはできません。瞬時の切り替えが必要な振り分けはロードバランサの仕事で、DNS はその入口の名前を配る役に回ります。
一方で、DNS が止まれば IP アドレスがわからず、サーバ自体が健在でもサービスには誰もたどり着けません。大手 DNS プロバイダの障害が有名サービスを軒並み巻き込んだ事例は何度もあり、DNS は可用性設計の単一障害点になりがちです。権威サーバを複数の事業者に分けて置くのはこのためです。
セキュリティ面でも DNS は長く攻撃の対象です。偽の応答をフルリゾルバのキャッシュに注入する「キャッシュポイズニング」は、2008年にダン・カミンスキーが効率的な手法を示して大問題になり、送信元ポートのランダム化と、応答に電子署名を付けて正しさを検証する DNSSEC の導入が進みました。また従来の DNS は通信が平文なので、どのサイトを見ようとしているかが経路上から丸見えです。これを防ぐため、スタブとフルリゾルバの間を HTTPS や TLS で暗号化する DoH（DNS over HTTPS）・DoT（DNS over TLS）が、主要なブラウザや OS で使えるようになっています。
試問
3台のパソコンが、フルリゾルバ（名前の問い合わせを代わりに引き受け、答えを TTL の間キャッシュするサーバ）を通して www.example.com のアドレスを引く画面です。パソコンを押すと名前を引き、「サーバを移転」で権威サーバのアドレスを新しいサーバのものに書き換えます。権威サーバの TTL（キャッシュしてよい秒数）は 3600 秒と 300 秒から選べ、時計は早送りもできます。
パソコンを押して www.example.com を引いてください。フルリゾルバのキャッシュは空なので、ルート → com → example.com の権威サーバへ順に聞きに行きます（反復問い合わせ）。