DNS変更に時間がかかる理由：TTLと反映のしくみ

「DNSの反映」が実際に意味すること

「伝播」や「反映」という言い方が誤解のほとんどを生んでいます。何かがインターネット上を広がっていくわけではありません。DNSプロバイダーでレコードを変更すると、その変更はあなたの権威ネームサーバー上で即座に有効になります。通常は数秒です。

時間がかかるのは逆の側です。世界中のリゾルバーがまだ古い応答を返し続けているのは、あなた自身がそれを許可したからです。各レコードにはTTL、つまり有効期間が付いており、一度そのレコードを取得したリゾルバーは、期限が切れるまで手元のコピーを返してよいことになっています。それより前に問い直すことはありません。必要ないとあなたが伝えたからです。

ですから正しい問いは「変更はもう反映されたか」ではなく、「どのキャッシュがまだ古い応答を持っていて、それはいつ切れるのか」です。この問いには正確な答えがあり、調べることができます。

TTLの実際の挙動

TTLは各レコードに付いた秒数です。ヒントでも希望でもなく、約束です。TTLが3600のレコードは、すべてのリゾルバーに対して「この応答は1時間有効、それより前に来るな」と伝えています。

次の3点がほぼ全員を混乱させます。

• カウントダウンはリゾルバーがキャッシュした時点から始まり、あなたが変更した時点からではありません。あるリゾルバーが50分前にTTL 3600で取得していれば、更新は10分後です。5分前に取得したリゾルバーは55分待ちます。だから変更が見える時刻が人によって大きく違うのです。
• 効いてくるのは古いTTLです。値を変えるのと同時にTTLを下げても何も短くなりません。リゾルバーは前回の問い合わせ時のTTLに従っているからです。新しい短いTTLは、次の更新から効きます。
• TTLはレコード単位で、ドメイン単位ではありません。AレコードとMXレコードの期限が数時間ずれることもあります。

古い応答を保持しているキャッシュ

訪問者とネームサーバーの間にキャッシュが1つだけ、ということはまずありません。変更が止まっているように見えるときは、どの層が原因かを知っておくと役に立ちます。

• 再帰リゾルバー——ISPのもの、あるいはCloudflareやGoogleのような公開リゾルバー。TTLが制御しているのはこのキャッシュで、「同僚には見えるのに自分には見えない」の本当の答えはたいていこれです。
• OSも小さなキャッシュを持っています。これをクリアすることが、本当に自分の手でできる唯一の操作です。
• ブラウザーはさらに別にキャッシュし、とくにChromeは短いTTLよりかなり長くレコードを保持します。別のブラウザーやプライベートウィンドウで数秒で切り分けられます。
• 自宅のルーターが転送リゾルバーとして動き、もう一段キャッシュを足していることもあります。

つまり1台のマシンからの確認ではほとんど何も分かりません。複数の公開リゾルバーに直接問い合わせて見比べてください。そのための道具がDNSクエリツールです。

実際にかかる時間

正直な答えは、大多数の人にとって以前のTTLより長くはかからない、です。どこでも繰り返される「24〜48時間」は、既定のTTLがはるかに長かった時代の話で、いまでは正しいより間違っていることの方がずっと多い数字です。

• TTL 300（5分）——ほぼ即時。頻繁に変わるレコードでよく使われます。
• TTL 3600（1時間）——非常に多い既定値。ほとんどの人は1時間以内に変更を見ます。
• TTL 86400（24時間）——一部のレジストラーでは今も既定で、「1日待て」という助言の本当の出どころです。

本当に長くかかるものが2つあります。レジストラーでのネームサーバー変更はTLD自身のレコードに関わり、そこには独自のTTL、しばしば48時間が設定されています。もう1つ、短いTTLを無視して独自の下限を課すリゾルバーがわずかに存在します。遅れ続ける少数派の正体はこれです。

無停止でレコードを変更する手順

待ち時間が問題になるのは、計画していなかったときだけです。次の順序なら、追加の一手間でほぼ完全に解消できます。

まずTTLを下げて待つ

変更の少なくとも古いTTL1周期分前に、TTLを300にします。そのうえで古いTTLが切れるまで待ちます。この手順は誰もが飛ばしますが、効くのはここだけです。古い値がまだ正しく誰も困らないうちに、待ち時間を先に使い切るわけです。

変更する

ここで値を編集します。どのリゾルバーも5分ごとに更新しているので、新しい応答はおおよそその時間で世界に行き渡ります。

自分のマシン以外で確認する

ブラウザーを再読み込みするのではなく、複数の公開リゾルバーと突き合わせます。自分のノートパソコンは、手元にある中でいちばん信用できない証人です。

TTLを戻す

変更を確認できたら、TTLを健全な値——3600以上——に戻します。すべてを300のままにしておくと、問い合わせが増え、初回の読み込みがわずかに遅くなり、ネームサーバーの調子が悪い日に守ってくれるキャッシュがなくなります。

進み具合を正しく確認する

次の3つの確認でほぼ全体像が分かります。

• リゾルバーを比べる。同じレコードをCloudflare、Google、Quad9に尋ねます。答えが違うのは、変更が進行中という意味で、壊れているのではありません。
• 応答のTTLを読む。リゾルバーは手元のコピーの残り秒数をカウントダウンで返します。この数字は、そのリゾルバーが古い応答をあと何秒返すかを文字どおり示しています。
• 実際に変えた種類を問い合わせる。古いMXレコードはAの問い合わせには現れません。

3つともDNSルックアップツールでブラウザー内で済みます。問い合わせごとにリゾルバーを切り替え、行ごとのTTLを読んでください。

MX、TXT、CNAMEでも同じですか

はい。仕組みはどのレコード種別でも同じですが、影響は異なります。触る前に知っておく価値があります。

• MXレコードは慎重に。古いMXがキャッシュに残っている間、メールは旧サーバーへ配送されます。そのメールはキューであなたを待ってくれるわけではなく、もう見ていない場所に届いてしまいます。メール移行のかなり前にTTLを下げ、TTLが完全に切れるまで旧メールボックスを使えるままにしておきましょう。
• TXTレコード——SPF、DKIM、ドメイン確認——はたいてい最も害が少ないものです。失敗した検証は後で再試行されるだけです。例外はSPFで、古いSPFレコードはその間、本物のメールを失敗として扱わせることがあります。
• CNAMEレコードは2つ目のTTLを連れてきます。リゾルバーはあなたのCNAMEと、別に参照先のレコードをキャッシュし、それぞれが独自に減っていきます。実際の待ち時間は長い方です。だからTTLの長いプロバイダーを指すCNAMEは、自分の設定より遅れることがあります。
• NSレコードは上で述べた遅いケースです。委任が一段上のTLDゾーンにあるからです。

何を変えたのであれ、推測せずその種別を問い合わせてください。古いMXはAの問い合わせでは見えず、意味を持つTTLは実際に編集した行のTTLです。

よくある失敗

• TTLを下げるのと値の変更を同時にやる。最も多い失敗で、効果はありません。
• ブラウザー1つで判断する。キャッシュ4層の奥は、確認には最悪の場所です。
• レコードを直すべき場面でネームサーバーを変える。はるかに遅く、汎用の手順書をたどって誤ってやってしまいがちです。
• 移行後もTTLを300のまま放置する。
• 24時間かかると決めつけて確認しない。TTLが1時間なら、ふつうは1時間で終わっています。

まとめ

変更は保存した瞬間に有効になっています。待っているのは他人のキャッシュの期限切れで、古いTTLがその所要時間を正確に教えてくれます。計画的な変更の前にTTLを下げ、自分のブラウザーではなく公開リゾルバーで確認し、終わったらTTLを戻す。ドメインの現在のレコードと残りTTLは無料のDNSルックアップツールで確認でき、証明書が新しいホストに届いたかはSSL証明書チェッカーで確かめられます。

関連ツールとガイド：

• DNS検索 — A、AAAA、MX、TXT、NS などの DNS レコードを値と TTL 付きで照会、さらに逆引き DNS も。
• SSL証明書チェッカー — 任意のドメインの SSL 証明書、発行者、有効期限、残り日数を確認。
• DNSルックアップ：ドメインレコードを照会する完全ガイド — DNSルックアップツールを使って任意のドメインのA、AAAA、MX、TXT、NSなどのレコードを照会する方法を学びましょう

よくある質問