# DNS浸透チェック：変更が反映されるまでの待ち時間を計算 URL: https://notificationharbor.com/ja/tools/dns-shintou-check Type: tool Locale: ja Published: 2026-10-07 Updated: 2026-10-08 --- > TTLと変更からの経過時間をもとに、DNS変更の最長待ち時間を見積もります。ブラウザ内で動作し、レコード、新しいDKIMキー、ネームサーバー切り替えに対応。 ## DNS浸透チェック：変更が反映されるまでの時間を確認 TTLと変更からの経過時間を入力してください。このDNS浸透チェックは、レコード変更、新しいDKIMキー、ネームサーバー切り替えについて、残りの最長待ち時間を表示します。 ## DNS浸透チェッカー 変更の種類、適用されるTTL、保存してからの経過時間を入力してください。結果は入力に合わせて更新され、データがブラウザの外に出ることはありません。 *[Interactive widget — see the live page for the full experience]* ## このツールが計算しているもの ### 浸透とはキャッシュの期限切れです DNSは変更を押し出して配信しません。各リゾルバーは取得した回答をTTLが切れるまで保持し、その後で問い合わせ直します。最も遅いリゾルバーは、編集の直前に古い回答を取得したものなので、最悪ケースは古いTTLと同じになります。 ### 新しいレコードには独自の時計があります 存在しなかったレコードも「存在しない」という回答としてキャッシュされることがあります。その否定的回答は、SOAのTTLとSOAのminimumフィールドの小さい方の値の間保持されます。事前に誰も名前を問い合わせていなければ、新しいレコードはすぐに見えます。 ### ネームサーバーの変更はレジストリの設定に従います ネームサーバーを切り替えると、親ゾーンにあるNSレコードが変わりますが、そのTTLはユーザーが設定できません。このツールはそれを入力値として受け取り、.comのような大規模TLDで一般的な値である2日を初期値にしています。 ## 待ち時間を短くする4つのステップ 1. **現在のTTLを確認する** — レコードに対してdigを実行し、answerセクションの数値を読みます。それが変更の反映に必要な待ち時間の上限です。 2. **事前にTTLを下げておく** — TTLを300秒に設定し、レコードを編集する前に古いTTLと同じ時間以上待ちます。長く保持されたコピーを、先にリゾルバー側で期限切れにさせる必要があります。 3. **変更を保存し、時刻を記録する** — 編集を保存し、その時刻をメモして、経過時間を上の計算ツールに入力します。 4. **まず権威サーバー、次にリゾルバーで確認する** — まず権威ネームサーバーに問い合わせ、次に公開リゾルバーに問い合わせます。両方が新しい値を返し、ウィンドウが過ぎたらTTLを元に戻します。 ## Common questions ### このDNS浸透チェックは無料ですか？ はい。登録は不要で、リクエスト数の制限もありません。入力された3つの数値の計算だけを行うため、ブラウザ内で動作し、データが当社のサーバーに送信されることはありません。 ### ライブのDNSサーバーに問い合わせますか？ いいえ。世界中のリゾルバーからレコードを調べることはしません。入力されたTTLから、キャッシュされた回答が残りうる最長時間を計算します。特定のリゾルバーが今何を返すかを確認するには、そのリゾルバーに対してdigを実行し、ここに表示されたウィンドウと比べてください。 ### 新しいTTLではなく古いTTLで見積もるのはなぜですか？ リゾルバーは、編集前に取得した回答を、それに付いていたTTLと一緒にキャッシュしています。同じ編集でTTLを下げても、古い回答を既に保持しているリゾルバーには効果がありません。新しいTTLは、変更後に取得された回答にだけ適用されます。 ### ネガティブキャッシュのTTLとは何で、いつ適用されますか？ リゾルバーが存在しない名前を問い合わせると、「存在しない」という回答をキャッシュすることがあります（RFC 2308）。その期間は、SOAレコード自身のTTLとそのminimumフィールドの小さい方です。レコードを作成する前にその名前を問い合わせていたリゾルバーにだけ影響します。例えば、誰かが早すぎるタイミングでテストしたDKIMセレクターなどです。 ### ネームサーバーの変更にこれほど時間がかかるのはなぜですか？ ネームサーバーを指すNSレコードはレジストリにあり、そのTTLはユーザーが管理できません。.comのような大規模TLDでは、そのTTLは一般的に2日です。それが切れるまで、一部のリゾルバーは古いネームサーバーへの問い合わせを続けます。 ### ウィンドウを過ぎても古い値が見えます。どうすればよいですか？ キャッシュのせいにするのはやめてください。権威ネームサーバーに直接問い合わせ、新しい値を返しているか確認します。返していなければ、編集が間違ったゾーンや間違ったホスト名に入ったか、そもそも保存されていません。返しているなら、これまで使っていないリゾルバーからテストし、自分のマシンやネットワーク内のローカルキャッシュも確認してください。 ### SPF、DKIM、DMARCのレコードにも当てはまりますか？ はい。これらはTXTレコードであり、他のレコードと同様にキャッシュされます。古いSPFレコードをキャッシュした受信サーバーは、TTLが切れるまでそれを使って評価し続けるため、編集直後の送信は古いポリシーで判定される可能性があります。 ## 自社の送信を支えるインフラも確認しましょう このツールは待ち時間を見積もるものです。Notification Harborは、自分で管理する送信を支えます。ドメインのウォームアップ、トレースレベルの可観測性、そして本番送信の前に正しく設定されたSPF、DKIM、DMARCを提供します。 *Call to action: Notification Harborの仕組みを見る* ## FAQ ### このDNS浸透チェックは無料ですか？ はい。登録は不要で、リクエスト数の制限もありません。入力された3つの数値の計算だけを行うため、ブラウザ内で動作し、データが当社のサーバーに送信されることはありません。 ### ライブのDNSサーバーに問い合わせますか？ いいえ。世界中のリゾルバーからレコードを調べることはしません。入力されたTTLから、キャッシュされた回答が残りうる最長時間を計算します。特定のリゾルバーが今何を返すかを確認するには、そのリゾルバーに対してdigを実行し、ここに表示されたウィンドウと比べてください。 ### 新しいTTLではなく古いTTLで見積もるのはなぜですか？ リゾルバーは、編集前に取得した回答を、それに付いていたTTLと一緒にキャッシュしています。同じ編集でTTLを下げても、古い回答を既に保持しているリゾルバーには効果がありません。新しいTTLは、変更後に取得された回答にだけ適用されます。 ### ネガティブキャッシュのTTLとは何で、いつ適用されますか？ リゾルバーが存在しない名前を問い合わせると、「存在しない」という回答をキャッシュすることがあります（RFC 2308）。その期間は、SOAレコード自身のTTLとそのminimumフィールドの小さい方です。レコードを作成する前にその名前を問い合わせていたリゾルバーにだけ影響します。例えば、誰かが早すぎるタイミングでテストしたDKIMセレクターなどです。 ### ネームサーバーの変更にこれほど時間がかかるのはなぜですか？ ネームサーバーを指すNSレコードはレジストリにあり、そのTTLはユーザーが管理できません。.comのような大規模TLDでは、そのTTLは一般的に2日です。それが切れるまで、一部のリゾルバーは古いネームサーバーへの問い合わせを続けます。 ### ウィンドウを過ぎても古い値が見えます。どうすればよいですか？ キャッシュのせいにするのはやめてください。権威ネームサーバーに直接問い合わせ、新しい値を返しているか確認します。返していなければ、編集が間違ったゾーンや間違ったホスト名に入ったか、そもそも保存されていません。返しているなら、これまで使っていないリゾルバーからテストし、自分のマシンやネットワーク内のローカルキャッシュも確認してください。 ### SPF、DKIM、DMARCのレコードにも当てはまりますか？ はい。これらはTXTレコードであり、他のレコードと同様にキャッシュされます。古いSPFレコードをキャッシュした受信サーバーは、TTLが切れるまでそれを使って評価し続けるため、編集直後の送信は古いポリシーで判定される可能性があります。