DNS Checker（dnschecker.org）でレコード種別に NS を選んで検索すると、世界各地の公開リゾルバが今どの NS を返しているかを一覧で比べられます。ただし、そこに表示されるのは各リゾルバのキャッシュの状態で、ゾーンに設定した TTL の値そのものではありません。この記事では、dnschecker で NS の見え方を一括確認し、TTL は権威サーバーにコマンドで聞いて補うことで、「反映済みか」「待てばよいか」「設定が誤っているか」を見分ける手順を説明します。
dnschecker でわかること、わからないこと
dnschecker は、世界の複数の地点にある公開リゾルバへ同じ問い合わせを送り、それぞれの答えを地図や一覧で表示する Web サービスです。ネームサーバーの変更やレコードの書き換えのあと、「新しい値がどこまで行き渡ったか」を見るのに向いています。
一方で、次のことは dnschecker だけではわかりません。
- 自分の PC や社内ネットワーク、契約中のプロバイダのリゾルバが何を返すか：一覧に含まれないリゾルバの状態は別に確認が要ります。
- ゾーンに設定した TTL：表示されるのは各リゾルバの答えで、TTL が表示される場合もキャッシュの残り時間です。画面によっては TTL 自体が表示されないこともあります。
- 社内向けの DNS：公開されていない名前は外部から確認できません。
画面のボタン名や表示項目、選べるレコード種別、併設されている他のツールの内容は更新で変わることがあります。ここでの説明は執筆時点（2026年10月現在）の一般的な使い方にもとづきます。
手順1：変更の前に権威サーバーの値を控える
確認の基準になるのは、権威サーバーが返す値です。変更の前後で次のコマンドを実行し、結果を残しておきます。
# 権威サーバーの一覧を確認する
dig example.com NS +short
# 権威サーバーに再帰なしで直接聞き、設定上の TTL を確認する
dig @ns1.example.net example.com NS +norecurse
dig @ns1.example.net example.com A +norecurse権威サーバーの応答に表示される TTL は、ゾーンに設定した値そのものです（キャッシュサーバーの答えのように減っていきません）。応答のフラグに aa が付いていれば、そのサーバーが権威を持って答えています。ここで新しい値が返らない場合は、伝播を待つ段階ではなく、DNS 事業者側の設定がまだ保存・反映されていない段階です。
手順2：dnschecker で NS の見え方を一括確認する
dnschecker の検索欄にドメイン名を入力し、レコード種別に NS を選んで検索します。結果では地点ごとに、そのリゾルバが返した NS と、応答が得られたかどうかの印が表示されます。読み方の要点は次のとおりです。
- すべての地点で新しい NS がそろっている：主な公開リゾルバには行き渡っています。
- 新旧の NS が混在している：まだキャッシュが残っているリゾルバがある状態で、変更直後には普通に起こります。
- 一部の地点だけ応答が無い：そのリゾルバ側の一時的な問題のこともあります。時間をおいて再検索し、同じ地点だけ失敗し続けるかを見ます。
- どの地点も古い NS のまま長時間変わらない：レジストラでの変更が登録されていない可能性があります。手順4で親ゾーンを確認します。
NS を確認したら、同じ画面で A や MX など実際に使うレコードも続けて調べておくと、新しいネームサーバーに必要なレコードが漏れなく登録されているかの点検になります。旧ネームサーバーを見ている地点と新ネームサーバーを見ている地点で値が違う場合は、新しい側にレコードの登録漏れがないかを疑います。
手順3：TTL から待ち時間を見積もる
dnschecker の結果が混在しているとき、「いつまで待てばよいか」は TTL から見積もります。考え方は次のとおりです。
- A や MX などのレコードを書き換えた場合：変更前のレコードの TTL が、古い値が残る時間の上限の目安です。1時間（3600）なら、変更から1時間程度で各リゾルバのキャッシュは切れていきます。
- ネームサーバーを変更した場合：親ゾーン（.com や .jp など）に登録された NS の TTL と、旧ネームサーバーが返していた NS の TTL の両方が関係します。親ゾーン側の TTL は TLD ごとに決まっており、.com では2日程度と長めです。
親ゾーンの NS とその TTL は、TLD のネームサーバーに直接聞くと確認できます。
# .com のネームサーバーを調べる
dig com. NS +short
# そのうちの1台に再帰なしで聞く（AUTHORITY SECTION に委任先が出る）
dig @a.gtld-servers.net example.com NS +norecurseAUTHORITY SECTION に表示される NS が新しいものになっていれば、レジストラでの変更は登録済みです。古いままなら、レジストラの管理画面で変更が完了しているか、ネームサーバー名の綴りに誤りがないかを確認します。
なお、リゾルバによっては TTL より短い時間でキャッシュを捨てたり、障害時に期限切れのデータを返したりする動きもあるため、見積もりはあくまで目安です。
手順4：手元のコマンドで各リゾルバの残り TTL を並べる
dnschecker で全体の傾向をつかんだら、主要な公開リゾルバの残り TTL をコマンドで並べると、あとどれくらいで切り替わるかが数字で見えます。
for s in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
printf '%-16s ' "$s"
dig @"$s" example.com NS +noall +answer | awk '{printf "%s(%s) ", $5, $2}'
echo
done各行に「NS 名（残り秒数）」が並びます。古い NS を返しているリゾルバの残り秒数が、そのリゾルバで切り替わるまでの時間の目安です。同じ公開リゾルバでも、拠点ごとにキャッシュが別々のことがあるため、実行するたびに値が前後することがあります。
旧ネームサーバーはすぐに止めない
ネームサーバーを変更しても、しばらくは旧ネームサーバーを参照するリゾルバが残ります。そのあいだに旧サーバーのゾーンを削除すると、まだ旧サーバーを見ているリゾルバでは名前が解決できなくなります。dnschecker で新しい NS がそろったことを確認し、さらに親ゾーンの NS の TTL が過ぎるまでは、旧サーバーにも同じ内容のゾーンを残しておくのが安全です。
利用するときの注意
- dnschecker の結果はその瞬間のスナップショットです。判断に迷ったら時間をおいて再検索します。
- 結果を自動で大量に取得するような使い方は、サービスの利用条件に反するおそれがあります。継続的な監視が必要なら、自前のスクリプトや監視サービスを使います。
- 外部に知られたくない内部用の名前は入力しないようにします。
まとめ
- dnschecker は、各地の公開リゾルバが返す NS を一覧で比べ、変更の行き渡り具合を見るのに向いています。
- 表示されるのはキャッシュの状態です。設定上の TTL は、権威サーバーに
dig +norecurseで直接聞いて確認します。 - 新旧が混在するのは変更直後の正常な状態で、待ち時間は変更前の TTL や親ゾーンの NS の TTL から見積もります。
- 長時間古い NS のままなら、TLD のネームサーバーに聞いてレジストラでの変更が登録されたかを確かめます。
- 旧ネームサーバーのゾーンは、切り替えが行き渡るまで残しておきます。