NS検索 — ネームサーバー確認ツール

ドメインのネームサーバーを確認できるツールです。レジストリが返すNSレコードをグルーとTTLとともに表示し、各ネームサーバー自身の応答と並べます。ドメインのネームサーバー検索で、レームなサーバー、不一致、古いグルーを見つけ、対処法まで示します。

情報源:ルートサーバーからたどったレジストリのサーバー · 各ネームサーバーのIPv4アドレスへの直接の問い合わせ · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

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レコードを部分ごとに見るgoogle.com · 2026-10-23に記録
google.com.所有者名345600TTLINクラスNSタイプns1.google.com.値
所有者名このレコードが属するゾーンです。
TTL · 4 日リゾルバーがこのレコードを保持してよい時間です。.comのコピーでは2 日です。
NSレコードタイプ2:このゾーンのネームサーバーです。
値固有のAまたはAAAAレコードを持つホスト名です。
親のコピー · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10権威ではない:グルー付きのリファラル
ゾーン自身のコピーgoogle.com. 345600 NS ns1.google.com.;; flags: qr aa権威:リゾルバーが保持するもの
ns1.google.com.固有のアドレスを持つホスト名
216.239.32.10アドレスは有効な値ではありません
ns.example.com. → CNAME別名は不可(RFC 2181 §10.3)
2つのコピーはどちらも実際に取得したものです:l.gtld-servers.netが返した.comレジストリのリファラルと、ns1.google.com自身の応答です。

ドメインのネームサーバーと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の2つの応答の読み方google.com · 2026-10-23に記録
dig · macOS、Linux
$ 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
…
  1. aaなし:リファラル。 レジストリはgoogle.comを運用しておらず、どこへ行けばよいかを案内します。
  2. 親の一覧と そのTTL:2 日。.comレジストリが設定したものです。
  3. グルー: ns1.google.comはgoogle.comの内側にあるため、.comがそのアドレスを返します。
  4. aa:ゾーン自身。 サーバーからの権威ある応答です。
  5. ゾーン自身のTTL: 4 日。レジストリではなくGoogleが設定したものです。
nslookup · 8.8.8.8に問い合わせ
$ 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.
…
PowerShell
# リゾルバーのコピー
PS> Resolve-DnsName -Name google.com -Type NS

# 1台のサーバー、再帰オフ
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
2026-10-23に記録しました。「Non-authoritative answer」は、リゾルバー(ここではGoogle Public DNS)のキャッシュのコピーという意味で、NSレコードは最長6 時間しか保持されません。whoisが表示するのはレジストリの一覧です。どちらも、各サーバーの応答は表示しません。

結果の読み方

判定には、DNSホストとレジストラが表示されます。「委任」表示では、レジストリの一覧とゾーンの一覧がサーバーごとに並び、各サーバーの応答と、TCPでの応答時間(接続の確立を含むため、往復およそ2回分)が分かります。

紺色の列は、リゾルバーがたどる経路です:ルート、TTLとDSを持つレジストリ、そして各ネームサーバー。ゾーンを運用していないサーバーは、途切れた状態で表示されます。

github.comのNS検索結果:NS1とRoute 53の8台のネームサーバー、各サーバーの応答と.comからの委任github.comのNS検索結果:NS1とRoute 53の8台のネームサーバー、各サーバーの応答と.comからの委任判定誰がゾーンを運用し、誰が登録し、レジストリとゾーンが一致しているか。レジストリとゾーンの並列表示レジストリの一覧とゾーン自身の一覧にある各名前を、グルーと応答とともに表示します。各サーバーの応答AAとTCPでの応答時間、拒否したサーバーが返したコード、当サイトのサーバーから接続できない場合は1.1.1.1経由の表示。委任ルート、レジストリ、そして各サーバー自身の応答を、リゾルバーがたどる順に表示します。
github.comのNS検索の例です。判定、レジストリの8台のネームサーバーとゾーン自身の一覧、各サーバーの応答、.comレジストリからの委任を表示します。番号を選ぶと、各部分に何が表示されているかを確認できます。

親と子のネームサーバーが異なる理由

2つの一覧は、別々の当事者が管理しています。親の一覧は、レジストラが指示したときにレジストリが公開し、ゾーン自身の一覧はDNSホストが提供します。どちらか一方だけを変更すると、2つはずれていきます。

リゾルバーは、リファラルよりもゾーン自身の応答を信頼するため(RFC 2181 §5.4.1)、いったんゾーンに問い合わせると、その一覧とTTLを保持します。2026-10-23の時点で、Cloudflareのリゾルバーはgoogle.comのNSセットを残り340,859秒で保持していました:.comの172,800秒より長く、コピーはゾーンの4日のTTLに由来します。

レジストリの一覧にしかない名前には、新たに問い合わせを始めるリゾルバーからのトラフィックが届きます。ゾーンにしかない名前は、そうしたリゾルバーからは見えません。どちらも直す価値はありますが、それだけで障害になることはありません。

レジストリの一覧とゾーンの一覧2026-10-23に記録
xserver.ne.jp5台 対 3台

レジストリ .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はレジストリにのみあります。どちらも権威ある応答を返すため、障害は起きませんが、一覧は異なっています。

github.com同じ8台

レジストリ .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 時間です。

.netドメイン(名前は非公開)共通の名前なし

レジストリ .net2 日

  • ns1.domaindirect.comレジストリのみ
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comレジストリのみ

ゾーン15 分

  • ns1.hover.comゾーンのみ
  • ns2.hover.comゾーンのみ

レジストリには、まだ古い名前が登録されています。そのうち2つはHoverのサーバーとアドレスが同じで応答し、3つ目は拒否します。

線は、2つの一覧に共通する名前を結びます。破線は、同じアドレスを持つ2つの名前を結びます。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などの名前で設定します。サーバーを移すときは、グルーも移す必要があります:古いグルーは、リゾルバーを、もう応答しないアドレスへ誘導します。

グルーと、それが必要なとき.comで記録 · 2026-10-23

ドメイン内 · google.com

  1. .com:ns1.google.comに問い合わせ
  2. そのアドレスはgoogle.com自身の中にあります
  3. グルーがないと、名前解決が堂々巡りになります
  4. そこで.comはns1.google.com A 216.239.32.10を添えます · MUST:必須

同じ親の下と無関係 · github.com

  1. .com:ns-421.awsdns-52.com, ns-520.awsdns-01.net, …に問い合わせ
  2. awsdns-52.comも.comの下にあります:グルー 205.251.193.165 · SHOULD:含める
  3. awsdns-01.netは別の場所にあります:リゾルバーは.netで名前解決します · グルーなし
古いグルー · 実例64.69.208.141ns1.register.comの.comのグルー · 応答なし、2回問い合わせ162.214.41.25現在のAレコード · 権威ある応答あり
2026-10-23にrdap.verisign.comで読み取った、.comにあるns1.register.comのホストオブジェクトです:レジストリには、サーバーが手放したアドレスが今も残っており、グルーとして返されています。

レームデリゲーションとは? 修正方法

親がリゾルバーを、ゾーンを運用していないサーバーに誘導しているとき、その委任はレーム(lame)です:サーバーは拒否する、何も返さない、または権威なしで応答します。リストされたすべてのサーバーがレームなら、ドメインは名前解決できなくなります。いくつかのうちの1台だけなら、リゾルバーが再試行する間、問い合わせが遅くなります。

RFC 9499は、「レームデリゲーション」がいくつもの障害を指すようになったと述べているため、ツールはそれぞれに名前を付けます:ゾーンを拒否(REFUSED)、応答なし(2回問い合わせ)、権威なしで応答(aaなし)、サーバーエラー(SERVFAIL)。TCPでの無応答だけでは、GoogleとCloudflareがドメインを名前解決できている限り、レームとは呼びません:UDPで応答している可能性があるため、TCP応答なしと表示します。

修正は常に、2つのうちどちらかです:レジストリが指しているDNSホストにゾーンを追加するか、レジストリの向き先を、ゾーンのあるホストに変えます。修正後も、リゾルバーは最大5分間、失敗を記憶していることがあります(RFC 9520)。

記録した3つのレームなサーバー2026-10-23 · ドメインは非公開

ゾーンを拒否

ns63 · ns64.domaincontrol.com

.comが示すGoDaddyのサーバー2台は、どちらもREFUSEDを返します:そこにはゾーンが設定されていません。

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

タイムアウトの後にREFUSED

ns1 · ns2.eftydns.com

1台のサーバーが一度タイムアウトし、もう一度問い合わせるとREFUSEDを返しました。1回のタイムアウトは判定ではありません:ツールは状態に名前を付ける前に、再度問い合わせます。

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# 再度問い合わせ
;; … status: REFUSED

3台のうち1台

ns1 · ns2 · ns3.domaindirect.com

2台のサーバーは権威ある応答を返し、3台目は拒否します。ドメインは動作しますが、遅くなります。

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. レジストリの向き先を確認「委任」表示に、レジストリのサーバーと各サーバーの応答が一覧表示されます。
  2. どちらか一方を修正そのホストにゾーンを追加するか、レジストラでネームサーバーを変更します。
  3. もう一度確認応答はすぐに戻ります。キャッシュされた失敗は最大5 分続きます。

すべてのサーバーがレームのとき、訪問者に表示されるもの:Google SERVFAILCloudflare SERVFAIL

無作為なスキャンで見つかった登録から記録したもので、名前は非公開です。example.comとexample.netとして表示しています。

ネームサーバーは何台必要?

最低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)。

ネットワークごとにまとめたサーバー2026-10-23に記録
ドメインネットワーク別のサーバーNSネットワーク判定
google.comGoogle · AS15169 · anycast41anycast、運用者は1社
github.comNS1 · AS62597Route 53 · AS16509 · anycast822プロバイダー
bbc.co.ukNetActuate · AS63911NS1 · AS62597822ネットワーク
xserver.ne.jpXserver · AS131965Amazon · AS16509522ネットワーク
craigslist.orgcraigslist · AS22414611つの/22

「ほとんどの組織レベルのゾーンには3台のサーバーを用意し、少なくとも1台は他から十分に離れた場所に置くことが推奨される。」

RFC 2182 §5 · BCP 16、1997年7月 · 2台が必須、3台を推奨
1つの枠が1つのネットワーク(AS)で、色付きの枠はanycastのプロバイダーです:多数の拠点があっても運用者は1社です。xserver.ne.jpの2つ目のネットワークは、Amazon上のns2.xserver.jpです。craigslist.orgの6台は、1つの/22を共有しています。

ネームサーバーの変更方法と、反映にかかる時間

変更は、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)。

変更する場所と、2つの時計TTLは2026-10-23に測定

レジストラで:各社の公式ガイド

レジストリのコピーが続く時間(親の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 時間
親のTTLは、各レジストリ自身のサーバーから取得しました(dig +norec)。.ioは、よく言われる300秒ではなく3,600秒を返しました。レジストラは今も一律の時間を案内しています:GoDaddyは「最大48時間」、Namecheapは「最大24時間」です。

NS・SOA・グルーレコードの違い

委任点では3つのレコードが交わります。NSはサーバーを指定します:親のコピーは道を示し、ゾーンのコピーが権威です。グルーは、ゾーンの内側に名前があるサーバーについてだけ、親が保持するAまたはAAAAレコードです。SOAはゾーンごとに1つ、その最上位にあります:プライマリサーバー、連絡先アドレス、シリアル、各種タイマーです。

SOAにaaフラグ付きで応答するサーバーが、そのゾーンを保持しています。ツールがすべてのサーバーにSOAを問い合わせるのはこのためです。シリアルからは、サーバー同士が同じバージョンを持っているかが分かります:Route 53は1から始まり、自動では変わりません。2つのプロバイダーに置いたゾーンには2つのシリアルがありますが、どちらも正常です。

2つのゾーン、1つの境界google.com · 2026-10-23に記録

.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サーバー自身のアドレス:グルーはこれと一致しているべきです
グルーとサーバー自身のAレコードは、1つの事実の2つのコピーです。両者が食い違っていれば、グルーが古くなっています。

NS検索とnslookupコマンドの違い

「ns lookup」で検索する人は、2つのものを探しています:ドメインのネームサーバーと、Windows、macOS、Linuxに付属するnslookupコマンドです。nslookupはリゾルバーに問い合わせ、キャッシュしている内容を表示します。-type=nsを付けると、リゾルバーが保持しているゾーンのNSセットが一覧表示されます。

そのコピーは数時間前のものかもしれず、レジストリの一覧、グルー、各サーバーがゾーンを保持しているかどうかは表示されません。このページは、到達できるそれぞれに直接問い合わせます。

ネームサーバーを調べる3つの方法
このNS検索dnsrobot.netnslookup-type=nsdigNS · +norec
問い合わせ先レジストリ、続いてすべてのサーバーお使いのリゾルバー指定した任意の1台のサーバー
レジストリとゾーンの比較両方を名前ごとにキャッシュのコピー1コマンドにつき1つの一覧
各サーバーのaa各IPv4アドレス(Aとグルー)なし1コマンドにつき1台のサーバー
グルーとTTL両方のTTL-debug付き出力に含まれる
診断名前付きで、対処法も表示なしなし
実行環境どのブラウザでもWindowsmacOSLinuxmacOSLinux

NS検索:よくある質問

NS検索とは何ですか?

NS検索は、どのネームサーバーがドメインのゾーンを保持しているかをDNSに問い合わせることです。このツールはまず、親の一覧をグルーとTTLとともにレジストリに問い合わせ、次に各ネームサーバーのIPv4アドレスにTCPで直接、ゾーンのSOAと自身のNSセットを問い合わせて、2つを比較します。DNSを運用しているのは誰か、どのサーバーが権威ある応答を返すか、リゾルバーの失敗や遅延の原因になりそうな点が分かります。

DNSプロバイダーは、どうすれば分かりますか?

ネームサーバーの名前を見ます:ns1.google.comはGoogle、*.ns.cloudflare.comはCloudflare、ns-*.awsdns-*はAmazon Route 53、01.dnsv.jpはお名前.comです。この検索は、各プロバイダーの公開されている名前のパターンからDNSホストを特定し、各アドレスの背後のネットワークは別に表示します。ホストによっては他社のネットワークで運用されているためです:PorkbunとHostingerはCloudflare、VercelはNS1です。

レジストリとゾーンで、ネームサーバーの一覧が異なるのはなぜですか?

レジストラで設定するレジストリの一覧と、DNSホストで設定するゾーン自身のNSレコードは、別々の2つのコピーで、RFC 1034は完全に同じであるべきだとしています。一方だけが変更されるとずれ、DNSホストの移行後によく起こります。レジストリから始めるリゾルバーはその一覧を使い、ゾーンに問い合わせたリゾルバーはゾーンの一覧を保持します。

レームデリゲーションとは何ですか?

レームデリゲーションとは、レジストリがリストしているのに、そのゾーンを運用していないネームサーバーのことです:REFUSEDまたはSERVFAILを返す、権威なしで応答する、あるいはまったく応答しません。リストされたすべてのサーバーがレームなら、ドメインは名前解決できなくなり、GoogleとCloudflareはSERVFAILを返します。そのDNSホストにゾーンを追加するか、レジストラでネームサーバーをゾーンのあるホストに変更して修正します。

ネームサーバーの変更が反映されるまで、どれくらいかかりますか?

2つの時計のうち長い方までです:レジストリのNSのTTL(.comと.netは2日、.ruは4日、.deと.jpは1日、.orgと.ioは1時間、.inは15分)と、古いホストにすでに問い合わせたリゾルバーが保持する、古いゾーン自身のNSのTTLです。Google Public DNSは約6時間に制限します。一律の「24~48時間」は、どちらの意味でも正しくありません。

ドメインのネームサーバーは何台にすべきですか?

最低2台です:RFC 2182は2台を必須とし、ほとんどの組織には、うち1台を他から十分に離す3台を、高い信頼性を求めるなら4~5台を推奨しています。台数より重要なのは、1つの障害がすべてに及ばないこと、つまり別のネットワークやプロバイダーに置くことです。CloudflareやRoute 53のように1社が運用するanycastのサーバーは、多数の拠点でも運用者は1社です。

グルーレコードとは何で、いつ必要ですか?

グルーは、example.comのns1.example.comのように、ゾーンの内側に名前があるネームサーバーについて、レジストリがリファラルとともに返すアドレスです。これがないと、リゾルバーはサーバーを見つけるためにそのサーバーのアドレスが必要になります。RFC 9471は、こうしたドメイン内の名前にグルーを必須としています。レジストラで、ホストレコード、child nameservers、personal DNS serversなどの名前で設定します。

ツールによって、表示されるネームサーバーが違うのはなぜですか?

多くのネームサーバー確認ツールはリゾルバーに問い合わせるため、変更後は数日前のキャッシュのコピーが表示されることがあります。一方、レジストリとゾーンは自身の情報を返します。ゾーン自身の一覧だけを表示するツールもあります。このツールは、レジストリの一覧、各サーバー自身の応答、GoogleとCloudflareのキャッシュのコピーを、各コピーの残り時間とともに並べて表示します。

「直接は確認していません」とはどういう意味ですか?

当サイトのサーバーはCloudflareのネットワーク上で動いており、Cloudflare Workerは、そのネットワーク上のアドレスに接続できません。そこにあるネームサーバー、つまりCloudflare自身のものと、PorkbunやHostinger、DigitalOceanなど、その上で運用するホストのものは、代わりにCloudflareのリゾルバー1.1.1.1経由で取得します:NSセットとそのTTLは分かりますが、各サーバーのAAビット、シリアル、応答時間は分かりません。

NS検索とnslookupは同じものですか?

いいえ。nslookupはWindows、macOS、Linuxにあるコマンドラインツールで、NSを含むあらゆるレコードタイプをリゾルバーに問い合わせます(nslookup -type=ns example.com)。NS検索は問い合わせの内容そのもの、つまりドメインを運用しているのはどのネームサーバーか、ということです。dig NSと同様に、nslookupはお使いのリゾルバーのキャッシュのコピーを表示します。このツールのようにレジストリと各サーバーへ直接問い合わせると、両者が一致しているかが分かります。

ネームサーバーを変更したのに、まだ反映されないのはなぜですか?

3か所を確認します:レジストリに新しいサーバーが登録されているか(なければ、変更はまだレジストラから出ていません)、新しいゾーンが権威ある応答を返すか、古いコピーがリゾルバーにどれくらい残るかです。「ネームサーバーを変更した」モードでは、新しいサーバーを入力すると、各コピーをそれと照合し、すべてのリゾルバーに行き渡るまでをカウントダウンします。

ネームサーバーを変更する前に、DNSSECを削除すべきですか?

はい。古いDNSホストと新しいDNSホストが連携できる場合を除きます。レジストリに、新しいホストの鍵と一致しないDSが残っていると、GoogleやCloudflareなど検証を行うリゾルバーはSERVFAILを返し、そのユーザーにはドメインが見えなくなります。レジストラでDSを削除し、そのTTLが過ぎるのを待ってから、ネームサーバーを変更し、新しいホストのDSを公開します。