NS検索 — ネームサーバー確認ツール
ドメインのネームサーバーを確認できるツールです。レジストリが返すNSレコードをグルーとTTLとともに表示し、各ネームサーバー自身の応答と並べます。ドメインのネームサーバー検索で、レームなサーバー、不一致、古いグルーを見つけ、対処法まで示します。
まずレジストリに問い合わせ、次にレジストリが示すすべてのネームサーバーに問い合わせます。URL、メールアドレス、サブドメインも入力できます。
NSレコードとは?
NSレコードは、ゾーン、つまりドメインのレコードが置かれている場所を保持するサーバーを指定します。ゾーンにはサーバー1台につきNSレコードが1つあり、たとえばgoogle.comにはns1からns4.google.comまでの4つがあります(RFC 1035 §3.3.11)。
同じNSレコードは2か所にあります。親ゾーン(ここでは.com)は、リゾルバーを先へ案内するため、境界にコピーを持っていますが、これは権威ある情報ではありません。ゾーンは自身の最上位に独自のコピーを持ち、こちらが権威です(RFC 1034 §4.2.1、RFC 2181 §6.1)。2つは完全に同じであるべきです。
値は常にホスト名で、アドレスでも別名でもありません:その名前には、固有のAまたはAAAAレコードが必要です(RFC 2181 §10.3)。
ドメインのネームサーバーとNSレコードを確認する方法
上の欄にドメインを入力してネームサーバーを確認を押すと、まずレジストリに問い合わせ、続いてレジストリが示すサーバーのうち当サイトのサーバーから到達できるものに、それぞれ問い合わせます。ターミナルからは、macOSとLinuxではdig NS example.com、Windowsではnslookup -type=ns example.com、PowerShellではResolve-DnsName -Name example.com -Type NSです。
この3つはお使いのリゾルバーに問い合わせるため、表示されるのはキャッシュのコピーです。レジストリの一覧を見るには、再帰をオフにしてレジストリのサーバーに問い合わせます:dig @a.gtld-servers.net example.com NS +norec。1台のネームサーバーをテストするには、+norecを付けてSOAを問い合わせ、フラグにaaがあるか確認します。whoisが表示するのも、ゾーンではなくレジストリの一覧です。
dig NS example.com +shortリゾルバーのコピーが、1行に1台のネームサーバーで表示されます。.comレジストリ自身の一覧を見るには、@a.gtld-servers.netと+norecを加えます。
$ dig @l.gtld-servers.net google.com NS +norec ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91 ;; AUTHORITY SECTION: google.com. 172800 IN NS ns2.google.com.2 google.com. 172800 IN NS ns1.google.com. … ;; ADDITIONAL SECTION: ns1.google.com. 172800 IN A 216.239.32.103 … $ dig @216.239.32.10 google.com NS +norec ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04 google.com. 345600 IN NS ns1.google.com.5 …
- aaなし:リファラル。 レジストリはgoogle.comを運用しておらず、どこへ行けばよいかを案内します。
- 親の一覧と そのTTL:2 日。.comレジストリが設定したものです。
- グルー: ns1.google.comはgoogle.comの内側にあるため、.comがそのアドレスを返します。
- aa:ゾーン自身。 サーバーからの権威ある応答です。
- ゾーン自身のTTL: 4 日。レジストリではなくGoogleが設定したものです。
$ nslookup -type=ns google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: google.com nameserver = ns3.google.com. google.com nameserver = ns1.google.com. …
# リゾルバーのコピー PS> Resolve-DnsName -Name google.com -Type NS # 1台のサーバー、再帰オフ PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
$ whois google.com Registrar: MarkMonitor Inc. Name Server: NS1.GOOGLE.COM … DNSSEC: unsigned
結果の読み方
判定には、DNSホストとレジストラが表示されます。「委任」表示では、レジストリの一覧とゾーンの一覧がサーバーごとに並び、各サーバーの応答と、TCPでの応答時間(接続の確立を含むため、往復およそ2回分)が分かります。
紺色の列は、リゾルバーがたどる経路です:ルート、TTLとDSを持つレジストリ、そして各ネームサーバー。ゾーンを運用していないサーバーは、途切れた状態で表示されます。

判定誰がゾーンを運用し、誰が登録し、レジストリとゾーンが一致しているか。レジストリとゾーンの並列表示レジストリの一覧とゾーン自身の一覧にある各名前を、グルーと応答とともに表示します。各サーバーの応答AAとTCPでの応答時間、拒否したサーバーが返したコード、当サイトのサーバーから接続できない場合は1.1.1.1経由の表示。委任ルート、レジストリ、そして各サーバー自身の応答を、リゾルバーがたどる順に表示します。親と子のネームサーバーが異なる理由
2つの一覧は、別々の当事者が管理しています。親の一覧は、レジストラが指示したときにレジストリが公開し、ゾーン自身の一覧はDNSホストが提供します。どちらか一方だけを変更すると、2つはずれていきます。
リゾルバーは、リファラルよりもゾーン自身の応答を信頼するため(RFC 2181 §5.4.1)、いったんゾーンに問い合わせると、その一覧とTTLを保持します。2026-10-23の時点で、Cloudflareのリゾルバーはgoogle.comのNSセットを残り340,859秒で保持していました:.comの172,800秒より長く、コピーはゾーンの4日のTTLに由来します。
レジストリの一覧にしかない名前には、新たに問い合わせを始めるリゾルバーからのトラフィックが届きます。ゾーンにしかない名前は、そうしたリゾルバーからは見えません。どちらも直す価値はありますが、それだけで障害になることはありません。
レジストリ .jp1 日
- ns1.xserver.jp
- ns2.xserver.jp
- ns3.xserver.jp
- ns4.xserver.jpレジストリのみ
- ns5.xserver.jpレジストリのみ
ゾーン1 時間
- ns1.xserver.jp
- ns2.xserver.jp
- ns3.xserver.jp
ns4.xserver.jp、ns5.xserver.jpはレジストリにのみあります。どちらも権威ある応答を返すため、障害は起きませんが、一覧は異なっています。
レジストリ .com2 日
- dns1.p08.nsone.net
- dns2.p08.nsone.net
- dns3.p08.nsone.net
- dns4.p08.nsone.net
- ns-1283.awsdns-32.org
- ns-1707.awsdns-21.co.uk
- ns-421.awsdns-52.com
- ns-520.awsdns-01.net
ゾーン15 分 · 1 時間
- dns1.p08.nsone.net
- dns2.p08.nsone.net
- dns3.p08.nsone.net
- dns4.p08.nsone.net
- ns-1283.awsdns-32.org
- ns-1707.awsdns-21.co.uk
- ns-421.awsdns-52.com
- ns-520.awsdns-01.net
名前は同じでも、時計が違います:レジストリのコピーは2 日、Route 53は15 分、NS1は1 時間です。
レジストリ .net2 日
- ns1.domaindirect.comレジストリのみ
- ns2.domaindirect.comREFUSED
- ns3.domaindirect.comレジストリのみ
ゾーン15 分
- ns1.hover.comゾーンのみ
- ns2.hover.comゾーンのみ
レジストリには、まだ古い名前が登録されています。そのうち2つはHoverのサーバーとアドレスが同じで応答し、3つ目は拒否します。
グルーレコードとは?
グルーは、親がリファラルとともに返すアドレスです。これにより、リゾルバーは、自身が運用するゾーンの内側に名前があるネームサーバーに到達できます。グルーがなければ、ns1.google.comを見つけるには、google.comのサーバーに問い合わせる必要があり、それは最初の問い合わせそのものです(RFC 1034 §4.2.1)。
RFC 9471はこれを規則にしています:リファラルは、ドメイン内のすべてのサーバー(google.comのns1.google.com)のグルーを含まなければならず(MUST)、同じ親の下にある兄弟サーバー(github.comのns-421.awsdns-52.com)のグルーも含めるべきです(SHOULD)。ns-520.awsdns-01.netのような無関係な名前は、別に名前解決されます。
グルーはレジストラで、ホストレコード、child nameservers、personal DNS serversなどの名前で設定します。サーバーを移すときは、グルーも移す必要があります:古いグルーは、リゾルバーを、もう応答しないアドレスへ誘導します。
ドメイン内 · google.com
- .com:ns1.google.comに問い合わせ
- そのアドレスはgoogle.com自身の中にあります
- グルーがないと、名前解決が堂々巡りになります
- そこで.comはns1.google.com A 216.239.32.10を添えます · MUST:必須
同じ親の下と無関係 · github.com
- .com:ns-421.awsdns-52.com, ns-520.awsdns-01.net, …に問い合わせ
- awsdns-52.comも.comの下にあります:グルー 205.251.193.165 · SHOULD:含める
- awsdns-01.netは別の場所にあります:リゾルバーは.netで名前解決します · グルーなし
レームデリゲーションとは? 修正方法
親がリゾルバーを、ゾーンを運用していないサーバーに誘導しているとき、その委任はレーム(lame)です:サーバーは拒否する、何も返さない、または権威なしで応答します。リストされたすべてのサーバーがレームなら、ドメインは名前解決できなくなります。いくつかのうちの1台だけなら、リゾルバーが再試行する間、問い合わせが遅くなります。
RFC 9499は、「レームデリゲーション」がいくつもの障害を指すようになったと述べているため、ツールはそれぞれに名前を付けます:ゾーンを拒否(REFUSED)、応答なし(2回問い合わせ)、権威なしで応答(aaなし)、サーバーエラー(SERVFAIL)。TCPでの無応答だけでは、GoogleとCloudflareがドメインを名前解決できている限り、レームとは呼びません:UDPで応答している可能性があるため、TCP応答なしと表示します。
修正は常に、2つのうちどちらかです:レジストリが指しているDNSホストにゾーンを追加するか、レジストリの向き先を、ゾーンのあるホストに変えます。修正後も、リゾルバーは最大5分間、失敗を記憶していることがあります(RFC 9520)。
ゾーンを拒否
ns63 · ns64.domaincontrol.com
.comが示すGoDaddyのサーバー2台は、どちらもREFUSEDを返します:そこにはゾーンが設定されていません。
$ dig @ns63.domaincontrol.com \ example.com SOA +norec ;; … status: REFUSED ;; flags: qr; … ANSWER: 0
タイムアウトの後にREFUSED
ns1 · ns2.eftydns.com
1台のサーバーが一度タイムアウトし、もう一度問い合わせるとREFUSEDを返しました。1回のタイムアウトは判定ではありません:ツールは状態に名前を付ける前に、再度問い合わせます。
$ dig @ns1.eftydns.com \ example.com SOA +norec ;; connection timed out # 再度問い合わせ ;; … status: REFUSED
3台のうち1台
ns1 · ns2 · ns3.domaindirect.com
2台のサーバーは権威ある応答を返し、3台目は拒否します。ドメインは動作しますが、遅くなります。
$ dig @ns2.domaindirect.com \ example.net SOA +norec ;; … status: REFUSED # ns1, ns3: NOERROR, flags qr aa
- レジストリの向き先を確認「委任」表示に、レジストリのサーバーと各サーバーの応答が一覧表示されます。
- どちらか一方を修正そのホストにゾーンを追加するか、レジストラでネームサーバーを変更します。
- もう一度確認応答はすぐに戻ります。キャッシュされた失敗は最大5 分続きます。
すべてのサーバーがレームのとき、訪問者に表示されるもの:Google SERVFAILCloudflare SERVFAIL
ネームサーバーは何台必要?
最低2台です:「DNSの仕様とドメイン名の登録規則は、すべてのゾーンに少なくとも2台のサーバーを求めている」(RFC 2182 §5、BCP 16)。同じ節は、ほとんどの組織には、うち1台を他から十分に離して置く3台を、信頼性がより重要な場合には4~5台を推奨しています。
数えるのは名前ではなくネットワークです。1つの障害がすべてに及ばない場所にサーバーを置くべきです(RFC 2182 §3.1):1つの/22にある6台は、同じ経路上の運命を共有します。anycastは1つのアドレスを多数の拠点に広げ、よく使われる解決策ですが、運用者は1社のままです。2つ目のプロバイダーがあれば、その運用者の障害にも耐えられます(RFC 8901)。
それ以上でも問題ありません。RFC 1912の上限7台は、512バイトのUDP応答に由来するもので、大規模なゾーンでは現在8台を運用しています(github.com、bbc.co.uk)。
| ドメイン | ネットワーク別のサーバー | NS | ネットワーク | 判定 |
|---|---|---|---|---|
| google.com | Google · AS15169 · anycast | 4 | 1 | anycast、運用者は1社 |
| github.com | NS1 · AS62597Route 53 · AS16509 · anycast | 8 | 2 | 2プロバイダー |
| bbc.co.uk | NetActuate · AS63911NS1 · AS62597 | 8 | 2 | 2ネットワーク |
| xserver.ne.jp | Xserver · AS131965Amazon · AS16509 | 5 | 2 | 2ネットワーク |
| craigslist.org | craigslist · AS22414 | 6 | 1 | 1つの/22 |
「ほとんどの組織レベルのゾーンには3台のサーバーを用意し、少なくとも1台は他から十分に離れた場所に置くことが推奨される。」
RFC 2182 §5 · BCP 16、1997年7月 · 2台が必須、3台を推奨
ネームサーバーの変更方法と、反映にかかる時間
変更は、DNSホストではなく、ドメインを登録しているレジストラで行います:レジストラが新しい一覧をレジストリに送り、レジストリが公開します。先に新しいホストにすべてのレコードを含むゾーンを追加しておくと、新しいサーバーが指定された瞬間から応答できます。
その後、2つの時計が進みます。レジストリのリファラルをキャッシュしたリゾルバーは、親のTTLの間、古い一覧を保持します:.comは2日、.deと.jpは1日、.orgは1時間です。すでにゾーンに問い合わせたリゾルバーは、古いゾーン自身のNSセットをそのTTLの間保持し、こちらの方が長いこともあります:google.comは4日です。Google Public DNSがNSを保持するのは最長6時間です。
つまり、決して一律の「24~48時間」ではありません。長い方の時計が終わるまで、古いDNSホストが同じレコードに応答し続けるようにしてください。署名済みのドメインでは、移行の前にDSを削除します(RFC 6781)。
レジストラで:各社の公式ガイド
- GoDaddyDNS → Nameservers
- NamecheapDomain List → Manage → Nameservers
- Squarespace DomainsDNS → Domain Nameservers
- PorkbunDetails → Nameservers
- お名前.comネームサーバー/DNS → ネームサーバー設定
- XServerドメインネームサーバー設定
- ムームードメインドメイン管理 → ネームサーバー設定変更
- Cloudflare RegistrarCloudflareのネームサーバーのままになります
レジストリのコピーが続く時間(親のNSのTTL)
- .ru4 日345,600 s
- .com2 日172,800 s
- .uk2 日172,800 s
- .de1 日86,400 s
- .jp1 日86,400 s
- .tr12 時間43,200 s
- .dev3 時間10,800 s
- .org1 時間3,600 s
- .io1 時間3,600 s
- .in15 分900 s
変更後の時計
- キャッシュに残る古いリファラル親のTTL.com:最大2 日
- キャッシュに残る古いゾーンのNSセット古いゾーンのTTLgoogle.com:最大4 日
- Google Public DNSNSの上限最大6 時間
NS・SOA・グルーレコードの違い
委任点では3つのレコードが交わります。NSはサーバーを指定します:親のコピーは道を示し、ゾーンのコピーが権威です。グルーは、ゾーンの内側に名前があるサーバーについてだけ、親が保持するAまたはAAAAレコードです。SOAはゾーンごとに1つ、その最上位にあります:プライマリサーバー、連絡先アドレス、シリアル、各種タイマーです。
SOAにaaフラグ付きで応答するサーバーが、そのゾーンを保持しています。ツールがすべてのサーバーにSOAを問い合わせるのはこのためです。シリアルからは、サーバー同士が同じバージョンを持っているかが分かります:Route 53は1から始まり、自動では変わりません。2つのプロバイダーに置いたゾーンには2つのシリアルがありますが、どちらも正常です。
.comゾーン運用:Verisign
- NSgoogle.com. 172800 NS ns1.google.com.委任:次に向かう場所 · 権威ではない
- Ans1.google.com. 172800 A 216.239.32.10グルー:サーバーに到達できるよう、そのアドレスを返します
- DSDSなし:google.comは未署名ですDS:子の署名鍵を指します。署名済みゾーンのみ(cloudflare.com DS 2371 13 2)
ゾーンの境界 · google.com
google.comゾーン運用:Google
- NSgoogle.com. 345600 NS ns1.google.com.ゾーン自身の一覧 · 権威
- SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60ゾーンに1つ:プライマリ、連絡先、シリアル、タイマー
- Ans1.google.com. 345600 A 216.239.32.10サーバー自身のアドレス:グルーはこれと一致しているべきです
NS検索とnslookupコマンドの違い
「ns lookup」で検索する人は、2つのものを探しています:ドメインのネームサーバーと、Windows、macOS、Linuxに付属するnslookupコマンドです。nslookupはリゾルバーに問い合わせ、キャッシュしている内容を表示します。-type=nsを付けると、リゾルバーが保持しているゾーンのNSセットが一覧表示されます。
そのコピーは数時間前のものかもしれず、レジストリの一覧、グルー、各サーバーがゾーンを保持しているかどうかは表示されません。このページは、到達できるそれぞれに直接問い合わせます。
| このNS検索dnsrobot.net | nslookup-type=ns | digNS · +norec | |
|---|---|---|---|
| 問い合わせ先 | レジストリ、続いてすべてのサーバー | お使いのリゾルバー | 指定した任意の1台のサーバー |
| レジストリとゾーンの比較 | 両方を名前ごとに | キャッシュのコピー | 1コマンドにつき1つの一覧 |
| 各サーバーのaa | 各IPv4アドレス(Aとグルー) | なし | 1コマンドにつき1台のサーバー |
| グルーとTTL | 両方のTTL | -debug付き | 出力に含まれる |
| 診断 | 名前付きで、対処法も表示 | なし | なし |
| 実行環境 | どのブラウザでも | WindowsmacOSLinux | macOSLinux |
NS検索:よくある質問
NS検索とは何ですか?
DNSプロバイダーは、どうすれば分かりますか?
レジストリとゾーンで、ネームサーバーの一覧が異なるのはなぜですか?
レームデリゲーションとは何ですか?
ネームサーバーの変更が反映されるまで、どれくらいかかりますか?
ドメインのネームサーバーは何台にすべきですか?
グルーレコードとは何で、いつ必要ですか?
ツールによって、表示されるネームサーバーが違うのはなぜですか?
「直接は確認していません」とはどういう意味ですか?
NS検索とnslookupは同じものですか?
ネームサーバーを変更したのに、まだ反映されないのはなぜですか?
ネームサーバーを変更する前に、DNSSECを削除すべきですか?
関連するDNSツール
DNS検索
ドメイン自身のネームサーバーから全DNSレコードを取得し、GoogleとCloudflareのキャッシュと比較
WHOIS検索
RDAPでドメインの登録情報、レジストラ、所有者の詳細を検索
ホスティングチェッカー
あらゆるサイトのホスティング会社を特定:ホスト、CDN、CMS、メールプロバイダー、レジストラ、SSL発行元
MX検索
メール交換レコードとメールサーバーの詳細を検索
ドメインからIP変換
ドメイン名をIPアドレスに変換(位置情報・CDN検出付き)
逆引きDNS
PTRレコードでIPアドレスに関連するホスト名を検索
サブドメイン検索
ドメインの全サブドメインを検出
ドメイン年齢チェッカー
WHOISでドメインの登録日、年齢、有効期限、レジストラ情報を確認