DNS — 名前からIPアドレスにたどり着くまで
ブラウザが example.com を数字の住所に変換する経路と、その途中に置かれたキャッシュがなぜ事故の原因になるのか。
この記事の進み方
What — 名前解決の道のり
example.com という文字列から 93.184.216.34 という IP アドレスを得るまで、問い合わせは複数のサーバーをたどります。まず一度、動かして全体を見てください。
ブラウザ自身は1回問い合わせるだけ。その裏でフルリゾルバが4往復している。この非対称さが「自分の環境では直っているのに、他の人は古いまま」を生む。
2回目以降は、この経路をたどりません。フルリゾルバが答えを覚えているからです。
- スタブリゾルバ
- OS やブラウザの中にいる、問い合わせを丸投げする側。自分では解決しない。
- フルサービスリゾルバ
- ルートから順にたどって答えを見つける側。ISP が提供するものや 8.8.8.8 / 1.1.1.1 がこれ。キャッシュを持つのはここ。
- 権威サーバー
- そのドメインの答えを持っている唯一のサーバー。ドメインを買ったときに指定するのはここ。
- TTL
- Time To Live。この答えを何秒間キャッシュしてよいかを、権威サーバーが指定する値。
キャッシュは1か所ではない
事故が起きるのは、キャッシュが経路上のあちこちに独立して存在するからです。
- 1ブラウザ内キャッシュタブを閉じても残る。数十秒〜数分軽い
- 2OS のキャッシュ端末単位。再起動や専用コマンドで消える軽い
- 3フルリゾルバのキャッシュTTL の秒数だけ保持。ここが本命重い
- 4権威サーバー正解を持っている場所中
dig example.com @8.8.8.8 のように権威サーバーを名指しで引けば、キャッシュを飛ばして現在の正解を確認できる。トラブル時はまずこれで「正解はどれか」を確定させる。
上から順に、先に当たったところで打ち切られる。権威サーバーを直接引いて新しい値が返っても、それは何も保証しない。
A レコードを新しい IP に変えた直後、dig example.com @8.8.8.8 で新しい IP が返りました。切り替えは完了したと言えますか?
Why — なぜ階層をたどる設計なのか
単純に考えれば、世界中のドメインと IP の対応表を1か所に置けば済みます。実際、初期のインターネットは HOSTS.TXT という1個のテキストファイルを全員が手でコピーして運用していました。ホストが数百台の時代はそれで足りたのです。
これが破綻した理由は3つあります。
更新が中央に集中する。 名前を1つ増やすたび、中央の管理者に申請する必要がありました。ホスト数が増えると、申請処理が人力のボトルネックになります。
配布が追いつかない。 全員がファイルを取りに来るため、中央サーバーの帯域が限界に達しました。
名前の衝突を避けられない。 平坦な名前空間では、誰かが取った名前は世界中の誰も使えません。
DNS はこの3つを、名前空間を木に切って、枝ごとに管理者を分けるという一手で解決しました。example.com の中身は example.com の持ち主が管理し、com の下に誰がいるかは com の管理者が管理する。上位は「下位の担当者が誰か」だけを知っていればよく、中身を知る必要がありません。これが What で見た委任です。
では、なぜキャッシュが要るのか
木構造にしただけでは、1回の名前解決に4往復かかります。ページを1枚開くたびに世界中のサーバーへ4往復していては話になりません。そこでキャッシュを入れるのですが、キャッシュにはいつ捨てるかという問題が必ずついてきます。
DNS の答えは「答えを持っている側（権威サーバー）が、有効期限を自分で決めて一緒に返す」という形を取りました。これが TTL です。キャッシュする側は、何秒使い回してよいかを自分で判断しなくてよくなります。
代わりに、権威サーバー側には答えを取り消す手段がありません。一度 TTL 86400 で配った答えは、24時間、世界中のどこかで生き続けます。取り消せないという性質が、冒頭の事故の正体です。
TTL 300 で運用しているレコードを変更しました。全利用者に行き渡るまでの最大時間は?
演習 — まず自分で判断する
解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。
この条件で、切り替え計画の TTL をどう設計しますか?
- EC サイトの本番サーバーを、来週の火曜 深夜2時に新環境へ移行する
- 現在の A レコードの TTL は 86400（24時間）
- 新旧どちらの環境も同じ本番 DB を参照する構成にはできない（DB も同時に移行する）
- 深夜2時でも注文は毎時30件ほど入っている
- 旧環境は移行後いつでも停止できる状態にある
- · TTL を下げる作業そのものにかかる浸透時間
- · 切り替え後、旧環境にアクセスが残る最大時間
- · 旧環境で注文を受けてしまった場合のデータの分岐
「DNS の変更が反映されない」と相談してきた同僚に、何が起きているかを説明してください
- 相手は TTL という言葉を聞いたことがない
- 相手の手元のブラウザでは新しいサーバーが見えている
- 利用者からは「まだ古いページが出る」と報告が来ている
読み終わりましたか?
読了にすると、これを前提とする記事がロードマップで開放されます。