メインコンテンツまでスキップ

DNS — 委任で成り立つ分散システム

DNS は「ドメイン名を IP アドレスに変える仕組み」と説明されます。それは正しいのですが、なぜ世界中のドメイン名を 1 台のサーバーが持たずに済んでいるのかまで理解すると、設定変更が反映されるタイミングやトラブルの切り分け方まで見通せるようになります。

鍵は委任です。

この章で学ぶこと​

  • 名前解決がどのサーバーをどの順で辿るか
  • ゾーンと委任の仕組みと、サブドメインを誰が決められるか
  • TTL がキャッシュをどう制御するか
  • いわゆる「浸透」が実際には何を指しているか
前提知識

TCP/IP の IP アドレスの話を前提にします。

DNS が返すもの​

DNS はドメイン名に紐づく情報を引くための仕組みです。最も使われるのが IP アドレスの取得ですが、返すのはそれだけではありません。

レコード種別返すもの
AIPv4 アドレス
AAAAIPv6 アドレス
CNAME別のドメイン名 (別名)
MXメールの配送先サーバー
NSそのゾーンを管理するネームサーバー
TXT任意の文字列 (所有権の証明、SPF など)

**DNS が扱うのは名前と、それに紐づくレコードだけです。**端末が通信を始めるにはサブネットマスクのようなネットワーク設定も要りますが、これを配るのは DHCP の役割です。RFC 2132 はサブネットマスクを option code 1、使用する DNS サーバーのアドレスを option code 6 として、どちらも DHCP のオプションに定めています。DNS の隣に並んで見えるのはこのためで、担当している仕事は別です。

名前解決の流れ​

www.example.com を引くとき、4 種類のサーバーが関わります。

サーバー役割
フルサービスリゾルバ利用者に代わって順に問い合わせて回る。ISP や 8.8.8.8 などが担う
ルートサーバーTLD をどこに聞けばよいかを知っている
TLD サーバー.com などの下にあるドメインの権威サーバーを知っている
権威サーバーそのゾーンの実際のレコードを持っている

要点は ルートサーバーが www.example.com の IP を知っているわけではないことです。ルートが知っているのは「.com の担当はここ」だけ。.com が知っているのは「example.com の担当はここ」だけ。それぞれが 1 段下への案内だけを持っています。

ゾーンと委任​

DNS が分散システムとして成立しているのは、この「1 段下への案内」の連鎖があるためです。

RFC 1034 は、権威ある情報がゾーンという単位に分けられ、ネームサーバーへ分散されると定めています。分散にした理由も明記されています。データベースの規模と更新の頻度からして分散管理せざるをえず、全体の一貫したコピーを集めようとする方式はますます高価で困難になる、というものです。

**すべてのゾーンがルートサーバーで管理されているわけではありません。**ルートが持つのは TLD への委任情報だけで、example.com のレコードはその組織の権威サーバーにあります。

サブドメインは自由に作れる​

ゾーンを委任された組織は、その配下を自分の裁量で扱えます。RFC 1034 は、組織が自分のゾーンを制御下に置いたあとの権限をこう記述しています。一方的にゾーン内のデータを変更し、新しい枝を伸ばし、既存のノードを削除し、配下に新しいサブゾーンを委任できる。

つまり example.com を管理している人は、blog.example.com も api.example.com も staging.api.example.com も、**誰の許可も得ずに自分で設定できます。**上位に申請する必要はありません。実際の操作は AWS 実践ガイド — Route 53 と ACM にホストゾーンの作り方があります。ACM が発行する証明書そのものの仕組みは TLS と証明書 で扱います。

これは委任という仕組みの本質です。上位は「この範囲はあなたに任せた」と宣言するだけで、中身には関与しません。だからこそ、世界中のドメインを中央で管理せずに運用できます。

さらに配下を別の組織へ再委任する道もあります。dept.example.com 以下を部署のネームサーバーへ委任する、といった入れ子の構造が作れます。

TTL とキャッシュ​

同じ問い合わせのたびに毎回ルートから辿っていたら、ルートサーバーが持ちません。そこでキャッシュが入ります。

RFC 1034 は TTL を「あるリソースレコードをキャッシュに保持してよい時間の上限」と定義し、その値はデータの出所であるゾーンの管理者が決めるとしています。TTL は「何時まで」ではなく「受け取ってから何秒か」という期間なので、機器ごとの時計のずれに影響されません (日時とタイムゾーン)。

www.example.com.    300    IN    A    203.0.113.5
                    ^^^ TTL (秒)

この例なら、リゾルバはこの回答を 300 秒間キャッシュし、その間の問い合わせには権威サーバーへ聞かずに答えます。300 秒を過ぎたら破棄して、次の問い合わせで改めて取りに行きます。

キャッシュはリゾルバだけでなく、OS やブラウザにも存在します。

キャッシュから返された回答には「権威ある回答ではない」という印が付きます。値そのものは正しくても、出所が権威サーバーではないことが区別できるようになっています。

いわゆる「浸透」の正体​

DNS の設定を変えたあと「浸透に時間がかかる」と言われることがあります。この表現は、何が起きているかを正しく表していません。

実際に起きているのはこうです。

  1. 権威サーバーのレコードを書き換える。これは即座に完了します
  2. しかし各地のリゾルバは、古い値をまだ TTL の期限までキャッシュしている
  3. 期限が切れたリゾルバから順に、新しい値を取りに来る
  4. すべてのリゾルバのキャッシュが切れると、全員が新しい値を見る

つまり「新しい情報が世界中へ広がっていく」のではなく、**「古い情報が期限切れで消えていく」**のです。方向が逆です。

この違いは対処法に直結します。

誤った理解起きること
「広がるのを待つしかない」実際は TTL を事前に短くしておけば待ち時間を制御できた
「ルートサーバーに聞けば最新が分かる」ルートは example.com のレコードを持っていない。聞いても分からない

設定変更が予定されているなら、変更の TTL 分以上前に TTL を短くしておくのが定石です。たとえば通常 86400 秒 (1 日) で運用しているなら、変更の 1 日以上前に 300 秒へ下げます。すると変更時点で出回っているキャッシュはすべて 300 秒で切れるので、切り替えが 5 分で行き渡ります。切り替え後に元の値へ戻します。

なお、確認したいときに見るのは権威サーバーです。ルートサーバーには目的のレコードがありません。

# 権威サーバーを調べる
dig NS example.com

# その権威サーバーへ直接聞く (キャッシュを経由しない)
dig @ns1.example.com www.example.com A

よくある誤解​

「DNS と DHCP はどちらもネットワークの設定を配る仕組み」 — 別物です。DNS は名前を引く仕組み、DHCP は端末へネットワーク設定を配る仕組みです。DHCP の配布項目に DNS サーバーのアドレスが含まれるので混ざりやすくなります。

「すべてのゾーンがルートサーバーで管理されている」 — ルートが持つのは TLD への委任情報だけです。実際のレコードは各組織の権威サーバーにあります。これが DNS が分散システムである理由です。

「サブドメインを作るには上位への申請が要る」 — 要りません。ゾーンを委任された管理者は、その配下を自分の裁量で設定できます。

「切り替わったか調べるには、ルートサーバーに聞けばよい」 — ルートには目的のレコードがありません。聞くべきなのは権威サーバーです。そもそも起きているのは「浸透」ではなく「古いキャッシュの期限切れ待ち」です。

「DNS の変更は反映に必ず 24 時間から 72 時間かかる」 — かかる時間は TTL で決まります。TTL を 300 秒にしてあれば 5 分です。固定の待ち時間があるわけではありません。

確認問題​

問 1. 3 日後にサーバーを移行し、A レコードを新しい IP へ切り替えます。ダウンタイムを最小にするための準備は何ですか。

答え: 今すぐ TTL を短くしておきます。

現在の TTL が 86400 秒 (1 日) だとすると、切り替えの瞬間に世界中のリゾルバは最大 1 日ぶん古い値を保持しています。切り替えても、1 日は旧サーバーへのアクセスが続きます。

手順は次のとおりです。

  1. 今すぐ TTL を 300 秒へ下げる — この変更自体も旧 TTL の期限まで待つ必要があるので、切り替えの「旧 TTL 以上前」に行います。今回は 3 日前なので 1 日以上前という条件を満たします
  2. 切り替え当日、A レコードを新しい IP に変える — 出回っているキャッシュはすべて 300 秒で切れるので、5 分で行き渡ります
  3. 切り替えが完了したら TTL を元に戻す — 短い TTL は問い合わせ回数を増やすので、平常時は長めにします

移行の前後で旧サーバーも動かしておくと、キャッシュが切れるまでの間もアクセスを受けられます。

問 2. blog.example.com を新設したいです。.com の管理者や ICANN への申請は必要ですか。

答え: 必要ありません。

example.com のゾーンを管理している時点で、その配下の名前空間は自分の裁量下にあります。RFC 1034 の言葉では、自分のゾーンを制御下に置いた組織は一方的にゾーン内のデータを変更し、新しい枝を伸ばせます。

自分の権威サーバーに blog.example.com の A レコードを追加するだけで完了です。上位の .com サーバーは example.com の権威サーバーがどこかを知っているだけで、その中身には関与しません。

申請が要るのは example.com そのものを取得するとき (レジストラ経由) だけです。

問 3. A レコードを変更したのに、自分の PC からは古い IP に繋がります。同僚の PC では新しい IP に繋がります。何が起きていますか。

答え: 自分の側のどこかに古い値がキャッシュされています。

キャッシュはブラウザ・OS・リゾルバの 3 段階にあります。同僚が新しい値を見ているなら権威サーバーは正しく更新されているので、原因は自分側のキャッシュです。

切り分けの順序は次のとおりです。

# 1. 権威サーバーに直接聞く。ここが新しければ設定は正しい
dig @ns1.example.com www.example.com A

# 2. 普段使っているリゾルバに聞く。古ければリゾルバのキャッシュ
dig www.example.com A

# 3. OS のキャッシュをクリアする (macOS の例)
sudo dscacheutil -flushcache

ブラウザも独自のキャッシュを持つので、シークレットウィンドウや別ブラウザでの確認も有効です。

「浸透待ち」という説明でここを飛ばすと、実際には自分の PC のキャッシュを消すだけで済む問題を何時間も待つことになります。どの段のキャッシュが古いのかを 1 つずつ確かめてください。

まとめ​

  • DNS はドメイン名に紐づくレコードを引く仕組みです。端末のネットワーク設定を配る DHCP とは役割が違います
  • 名前解決はリゾルバ → ルート → TLD → 権威サーバーの順に辿ります。各段は 1 段下への案内だけを持ちます
  • **すべてのゾーンがルートで管理されているわけではありません。**これが分散システムである理由です
  • **ゾーンを委任された管理者は、配下のサブドメインを自由に設定できます。**上位への申請は不要です
  • TTL はキャッシュの保持時間の上限で、ゾーンの管理者が決めます
  • いわゆる「浸透」は古いキャッシュが期限切れで消えていく現象です。新しい情報が広がるのではありません
  • 変更の反映を速めたいなら、事前に TTL を下げておきます。確認先はルートではなく権威サーバーです
関連リファレンス

次に読む​

  • HTTP — 解決した宛先と実際に何をやり取りするか