ネームサーバー確認ツール

ネームサーバーの変更が反映されたか確認する手順

このページ上で完結する 3 ステップです。ブラウザから HTTPS で公開情報(DNS とレジストリの RDAP)を読むだけなので、管理画面の認証情報は不要で、インストールも登録もありません。

1. ドメインを入力します。 ドメイン名・ホスト名・URL のいずれかを入力して「確認」を押します。レジストリ自身の登録内容を RDAP で読み、並行して dns.google と cloudflare-dns に NS・SOA・A・AAAA・MX・TXT を問い合わせます。レジストリのいまの答えと、独立した 2 つのキャッシュが並びます。
2. 最初に委任の行を読みます。 状態は 3 つのいずれかです。NOERROR + ネームサーバーなら委任は生きていてキャッシュ待ち。NXDOMAIN なら上位ゾーンに委任がなく、待っても状況は変わりません。SERVFAIL なら委任はあるものの、その先のサーバーがゾーンを応答していません。
3. 次にレジストリとリゾルバを見比べます。 レジストリに新しいネームサーバーがすでに登録されているのに、リゾルバが古い値を返しているなら、そのリゾルバがキャッシュを持っているだけです。これが「浸透待ち」の実体で、放っておけば終わります。レジストリ自体が古い組み合わせのままなら、変更はレジストリに届いておらず、待っても直りません。.jp のように RDAP を公開していない TLD では 2 系統のリゾルバを見比べ、レジストリ側は JPRS WHOIS で確かめます。

答えは 2 種類ではなく 3 種類です

この話題の説明はたいてい「動いている」か「まだ浸透中」の 2 択になっています。この切り分けが間違っているせいで、放っておいても絶対に直らない状態を 3 日間待ってしまう人が出ます。NOERROR + NS レコードあり = 委任は生きていて、キャッシュの期限切れを待っている状態。NXDOMAIN = 上位ゾーンにそのドメインの委任がない。SERVFAIL = 委任はあるが権威サーバーが答えていない。

「ネームサーバー 確認」で上位に出るページの多くは、事業者のヘルプで管理画面の見方を説明しています。ただ、ネームサーバーの値は 3 か所にあります。管理画面に保存した値、レジストリに登録されている値、リゾルバがキャッシュしている値です。「反映されない」はそのどこかがずれている状態で、ずれている場所が、待つか動くかを決めます。ツールは SOA も読みます。健全なゾーンは自分の SOA を返し、委任のないドメインは NXDOMAIN と一緒に上位ゾーンの SOA を返します。ブラウザではどちらも「開かないページ」ですが、まったく別の問題です。

「DNS 浸透」の正体は、キャッシュの期限切れです

日本語圏では長らく「浸透」という言い方そのものが議論の的になってきましたが、その指摘は技術的に正しいものです。何かがサーバーからサーバーへ伝播しているわけではありません。変更がレジストリに登録されれば、新しい委任はそのまま上位ゾーンに載ります。時間がかかるのは、古い答えをキャッシュしてしまったリゾルバが、その TTL が切れるまで古い答えを返し続けるからです。だから上限は「24〜48 時間」という慣用句ではなく、古いレコードの TTL と、上位ゾーンが委任の NS に付けている TTL で決まります。後者は jp. で 86400 秒(24 時間)、com. で 172800 秒(48 時間)です(2026 年 9 月 26 日、権威サーバーで実測)。ツールはどの応答にも、そのコピーの残り TTL を付けます。2 系統で値が違えば、それが「浸透中」の実体です。

出力の先頭に出るレジストリの行は、多くの TLD でこれを推測なしに決着させます。RDAP(gTLD で WHOIS の後を継いだ登録情報の照会プロトコル)はレジストリがいま登録しているネームサーバーを HTTPS で返し、RFC 7480 は公開情報をブラウザから読めるようにすることを勧めています。レジストリに新しいネームサーバーがすでに登録されていれば、待っているのはキャッシュだけ。古いままなら、変更はまだ届いていません。.com・.net(Verisign)、.org、.app・.dev、.ai・.info などはこの形で答えるので、お名前.com・ムームードメイン・Xserverドメインで取得した .com や .net でもレジストリの行が出ます。.jp は次の節で扱います。

.jp の場合:RDAP はなく、JPRS WHOIS と JP DNS で確かめる

.jp のレジストリは JPRS(日本レジストリサービス)ですが、JPRS は .jp の RDAP を公開しておらず、IANA の RDAP 一覧にも .jp はありません(2026 年 9 月 26 日確認)。JPRS の RDAP は、JPRS がレジストラとして取り次ぐ .com・.tokyo など 20 種類の gTLD 等のためのものです。そのため .jp や .co.jp では、このページはレジストリの行を出せず、2 系統のリゾルバだけで判定します。代わりに見る場所は 2 つです。

一つめは JPRS WHOIS。Web の whois.jprs.jp か、whois -h whois.jprs.jp example.jp(末尾に /e で英語表示)。JPRS 自身の手順書も、登録したネームサーバーは WHOIS で照合するよう案内しています。

二つめは JP DNS そのもの。dig +norecurse NS example.jp @a.dns.jp はキャッシュを通さず .jp の権威サーバーに聞くので、JPRS がいま公開している委任がそのまま返ります(co.jp なども同じ)。付いてくる TTL は 86400 秒で、ここから古い委任を受け取ったリゾルバは、最長でこの時間それを使い続けます。

待ち時間の組み立ても .jp 固有です。JPRS は 2006 年 4 月から、指定事業者経由の申請を処理してから 15 分程度をめどに JP DNS を更新しています(それまでは 1 日 1 回)。JPRS の JPDirect も反映は 15 分程度で、JPRS WHOIS にも順次反映され、午前 3 時〜5 時は原則として JP DNS を更新しないと書いています。2026 年 9 月 26 日には jp. の SOA シリアル(UNIX 時刻として読める値)が 09:15:02 → 09:30:03 → 09:45:02 → 10:00:03 UTC と 15 分刻みで進んでいました。待つのは「処理後 15 分程度」と「古い委任のキャッシュが最長 24 時間」の二段で、JPRS も、DNS サーバーの変更は申請直後から 24 時間以内に新しい設定でつながると説明しています。お名前.com の最大 72 時間程度、ムームードメインの数時間〜72 時間、エックスサーバーの数時間〜最大 24 時間程度は、TLD を区別しない目安です。JPRS WHOIS が新しい値なら待つだけ。古いままなら変更は JPRS に届いていないので、確認先は管理画面の事業者です(.jp の申請はすべて指定事業者経由)。

ネームサーバー変更のあとに実際に壊れるもの

8 つでほぼ網羅できます。上の委任の状態でどの系統かが分かり、ここで何を見に行くかが決まります。

1. 管理画面では保存できているのに、レジストリまで届いていない。公開 DNS には古い値が残り、レジストリの行も古いネームサーバーのまま(.jp では 2 系統とも古い値で一致し、JPRS WHOIS も古いまま)。待つのではなく、事業者に問い合わせる案件です。
2. 移行先にゾーンを作らないまま委任だけ切り替えた。指定されたサーバーはそのドメインを知らないので、2 系統とも SERVFAIL。先にゾーン、後で委任——ムームードメインのヘルプもムームーDNS のセットアップを先に済ませるよう案内し、JPRS の技術解説も、動いていない DNS サーバーを登録すると lame delegation になると注意しています。
3. DNSSEC を有効にしたまま移行した。上位に残った DS が移行前の鍵を指し、検証するリゾルバは新しい側の答えを拒否します。全体的に SERVFAIL なのに、新しいネームサーバーに直接聞くと正常に答えます。レジストリの行(.jp なら [Signing Key] / s. [署名鍵])に DS があればほぼ確定です。レジストラで DS を削除し(お名前.com Navi なら「DSレコード設定」)、TTL を待ってから新しい側で有効化し直します。
4. レコードを移していない。委任も正常、ゾーンも生きているのに、実際にアクセスされるホスト名の A / AAAA がない。「変更はうまくいったのにサイトが表示されない」の最頻出パターンです。
5. MX と SPF・DKIM・DMARC を忘れている。メールはサイトより静かに、遅れて壊れます。送信側が数日リトライするためです。アドレスの行だけでなく MX と TXT の行も見てください。
6. 単に古くて長い TTL の中にいる。何も壊れていません。上の残り TTL がそのままカウントダウンです。
7. 移行のあいだにドメインが期限切れになった、あるいは TLD ゾーンから外れた。見え方は NXDOMAIN と上位ゾーンの SOA、レジストリの行では client hold・server hold・redemption period などの状態。.jp なら JPRS WHOIS の [状態] で、JPRS も Web やメールが急に使えなくなったら WHOIS で状態を確かめるよう案内しています。更新・回復・事業者への連絡が必要で、待っても何も起きません。
8. ロックが更新を拒否した。client update prohibited はレジストリにドメインの更新を拒否させる指定(JPRS の表記では「登録情報変更禁止」)で、server update prohibited はそのレジストリ側版です。古いネームサーバーの横にどちらかがあれば、まずロックを疑います。client はレジストラで、server はレジストリを通してしか外せません。.jp では JPRS の「レジストリロックサービス」が同種の仕組みで、設定中はネームサーバー設定を含む登録情報の変更申請の受付が制限されます。

ネガティブキャッシュ:直したのに NXDOMAIN が返り続ける理由

いちばん厄介なのは、直したのに何も起きないパターンです。委任を直した後も、ネガティブキャッシュの TTL(SOA の minimum)のあいだは NXDOMAIN が返り続けることがあります。リゾルバは「この名前は存在しない」という事実もキャッシュします。RFC 2308 はその寿命を SOA の minimum フィールドと SOA レコード自身の TTL の小さい方と定めており、ツールはこれを 1 つの数字で表示します。jp. と com. はどちらも 900 秒(2026 年 9 月 26 日実測)、ルートは丸 1 日です。

これは自社のドメインで実際に経験しました。2026 年 6 月、4 つの .app ドメインがレジストリ側の委任を失い、約 4 日間にわたって世界中で NXDOMAIN を返しました。レジストラが委任を書き戻したのは 6 月 30 日 17:30 UTC ですが、その晩の時点でも多くの利用者からは復旧して見えませんでした。障害中に問い合わせたリゾルバが、まだネガティブキャッシュの窓の中にいたからです。その間ずっと、Cloudflare のゾーンは active、レジストラの状態欄は verified と表示していました。正しかったのは、2 系統から読んだ公開の権威 DNS だけです。4 層のドメイン健全性チェックがベンダーの状態欄ではなくレジストリ層から始まるのは、この経験があるからです。

実務上は、NXDOMAIN とネガティブキャッシュ 900 秒が出たら、委任を直してから 15 分は「直らなかった」と判断しないこと。1 日と出たら長い尾を覚悟し、その間に二度目の「修正」を入れないことです。

ターミナルで同じ確認をする

このページに独自の仕組みはなく、どの行も dig で再現できます。ツールは入力したドメイン用のコマンドをそのまま出力します。要になるのは次の 5 つ、.jp ならさらに 2 つです。

dig NS example.com +short          # 委任がいま解決する先
      dig @8.8.8.8 NS example.com +short # 特定のキャッシュ 1 つに同じ質問
      dig @1.1.1.1 NS example.com +short # もう 1 つのキャッシュ。答えが違えば浸透待ち
      dig SOA example.com                # NXDOMAIN なら authority に否定したゾーンが出る
      curl -sL https://rdap.org/domain/example.com   # レジストリ自身の登録内容(NS・状態・DNSSEC)
      
      # .jp は RDAP がない(rdap.org も 404 を返す)ので、代わりにこの 2 つ
      whois -h whois.jprs.jp example.jp/e       # JPRS WHOIS(/e で英語表示)
      dig +norecurse NS example.jp @a.dns.jp    # JP DNS がいま公開している委任(TTL 86400)

鎖全体を見たいなら、dig +trace NS example.jp がルートから 1 委任ずつ辿り、どこで止まるかを示します。Windows なら nslookup -type=NS example.jp 8.8.8.8。どちらも使えない環境でも、同じ 2 系統のリゾルバは HTTPS で答えます。

curl -s -H 'accept: application/dns-json' \
        'https://dns.google/resolve?name=example.jp&type=NS'

このページが実際に投げているのがこのリクエストです。JSON の Status が RCODE(0 が NOERROR、2 が SERVFAIL、3 が NXDOMAIN)、Answer がレコードで、否定応答では Authority にそれを出したゾーンの SOA が入ります。

ブラウザから見えないもの、CLI で足せるもの

このページの限界もはっきりさせておきます。ブラウザから話せるのは HTTPS のフルサービスリゾルバと、多くの TLD ではレジストリの RDAP です。読めるのは、レジストリに何が登録されているか、委任の鎖が解決するか、ゾーンが何を答えるか、の 3 つ。TLD のネームサーバーには直接聞けず、管理画面や事業者側の申請待ちも見えず、.jp のように RDAP をブラウザに開いていない TLD ではレジストリそのものが見えません。手前のプロキシ、未発行の証明書、作られていないホスティングの割り当て、502 を返すオリジンも見えません。どれも体感は「ネームサーバーを変えたらサイトが落ちた」ですが、DNS の問題ではありません。

clize domain check <domain> は、この 1 層目の上にさらに 3 層を重ねたものです。同じ 2 系統の DoH 探索(dns.google を優先、cloudflare-dns をフォールバック、RCODE を 3 状態として読む)に続けて、Cloudflare のゾーン、ホスト名とサイトワーカーの結び付き、実際に内容が配信されているかを確認します。4 層を 1 コマンドで。ドメインを省略すればアカウント上の全ドメインを一巡し、プラットフォーム側では 30 分ごとの cron が同じ探索を回して、2 回連続で異常だったときにだけ警告メールを送ります。

周辺については、DNS TTL 計算ツールが切り替え前に TTL をいつ下げるかを、Agent Domains が CLI からのドメインの購入・取り込み・接続を扱っています(後者は英語)。日本語での全体像は Clize の日本語トップにあります。

$ npm i -g @clize/clize && clize install
$ clize domain check example.jp