DNS 変更後の古い値が消える時刻

DNS の変更から、古い値が消える時刻を逆算する。

DNS レコードを変更した日時と TTL(秒)を入れると、古い値がキャッシュに残りうる最長の時刻を日本時間と UTC で一覧にします。TTL の上限や範囲外の値の扱いは RFC 2181 にもとづいて指摘します。入力はブラウザの中だけで処理します。

ツールを使う 入力例と結果

TTL と変更日時から、古い値が残る期限を出す

入力した内容は送信されません。貼り付けた文字や選んだファイルは、お使いのブラウザの中だけで処理します。本サイトのサーバーや第三者へ送信・保存しません(通信を禁止する設定でページを配信しています)。

結果

エラー 0 件・警告 0 件・情報 1 件

指摘(エラー・警告・情報)

  • 情報 全体 TTL は「その時間まではキャッシュに残してよい」という最大の目安で、必ず残るという意味ではありません。実際の保持は実装によって短くなることがあります(RFC 2181 8 節)。
変更した日時2026-10-28 12:00:00(水) JST / 2026-10-28 03:00:00(水) UTC

古い値が残りうる最長の時刻

古い値が残りうる最長の時刻
TTL(秒)長さ古い値が残りうる最長の時刻(日本時間)同(UTC)
36001 時間2026-10-28 13:00:00(水) JST2026-10-28 04:00:00(水) UTC

初期表示は入力例「TTL 3600 秒(1 時間)のレコードを昼に変更」の結果です。入力を変えるとその場で処理し直します。判定の根拠は仕様と根拠にまとめています。

ご利用にあたって

  • 結果は仕様上の最長の目安で、実際に古い値が消える時刻を保証するものではありません。
  • 本番の切り替えでは、複数の場所から実際の応答を確かめてから旧環境を止めてください。

使い方

  1. 変更前のレコードに設定されていた TTL(秒)を調べます。DNS 事業者の管理画面や dig の結果で確認できます。
  2. 「TTL」の欄に秒数を、「レコードを変更した日時」の欄に変更を反映した日時を書きます。
  3. 表で、各 TTL について古い値がキャッシュに残りうる最長の時刻(日本時間と UTC)を確かめます。
  4. メールサーバーの切り替えなどで、その時刻より後に作業の完了や旧環境の停止を予定します。

入力例と結果

代表的な入力・境界の入力・壊れた入力の例です。例ごとに入力・出力・指摘と、その結果になる理由(検算)を載せています。

入力例と結果の一覧
入力例結果
TTL 3600 秒(1 時間)のレコードを昼に変更エラー 0 件・警告 0 件・情報 1 件
5 分と 1 日の TTL を日付をまたいで比べるエラー 0 件・警告 0 件・情報 1 件
TTL 0(キャッシュしない)に設定した場合エラー 0 件・警告 0 件・情報 2 件
上限を超えた TTL(2147483648)の扱いエラー 0 件・警告 1 件・情報 1 件
単位つき(1h)で書いた壊れた入力エラー 1 件・警告 0 件・情報 0 件

このツールでできないこと(制約)

よくある質問

切り替えの前に TTL を下げておくのはなぜですか?

切り替え時点で古い値が残る期間は、変更前に設定していた TTL で決まります。事前に TTL を短くして、その古い TTL が過ぎるまで待ってから切り替えると、残る期間を短くできます。

TTL の単位つき(1h や 5m)は使えますか?

このツールは秒数の整数だけを読みます。ゾーンファイルの一部の実装は 1h のような単位つきの書き方を受け付けますが、RFC 2181 が定めるのは秒数です。1h は 3600、5m は 300 と書き直してください。

貼り付けた値はどこかに送られますか?

送られません。処理はお使いのブラウザの中だけで行い、ページは通信を禁止する設定(CSP の connect-src)で配信しています。社内で使っている名前や設定を含む値でも、そのまま試せます。