// 無料ツール · ネームサーバーの委任を確認
ネームサーバー確認ツール
ネームサーバーを変更したのに反映されない——そのとき知りたいのは「待てば直るのか、もう壊れているのか」です。ドメインを入力すると、独立した 2 系統の公開リゾルバに同じ質問を投げ、レジストリ側に実際に何が入っているかを読み取ります。NS の問い合わせに対する答えは 2 種類ではなく 3 種類です。NOERROR + NS レコードあり = 委任は生きていて、キャッシュの期限切れを待っている状態。NXDOMAIN = 上位ゾーンにそのドメインの委任がない。SERVFAIL = 委任はあるが権威サーバーが答えていない。無料・登録不要・ブラウザ内で完結します。
ドメイン名でもホスト名でも URL でも構いません(www.example.jp / https://example.jp/blog も可)。NS・SOA・MX・TXT は登録可能なドメインに対して、A・AAAA は入力したホスト名に対して問い合わせます。
1 行に 1 つ、カンマ区切りでも構いません。入力すると、設定した組み合わせが公開 DNS から返ってくる組み合わせと一致しているかも判定します。
例で試す — それぞれ 3 種類の答えのうち別の 1 つに当たります:
ネームサーバーの変更が反映されたか確認する手順
このページ上で完結する 3 ステップです。ブラウザから HTTPS で公開 DNS を読むだけなので、管理画面の認証情報は不要で、インストールも登録もありません。
- ドメインを入力します。 ドメイン名・ホスト名・URL のいずれかを入力して「確認」を押します。dns.google と cloudflare-dns に対して NS・SOA・A・AAAA・MX・TXT を並行で問い合わせ、同じ公開 DNS を 2 つの独立した視点から読みます。
- 最初に委任の行を読みます。 状態は 3 つのいずれかです。NOERROR + ネームサーバーなら委任は生きていてキャッシュ待ち。NXDOMAIN なら上位ゾーンに委任がなく、待っても状況は変わりません。SERVFAIL なら委任はあるものの、その先のサーバーがゾーンを応答していません。
- 次に 2 系統を見比べます。 dns.google と cloudflare-dns で返るネームサーバーやアドレスが違えば、片方が古いキャッシュを保持しているだけで、放っておけば解消します。両方が一致していて、それでも設定した値と違うなら、変更はレジストリまで届いていません。
答えは 2 種類ではなく 3 種類です
この話題の説明はたいてい「動いている」か「まだ浸透中」の 2 択になっています。この切り分けが間違っているせいで、放っておいても絶対に直らない状態を 3 日間待ってしまう人が出ます。NOERROR + NS レコードあり = 委任は生きていて、キャッシュの期限切れを待っている状態。NXDOMAIN = 上位ゾーンにそのドメインの委任がない。SERVFAIL = 委任はあるが権威サーバーが答えていない。
| 返ってくる答え | 意味 | 待てば直る? |
|---|---|---|
NOERROR + NS レコード | レジストリに委任があり、その先のネームサーバーも応答している。ここに表示される値が、外から見えている値です。 | はい(表示が新しい値なら)。古い値なら、まだ保持しているキャッシュがあるだけで、期限が来れば消えます。 |
NXDOMAIN | 上位ゾーン(jp. / com. など)に問い合わせた結果、その名前は存在しないという答え。辿るべき委任そのものがありません。 | いいえ。この状態で進行中のものは何もありません。 |
SERVFAIL | 上位ゾーンから委任は返ってきた——つまり委任はある——のに、その先のサーバーが答えられなかった状態。NS の指定ミス、移行先にゾーンを作っていない、上位に残った DS レコードが現在の DNSSEC 鍵と合わない、などです。 | いいえ。ゾーンか DS レコードを直す必要があります。 |
「ネームサーバー 確認」で上位に出てくるページの多くは、ホスティング事業者やレジストラのヘルプで、自社の管理画面のどこに NS が表示されるかを説明しています。それは設定した値であって、外から見えている値ではありません。両者がずれている状態こそが、ここで切り分けたいものです。上のツールは応答コードに加えて SOA も読みます。健全なゾーンは SOA の問い合わせに自分自身の SOA を返します——ルートから TLD を経て自分のネームサーバーまで、鎖が最後までつながっている証拠です。委任のないドメインは NXDOMAIN を返し、authority セクションに上位ゾーンの SOA を入れてきます。レジストリが「そんな名前は持っていない」と明言しているわけです。ブラウザから見れば、この 2 つはどちらも「開かないページ」で見分けがつきません。中身はまったく別の問題です。
「DNS 浸透」の正体は、キャッシュの期限切れです
日本語圏では長らく「浸透」という言い方そのものが議論の的になってきましたが、その指摘は技術的に正しいものです。何かがサーバーからサーバーへ伝播しているわけではありません。ネームサーバーを変更すると、レジストリは新しい委任をすぐ書き込み、関係する権威サーバーはその瞬間から新しい答えを持っています。時間がかかるのは逆側です。すでに古い答えを問い合わせてキャッシュしてしまったリゾルバが、その TTL が切れるまで古い答えを返し続ける。それだけです。
この言い換えは実務を変えます。上限は「24〜48 時間」という慣用句ではなく、古いレコードに設定されていた TTL と、上位ゾーンの NS の TTL(レジストリによっては 48 時間)で決まります。古い TTL が 5 分なら 5 分で終わります。2 日なら、何度リロードしても変わりません。世界地図に緑と赤の点を出すツールが教えてくれるのは「どのキャッシュが切り替わったか」だけで、「設定が正しいかどうか」ではありません。
上のツールは慣用句ではなく数字を返します。どの応答にも、そのリゾルバが保持しているコピーの残り TTL が付きます。そのキャッシュがあと何秒だけ古い答えを返し得るか、という具体的な時間です。2 系統で値が違えば、それが「浸透中」の実体。2 系統とも一致していて、なお設定した値と違うなら、進行中のものは何もありません——レジストリまで届いていないので、待つのではなく管理画面か窓口に戻る場面です。
ネームサーバー変更のあとに実際に壊れるもの
上の委任の状態でどの系統かが分かります。ここから先は、では何を見に行くか、です。
- 管理画面では保存できているのに、レジストリまで届いていない。公開 DNS には古い値が残ります。ツール上の見え方は「2 系統とも一致、しかも古いネームサーバー」。これは待つ案件ではなく問い合わせる案件です。
- 移行先にゾーンを作らないまま委任だけ切り替えた。指定されたサーバーはそのドメインを知らないので応答できません。見え方は 2 系統とも SERVFAIL。先にゾーンを作り、後で委任を変える——順序がすべてです。
- DNSSEC を有効にしたまま移行した。上位に残った DS レコードが移行前の鍵を指しているため、検証するリゾルバは新しい側の答えを拒否します。見え方は全体的に SERVFAIL。レジストラ側で DS を削除し、TTL を待ってから新しい側で有効化し直します。
- レコードを移していない。委任も正常、ゾーンも生きているのに、実際にアクセスされるホスト名の A / AAAA がない。「変更はうまくいったのにサイトが表示されない」の最頻出パターンです。
- MX と SPF・DKIM・DMARC を忘れている。メールはサイトより静かに、そして遅れて壊れます。送信側が数日リトライするため、バウンスに気づくのが遅れるからです。上の出力ではアドレスの行だけでなく MX と TXT の行も見てください。
- 単に古くて長い TTL の中にいる。何も壊れていません。上の残り TTL がそのままカウントダウンです。
- 移行のあいだにドメインが期限切れになった、あるいは TLD ゾーンから外れた。ブラウザからは他と区別がつかず、DNS の応答では見逃しようがありません。見え方は NXDOMAIN と、authority セクションに入った上位ゾーンの SOA です。
ネガティブキャッシュ:直したのに NXDOMAIN が返り続ける理由
いちばん厄介なのは、直したのに何も起きないパターンです。委任を直した後も、ネガティブキャッシュの TTL(SOA の minimum)のあいだは NXDOMAIN が返り続けることがあります。リゾルバは「この名前は存在しない」という事実もアドレスと同じようにキャッシュします。RFC 2308 はその寿命を、SOA の minimum フィールドと SOA レコード自身の TTL の小さい方と定めており、だからツールはこれを 1 つの数字として表示します。com. では 900 秒、レジストリやルートによっては丸 1 日です。
これは自社のドメインで実際に経験しました。2026 年 6 月、4 つの .app ドメインがレジストリ側の委任を失い、約 4 日間にわたって世界中で NXDOMAIN を返しました。レジストラが委任を書き戻したのは 6 月 30 日 17:30 UTC ですが、その晩の時点でも多くの利用者からは復旧して見えませんでした。障害中に問い合わせたリゾルバが、まだネガティブキャッシュの窓の中にいたからです。その間ずっと、Cloudflare のゾーンは active、レジストラの状態欄は verified と表示していました。正しかったのは、2 系統から読んだ公開の権威 DNS だけです。4 層のドメイン健全性チェックがベンダーの状態欄ではなくレジストリ層から始まるのは、この経験があるからです。
ブラウザから見えないもの、CLI で足せるもの
このページの限界もはっきりさせておきます。ブラウザから話せるのは HTTPS 経由のフルサービスリゾルバだけなので、読めるのは 2 つ——委任の鎖が解決するか、ゾーンが何を答えるか、です。TLD のネームサーバーに直接聞くことはできませんし、管理画面も見えません。DNS の外側にあるもの——手前のプロキシ、まだ発行されていない証明書、作られていないホスティングの割り当て、502 を返すオリジン——も見えません。どれも体感は「ネームサーバーを変えたらサイトが落ちた」ですが、どれも DNS の問題ではありません。
clize domain check <domain> は、この 1 層目の上にさらに 3 層を重ねたものです。まったく同じ 2 系統の DoH 探索(dns.google を優先、cloudflare-dns をフォールバック、RCODE を 3 状態として読む)を行い、続いて Cloudflare のゾーン、ホスト名とサイトワーカーの結び付き、実際に内容が配信されているかを確認します。4 層を 1 コマンドで。ドメインを省略すればアカウント上の全ドメインを一巡します。さらにプラットフォーム側では 30 分ごとの cron が同じ探索を回し、2 回連続で異常だったときにだけ警告メールを送ります——DoH の一時的なぶれで誰も起こさないためです。
周辺については、Agent Domains が CLI からのドメイン購入・取り込み・接続を、Agent Inbox がそのドメイン上のメールボックスを扱っています(いずれも英語)。日本語での全体像は Clize の日本語トップにまとめてあります。
// よくある質問
ネームサーバーを変更したのに反映されません。待てばよいのか壊れているのか、どう見分けますか?
時計ではなく応答コードを見ます。ドメインに対して NS を問い合わせ、NOERROR + NS レコードなら委任は生きていてキャッシュの期限切れ待ちです。NXDOMAIN なら上位ゾーンに委任がなく、待っても状況は変わりません。SERVFAIL なら委任はあるが権威サーバーが答えていない状態です。そのうえで独立した 2 系統のリゾルバを見比べ、内容が違えばキャッシュ待ち、両方一致していて設定値と違うなら変更がレジストリまで届いていません。
ネームサーバーの変更が反映されるまでどれくらいかかりますか?
決まった時間はなく、「24〜48 時間」は慣用句です。レジストリは新しい委任を数分で書き込みます。待っているのは、古い答えをすでにキャッシュしたリゾルバの TTL が切れるまでの時間で、上限は古いレコードの TTL と上位ゾーンの NS の TTL(レジストリによっては 48 時間)で決まります。このページのツールは応答ごとに残り TTL を表示するので、推測ではなく数字として読めます。
管理画面ではなく、公開 DNS 側のネームサーバーを確認する方法はありますか?
このページのツールがそれです。ブラウザから dns.google と cloudflare-dns に HTTPS で問い合わせ、2 系統が返す NS・SOA・A・AAAA・MX・TXT を残り TTL 付きで並べて表示します。事業者の管理画面に表示されるのは「設定した値」で、外から見えている値とは別物です。同じ結果を再現できる dig と curl のコマンドも出力するので、あとからターミナルで確かめられます。
2 つの DNS チェッカーで違うネームサーバーが表示されるのはなぜですか?
別々のキャッシュに聞いているからで、片方がまだ変更前の答えを保持しているためです。「浸透」と呼ばれているものの実体はこれだけです。どちらの結果も間違いではなく、各リゾルバは自分がキャッシュした内容と残り時間を報告しています。古いコピーの期限が切れれば食い違いは消えます。世界地図型のツールが教えてくれるのも、どのキャッシュが切り替わったかまでです。
直したはずなのに NXDOMAIN が返り続けます。なぜですか?
ネガティブキャッシュです。リゾルバは「この名前は存在しない」という事実も一定時間覚えており、RFC 2308 はその長さを SOA の minimum フィールドと SOA レコードの TTL の小さい方と定めています。.com なら 900 秒、レジストリやルートによっては丸 1 日です。ツールは NXDOMAIN を検出したときにこの秒数を表示するので、「直っていない」と判断する前にどれだけ待つべきかが分かります。2026 年 6 月の当社の障害でも、委任が戻った数時間後まで NXDOMAIN が返り続けました。
ブラウザから見えるのは 2 層。CLI は 4 層を見ます。
同じ 2 系統の委任探索に加えて、Cloudflare のゾーン、ホスト名の結び付き、実際に内容が配信されているかまで。ドメイン 1 つでも、アカウント上の全ドメインでも。プラットフォーム側では 30 分ごとに再実行し、2 回連続で異常だったときにだけ通知します。
$ npm i -g @clize/clize && clize install $ clize domain check example.jp[ Agent Domains(Clize)→ ]