search

Found

info 概要

DNSレコード変更が世界中のリゾルバへ反映される完了予定時刻と残り時間が一目でわかる。5min・1h・24h・48hのTTLプリセットとカウントダウン、進捗バー内蔵。

📘 使い方

  1. TTLプリセット(5min・1h・24h・48h)を選ぶか、カスタム欄に秒数を直接入力する
  2. DNSレコードを変更した日時を「DNS変更日時」欄に設定する
  3. 伝播完了予定時刻と残り時間のカウントダウン、進捗バーを確認する

DNS伝播TTL計算

schedule TTL(読みやすい形式)
1h 0m 0s
伝播完了予定時刻
-
カウントダウン
-
-
経過時間
-
進捗
-
Article

DNS伝播TTL計算|TTLから完了時刻を予測

DNSレコードを変更してから、その内容が世界中のリゾルバ(問い合わせを中継するDNSサーバー)へ行き渡るまでの完了予定時刻を、TTLと変更日時から割り出すツールです。5min・1h・24h・48hのTTLプリセットと、残り時間を秒単位で示すカウントダウン、進捗バーを1画面にまとめています。

💡 このツールについて

サーバーを移転したのにサイトが切り替わらない、メールの宛先が古いまま届く——DNS変更後の「いつ反映されるのか分からない」待ち時間は、運用担当者にとって地味なストレスです。原因の多くはTTL(Time To Live)の設定にあります。TTLは「このDNS情報を何秒キャッシュしてよいか」を示す値で、たとえば86400秒なら24時間、古い情報が各サーバーに残り続けます。

このツールは、変更した日時とそのレコードのTTLを入れるだけで「最も遅いケースで何時に全体へ反映されるか」と「あと何秒残っているか」を即座に表示します。やみくもにリロードして確認する代わりに、待つべき時間の上限を数値で把握できるので、切り替え作業の段取りが立てやすくなります。

🧐 よくある質問

Q. TTLを5分(300秒)に設定すれば、必ず5分で反映されますか? A. 変更後にキャッシュを取得するサーバーには5分で反映されますが、変更直前に旧情報を取得したサーバーは、そのキャッシュが切れるまで旧TTL分待ちます。本ツールはこの「最も遅いケース」を完了予定として表示します。

Q. なぜ「当日にTTLを短くする」だけでは遅いのですか? A. 切り替え当日にTTLを短くしても、その直前に旧レコードを大きなTTLでキャッシュしたサーバーは、その期間が満了するまで古い情報を返し続けるためです。事前にTTLを下げておくのが定石です。

Q. TTLを過ぎても古い情報が返るのはなぜですか? A. 一部のISP(プロバイダ)はTTLを厳密に守らず、独自の間隔でキャッシュを更新することがあります。この場合は本ツールの予定時刻より遅れる可能性があります。

Q. 計算した時刻や入力値はどこかに送信されますか? A. すべてブラウザ内で計算され、サーバーには送信されません。

📚 「伝播」という言葉の誤解

DNSの世界でよく使われる「伝播(propagation)」という言葉は、実は技術的には少し不正確です。DNSは変更を能動的に「送り出す(push)」仕組みではなく、各リゾルバがTTLの満了を待って自分から最新情報を「取りに行く(pull)」仕組みだからです。つまり情報が波のように広がるのではなく、それぞれのキャッシュが期限切れになった順に更新されていきます。

日本国内の事業者向け解説でも「浸透」「伝播」という表現が定着していますが、本質はキャッシュの寿命管理です。だからこそ、移転を計画するなら数日前にTTLを短く(例: 300秒)設定しておくと、切り替え当日の待ち時間を大幅に縮められます。