DNSとCDN — URLを打ってから画面が出るまで

アドレスバーにEnterを押してから画面が出るまでの1秒足らずの間に、名前解決の旅とキャッシュ階層とエッジ配信が順番に走っています。DNSが木構造をどう辿るか、TTLが何を約束していないか、CDNが距離という物理をどう誤魔化すかを、前提知識ゼロから積み上げます。

打ち込んだ名前は、宛先ではない

アドレスバーに example.com と打ってEnterを押すと、1秒足らずで画面が出ます。この短い間に、ブラウザは3つの仕事を順番に片づけています。相手の居場所を突き止める、その相手と会話を始める、中身を受け取る。世間で「サイトが重い」と言われる現象のほとんどは、この3つのどれかで待たされている状態です。

まず居場所の話から始めます。example.com は人間が覚えるための名前であって、通信の宛先ではありません。パケットを実際に届けるには 203.0.113.10 のようなIPアドレス（数字で書いた住所）が必要です。名前と住所を対応づける仕組み、それがDNS（Domain Name System）です。

素朴に考えれば「全部の対応表を1つのファイルに書いて全員に配ればいい」となります。実際、インターネットの初期はそうしていました。しかし名前は毎日増え、住所は引っ越しで変わります。世界中の全端末に最新版を配り続けるのは不可能でした。表を1か所に持たず、持ち主を分散させたまま、必要なときだけ聞きに行く。この転換がDNSの出発点です。

名前は右から読む — 委任という設計

www.example.com を右から読んでみてください。実は末尾に見えないドットがあり、正しくは www.example.com. です。

• 一番右の . はルート。「.comのことは誰が知っているか」だけを知っている
• com はTLD（トップレベルドメイン）。「example.comのことは誰が知っているか」だけを知っている
• example の持ち主が権威サーバー。www が実際どのIPかを知っている

重要なのは、どの段も答えを知らなくていいという点です。上位は「自分は知らないが、この人に聞け」という紹介状だけを返します。この紹介状がNSレコードであり、この受け渡しを委任（delegation）と呼びます。誰も全体像を持っていないのに全体が引ける、というのがこの木構造の狙いです。ルートの役割を担うサーバーのアドレスは13個（a〜m）に定められており、その実体は世界中に多数複製されています。

名前解決の旅 — 誰が誰に聞くのか

登場人物は3人です。

1. スタブリゾルバ — あなたのPCやスマホのOSに入っている、丸投げ専門の窓口
2. フルサービスリゾルバ（再帰リゾルバ） — ISPが用意したものや 8.8.8.8 / 1.1.1.1 のような公開サービス
3. 権威サーバー — その名前の答えを実際に持っている当事者

スタブが投げる質問はひとつだけです。「www.example.com のアドレスを、調べて持ってきてくれ」。丸投げなので再帰問い合わせと呼びます。

汗をかくのはフルサービスリゾルバの側です。ルートに聞き、返ってきた紹介状を頼りに.comのサーバーに聞き、また紹介状をもらって権威サーバーに聞く。1段ずつ自分の足で降りていくので、こちらは反復問い合わせと呼ばれます。質問はUDPというごく軽い方式で飛び、答えが1パケットに収まらない場合だけTCPに切り替えて聞き直します。

つまり最悪の場合、あなたの1回のアクセスの裏で3往復以上のやりとりが走ります。もしこれを全アクセスで毎回やっていたら、世界中のリクエストがルートと.comに殺到して、インターネットは初日で止まっていたはずです。止まらなかったのは、同じ質問を二度しない仕組みが最初から組み込まれていたからです。

答えにはTTL（Time To Live）という有効期限が付いてきます。「この答えはこの秒数だけ使い回してよい」という発行元からの申告です。この一行が、インターネットの運用をどれだけ支配しているかを次に見ていきます。

キャッシュは階層になっている

TTLの効き目は1か所ではありません。同じ答えが少なくとも4つの層に転がります。

• ブラウザの中 — 独自の方針で短時間保持する。開発者を最初に混乱させる層
• OSのスタブリゾルバ — 端末単位の保持
• フルサービスリゾルバ — ここが本丸。何万人分もの質問をここで吸収する
• 権威サーバー — キャッシュではなく原本

ここで効いてくるのが層の重なりです。あるISPのリゾルバが一度答えを持てば、そのISPの利用者全員がその答えを共有します。上に行くほど守られる構造になっているわけです。

見落とされがちなのがネガティブキャッシュです。「そんな名前は存在しない」という答え（NXDOMAIN）もキャッシュされます。保持時間はSOAレコードで指定された値です。だからレコード名を打ち間違えて公開し、慌てて直しても、間違いを踏んだ人の側ではしばらく「存在しない」が返り続けます。直したのに直らないという現象の典型的な正体がこれです。

そしてもうひとつ。TTLは強制力のある約束ではありません。多くのリゾルバは極端に短いTTLに下限を設けたり、上限で頭打ちにしたりします。TTLは「希望的な申告」であって、切れた瞬間に世界中が一斉に更新するわけではない、と考えておくのが安全です。