ネームサーバーが一致しない・2社が混ざっているとき｜委任を確かめる4ステップ

先に結論を書きます。

1. ネームサーバーの一覧は2か所にあります。1つは上位のゾーンにある委任、もう1つはドメイン自身のサーバーが返すものです。片方だけ書き換わることがあり、それが「管理画面の値とコマンドの値が違う」の正体です
2. どちらも、途中のリゾルバのキャッシュを通さずに直接出せます
3. 委任に載っているサーバーは1台ずつ聞きます。1台だけに聞くとその1台の答えしか分かりません
4. 何も申請していないのに2つが食い違っているなら、どちらかの側に手を入れないと揃いません
5. 意図して2社を併用しているなら、直す必要はありません。ただし両方が同じ内容を返している必要があります

dig が入っていないWindowsでも、コマンドプロンプトだけで手順を実行できます。

いま見えていることから読む場所を決めてください

状態の番号は、ステップ 3/4 の判定表の行の番号です。どの行に当たるかは、ステップ 1/4 と 2/4 で一覧を出せば決まります。

診断結果の表示について1つ補足します。この診断は、上位のゾーンの側とドメイン自身の側を比べていません。1つの一覧の中に別々の事業者の名前が入っていることを見つけたときに出る表示です。比べた結果は、この記事の手順で分かります。

出てくる用語

自分のドメインでサイトかメールを運用していて、ネームサーバーを変えた（あるいは変えたつもりの）人に向けて書いています。コマンドは、macOSかLinuxのターミナルかWindowsのコマンドプロンプトで実行します。

この最後の2つが別であることが、混乱の元になります。ドメインを取った会社といま使っているレンタルサーバーの会社が違う場合、ネームサーバーの指定は前者の画面、レコードの追加は後者の画面で行います。

委任は、上位のゾーンにそのドメインを頂点とするNSレコードの組が置かれることで成立します（RFC 9499 セクション7）。上位のゾーンにこの組があることが、そこでゾーンが分かれていることを示します（RFC 2181 セクション6）。一方、そのゾーンの権威サーバーは、ゾーンの頂点にあるNSレコードに列挙されています（RFC 2181 セクション6.1）。同じ節は、上位のゾーンのサーバーについて、そのゾーンのサーバーも兼ねている場合を除いて、切れ目にあるNSレコードを権威をもって答えるべきではないとしています。

4つのステップと控えておくもの

ステップ 1/4 と 2/4 で控えたものは、あとで元に戻すときの記録になります。画面の写しでもテキストの貼り付けでも構いませんが、必ず手元に残してください。

ステップ 1/4：上位のゾーンにある委任を出して控えてください

1-1 whoisや管理画面ではなく上位のゾーンへ直接聞きます

この記事は、whoisの検索結果もドメインの管理画面の表示も、いま何が配られているかの判定には使いません。上位のゾーンのサーバーへ直接聞きます。上位のゾーンのサーバーが返すものが、いま配られている委任だからです。途中のリゾルバのキャッシュも通りません。

手元にドメインの管理画面の値がある場合は、そのまま残しておいてください。ステップ 3/4 で、コマンドで出た一覧との突き合わせに使います。使いたい事業者が案内している値も同じです。

ただし、レジストラで出した変更の申請がまだ処理されていない段階では、ここで出るのは変更前の委任です。申請の状況は、ドメインの管理画面で確認してください。

1-2 上位のゾーンのサーバーの名前を出します

com のドメインなら次のように打ちます。

macOSとLinux:

$ dig +short NS com
m.gtld-servers.net.
g.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
k.gtld-servers.net.
f.gtld-servers.net.
j.gtld-servers.net.
l.gtld-servers.net.
i.gtld-servers.net.
b.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
c.gtld-servers.net.

Windowsのコマンドプロンプト:

> nslookup -type=NS com
権限のない回答:
サーバー:  ns4.kk-ca.net
Address:  61.115.234.26

com     nameserver = l.gtld-servers.net
        (中略。13 件)
com     nameserver = k.gtld-servers.net

g.gtld-servers.net      internet address = 192.42.93.30
        (以下、IP アドレスの一覧)

冒頭の「権限のない回答:」は、いま聞いた相手がその答えの権威ではないという意味です。ここでは名前を1つ選べればよいのでそのままで構いません。この行を気にするのはステップ 2/4 だけです。返ってきた名前からどれか1つを次で使います。

jp のドメインは com の部分を jp に置き換えます。example.co.jp のような形でも、置き換えるのは co.jp ではなく jp です。co.jp は別のゾーンへ委任されていないので、dig +short NS co.jp は1件も返しません。Windowsで nslookup -type=NS co.jp を打つと一覧ではなく jp のSOAレコードが返ります。どちらも2026年9月1日に確認しました。

どこで分かれているか分からない場合は、1-5 のやり方でルートサーバーからたどってください。

1-3 そのサーバーへ委任の一覧とTTLを聞きます

sitekensa.com の部分は自分のドメインに置き換えます。a.gtld-servers.net の部分は1-2で選んだ名前に置き換えます。

macOSとLinux:

$ dig +norecurse +noall +authority NS sitekensa.com @a.gtld-servers.net
sitekensa.com.		172800	IN	NS	ns-248.awsdns-31.com.
sitekensa.com.		172800	IN	NS	ns-971.awsdns-57.net.
sitekensa.com.		172800	IN	NS	ns-1085.awsdns-07.org.
sitekensa.com.		172800	IN	NS	ns-1749.awsdns-26.co.uk.

Windowsのコマンドプロンプト:

> nslookup -debug -norecurse -type=NS sitekensa.com a.gtld-servers.net
------------
Got answer:
    HEADER:
	opcode = QUERY, id = 2, rcode = NOERROR
	header flags:  response
	questions = 1,  answers = 0,  authority records = 4,  additional = 2

    QUESTIONS:
	sitekensa.com, type = NS, class = IN
    AUTHORITY RECORDS:
    ->  sitekensa.com
	nameserver = ns-248.awsdns-31.com
	ttl = 172800 (2 days)
    (以下 3 件)
    ADDITIONAL RECORDS:
    ->  ns-248.awsdns-31.com
	internet address = 205.251.192.248
	ttl = 172800 (2 days)
------------

この形でネームサーバーの名前が並べば、次へ進めます。この例では4件返っています。件数はドメインによって違います。2件でも問題ありません。

控えるものは2つです。1つはネームサーバーの名前の一覧、もう1つはその左または ttl = に出ている秒数です。dig では左から2列目の 172800、nslookup では ttl = 172800 (2 days) がそれにあたります。この秒数はステップ 4/4 で使います。

Windows側で -debug を付けているのはTTLを出すためです。-debug を外すと一覧は出ますが、TTLは出ません。

-debug を付けると ------------ で区切られた塊が2つ以上出ることがあります。聞いた相手の名前を逆に引く問い合わせが先に出るためです。読むのは QUESTIONS: の行に自分のドメイン名と type = NS が並んでいる塊です。

一覧はANSWERではなくAUTHORITYに入ります。上位のゾーンのサーバーは委任を返しているだけで、そのゾーンの担当ではないためです。

1-4 一覧が返らなかったとき

返り方によって意味が違います。次の3つを見分けてください。

存在しない名前だった場合:

$ dig +norecurse +noall +comments +authority NS this-domain-does-not-exist-sitekensa-test.jp @a.dns.jp
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20734
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

> nslookup -norecurse -type=NS this-domain-does-not-exist-sitekensa-test.jp a.dns.jp
*** UnKnown が this-domain-does-not-exist-sitekensa-test.jp を見つけられません: Non-existent domain
サーバー:  UnKnown
Address:  203.119.1.1

status: NXDOMAIN または Non-existent domain は、その名前が上位のゾーンに存在しないという答えです。たとえば次のようなことが考えられます。ドメインの有効期限が切れている。登録や移管の手続きが終わっていない。名前の綴りが違う。レジストリ側で保留の状態になっている。DNS側をいくら触っても変わりません。ドメインの管理画面を開き、契約の状態を先に確認してください。ここが解決するまでステップ 2/4 へは進めません。

名前はあるがNSレコードが無い場合:

$ dig +norecurse +noall +comments +authority NS www.sitekensa.com @ns-248.awsdns-31.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38679
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; AUTHORITY SECTION:
sitekensa.com.		900	IN	SOA	ns-1085.awsdns-07.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

> nslookup -norecurse -type=NS www.sitekensa.com ns-248.awsdns-31.com
サーバー:  UnKnown
Address:  205.251.192.248

sitekensa.com
	primary name server = ns-1085.awsdns-07.org
	responsible mail addr = awsdns-hostmaster.amazon.com
	serial  = 1
	refresh = 7200 (2 hours)
	retry   = 900 (15 mins)
	expire  = 1209600 (14 days)
	default TTL = 86400 (1 day)

エラーの行が出ず、status: NOERROR でSOAレコードの各項目が返っています。その名前は存在するが、NSレコードは持っていないという答えです。委任されていないサブドメインを調べたときにこの形になります。心当たりがあるなら、サブドメインを診断したときを読んでください。

答えが返らなかった場合:

$ dig +norecurse +noall +comments +authority NS sitekensa.com @192.0.2.1 +time=2 +tries=1
;; connection timed out; no servers could be reached

> nslookup -norecurse -type=NS sitekensa.com 192.0.2.1
*** UnKnown への要求がタイムアウトしました
DNS request timed out.
    timeout was 2 seconds.
サーバー:  UnKnown
Address:  192.0.2.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

聞いた相手が答えを出せなかった場合は、Windowsでは Server failed の語が出ます。2026年9月1日にWindows Server 2022（ja-JP）で確認しました。dig では status: SERVFAIL にあたります。

タイムアウトや Server failed は、その名前が存在しないという意味ではありません。聞いた相手から答えが得られなかっただけです。1-2 で出た別のサーバーの名前に替えて打ち直してください。どのサーバーでも同じなら、時間をおいて引き直します。この状態のまま先へ進むと実際には設定されているものを「設定されていない」と読み違えます。

1-5 上位のゾーンの名前が分からないとき

ルートサーバーから順にたどります。左の列に自分のドメイン名が出るまで繰り返すだけです。

1手目:

$ dig +norecurse +noall +authority NS jprs.co.jp @a.root-servers.net
jp.			172800	IN	NS	e.dns.jp.
jp.			172800	IN	NS	g.dns.jp.
jp.			172800	IN	NS	c.dns.jp.
jp.			172800	IN	NS	a.dns.jp.
jp.			172800	IN	NS	h.dns.jp.
jp.			172800	IN	NS	d.dns.jp.
jp.			172800	IN	NS	f.dns.jp.
jp.			172800	IN	NS	b.dns.jp.

左の列が jp. なので、まだ自分のドメインではありません。右の名前を1つ選んで、同じ形で打ち直します。

2手目:

$ dig +norecurse +noall +authority NS jprs.co.jp @a.dns.jp
jprs.co.jp.		86400	IN	NS	ns1.jprs.co.jp.
jprs.co.jp.		86400	IN	NS	ns2.jprs.co.jp.
jprs.co.jp.		86400	IN	NS	ns3.jprs.co.jp.
jprs.co.jp.		86400	IN	NS	ns4.jprs.co.jp.

左の列が jprs.co.jp. になりました。ここが上位のゾーンから見た委任です。1-3 で控えるものは、この一覧とTTLです。

Windowsでも同じことができます。a.root-servers.net から始めて、左の列が自分のドメイン名になるまで繰り返します。

1手目:

> nslookup -norecurse -type=NS jprs.co.jp a.root-servers.net
in-addr.arpa	nameserver = f.in-addr-servers.arpa
	(中略。逆引きの過程で出るもので、聞いた答えではありません)
サーバー:  UnKnown
Address:  198.41.0.4

jp	nameserver = e.dns.jp
jp	nameserver = g.dns.jp
	(中略。8 件)
jp	nameserver = b.dns.jp
e.dns.jp	internet address = 192.50.43.53
	(以下、IP アドレスの一覧)

2手目:

> nslookup -norecurse -type=NS jprs.co.jp a.dns.jp
サーバー:  UnKnown
Address:  203.119.1.1

jprs.co.jp	nameserver = ns1.jprs.co.jp
jprs.co.jp	nameserver = ns2.jprs.co.jp
jprs.co.jp	nameserver = ns3.jprs.co.jp
jprs.co.jp	nameserver = ns4.jprs.co.jp
ns1.jprs.co.jp	internet address = 202.11.16.49
	(以下、IP アドレスの一覧)

ルートサーバーへ聞いた1手目では先頭に in-addr.arpa の一覧が出ることがあります。これは指定したサーバー名を解決する過程で出るものです。聞いた答えではありません。読むのは サーバー: の行から下です。サーバー: UnKnown と出るのも異常ではありません。聞いた相手の名前を逆に引けなかったときに出る表示です。答えそのものは返っています。

ステップ 2/4：委任に載っているサーバーへ1台ずつ聞いて控えてください

2-1 ステップ 1/4 で出た名前すべてに聞きます

ステップ 1/4 で控えた名前を1つずつ順に聞きます。1台だけに聞くとその1台の答えしか分かりません。委任に載っているサーバーが互いに違う内容を返していることがあるので、全部に聞いてください。

macOSとLinux:

$ dig +norecurse +noall +comments +answer NS sitekensa.com @ns-248.awsdns-31.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45619
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
sitekensa.com.		172800	IN	NS	ns-1085.awsdns-07.org.
sitekensa.com.		172800	IN	NS	ns-1749.awsdns-26.co.uk.
sitekensa.com.		172800	IN	NS	ns-248.awsdns-31.com.
sitekensa.com.		172800	IN	NS	ns-971.awsdns-57.net.

Windowsのコマンドプロンプト:

> nslookup -debug -norecurse -type=NS sitekensa.com ns-248.awsdns-31.com
------------
Got answer:
    HEADER:
	opcode = QUERY, id = 2, rcode = NOERROR
	header flags:  response, auth. answer
	questions = 1,  answers = 4,  authority records = 0,  additional = 0

    QUESTIONS:
	sitekensa.com, type = NS, class = IN
    ANSWERS:
    ->  sitekensa.com
	nameserver = ns-1085.awsdns-07.org
	ttl = 172800 (2 days)
    (以下 3 件)
------------

1台ごとに2つを控えます。1つは返ってきた名前の集合、もう1つは権威の応答かどうかです。権威の応答なら dig の flags: に aa が、Windowsの header flags: に auth. answer が出ます。上の2つの例はどちらも出ています。

aa も auth. answer も出ていない場合は、そのサーバーが自分のドメインの担当になっていません。名前の集合が正しく見えるときも、次の 2-2 の「答えを返さなかったサーバー」と同じ扱いにして、名前を控えておいてください。直し方はステップ 4/4 の 4-4 にあります。

比較のために公開のDNSリゾルバへ同じことを聞いた出力を挙げます。委任に載っている名前を指定して次の形になったなら、そのサーバーは担当になっていません。

$ dig +noall +comments +answer NS sitekensa.com @8.8.8.8
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29325
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; ANSWER SECTION:
sitekensa.com.		21600	IN	NS	ns-248.awsdns-31.com.
sitekensa.com.		21600	IN	NS	ns-1749.awsdns-26.co.uk.
sitekensa.com.		21600	IN	NS	ns-971.awsdns-57.net.
sitekensa.com.		21600	IN	NS	ns-1085.awsdns-07.org.

Windowsでは、この状態のときに画面のいちばん上に「権限のない回答:」の行が出ます。ただし、この行が出ないことだけを根拠に権威だと判断しないでください。上位のゾーンのサーバーが返す委任の応答でも、この行は出ません。-debug を付けて auth. answer を見るのが確実です。

2-2 答えが返らなかったサーバーがあったとき

> nslookup -norecurse -type=NS example.com ns-248.awsdns-31.com
*** UnKnown が example.com を見つけられません: Query refused
サーバー:  UnKnown
Address:  205.251.192.248

Query refused（dig では status: REFUSED）は、聞いた相手がその問い合わせに答えることを拒んだという返事です。委任に載っている名前を指定してこれが返ったなら、そのサーバーは自分のドメインの担当になっていません。

上の例は -debug を外して打ったものです。2-1 と同じように -debug を付けたままでも構いません。*** から始まるエラーの行はデバッグの表示より前に出るので、読む場所は変わりません。

タイムアウトは別に扱ってください。応答が届かなかっただけで、拒まれたとは限りません。時間をおいて2回か3回試してください。それでも返らないときに、そのサーバーは答えを返さないものとして扱います。

Query refused が返った名前、aa も auth. answer も出なかった名前、何度試しても返らなかった名前は、控えておいてください。ステップ 4/4 で残す集合を決めるときに使います。

委任に載っている全部のサーバーがこの形だったなら、ドメイン自身の側の一覧は出せません。ステップ 3/4 の行1に当たります。

ステップ 3/4：見比べて6つのどれかに決めてください

ステップ 1/4 で控えた委任の一覧とステップ 2/4 で控えたサーバーごとの答えを並べます。上の行から順に当てはめてください。当てはまった時点で、その行です。

名前の提供元が何社かは、いま使うつもりの事業者が案内しているネームサーバーの値と突き合わせて決めます。その案内に無い名前が一覧に入っているなら、別の提供元の名前が混ざっています。案内の値は、DNSの管理画面か事業者のマニュアルにあります。

ドメインの管理画面に値が出ているなら、ステップ 1/4 で出た委任とも見比べてください。この2つが違うなら、管理画面で出した変更がまだ処理されていない可能性があります。1-1 の後半を読んでください。

ステップ 2/4 で答えを返さなかったサーバー、または権威の応答にならなかったサーバーが1台でもあるなら、行6に当たっていてもそのサーバーは直す対象です。ステップ 4/4 の 4-4 を読んでください。

行3と行4は、いまレジストラへ何も申請していないなら、手を入れるまで揃いません。上位のゾーンの側とドメイン自身の側は別々に設定されているためです。申請を出した直後なら、処理が終わるまで待ってから 1-3 をもう一度実行してください。

案内に無い名前があったとき

行5に当たったなら、まず一覧の中身を2つに分けてください。

一覧の名前が全部、使いたい事業者の案内に無いものだった場合。委任がまだ切り替わっていません。ドメインを取ったときの初期設定のまま、というのがよくある形です。ドメインの管理画面でネームサーバーの変更をすでに出しているなら、処理が終わるまで待ってから 1-3 をもう一度実行してください。まだ出していないなら、ステップ 4/4 へ進み、案内の値へ置き換えてください。

案内どおりの名前と案内に無い名前の両方があった場合。2社以上のネームサーバーが混ざっています。次のどちらかに心当たりがあるなら、そのままにできます。

• 複数のDNS事業者をあえて併用して、片方が止まっても名前を引けるようにしている
• DNS事業者を移している最中で、切り替えのあいだ両方を登録している

ただし、どちらの場合も条件があります。両方の事業者のサーバーが、同じ内容を返している必要があります。ステップ 2/4 で行6と同じ形（全部のサーバーが権威の応答で、同じ集合を返す）になっていることを確かめてください。行2になっているなら、併用も移行も成立していません。さらに、レコードを追加するときは両方の画面へ同じものを入れることになります。

移行の途中なら、切り替えが済んだ時点で使わないほうを外します。

どちらにも心当たりが無いなら、レコードを追加した画面によって、届く問い合わせがあったりなかったりします。片方の事業者にしか入っていないレコードは、問い合わせがそちらのサーバーへ届いたときだけ返ります。ステップ 4/4 へ進んでください。

診断結果に出る「ネームサーバーが複数の事業者にまたがっています」は、この状態を見つけたという表示です。意図して併用しているなら、変更は要りません。

ステップ 4/4：残す集合を決めて委任を置き換えてください

4-1 待つあいだに何が起きるか

委任を書き換えても他の人が使っているDNSリゾルバは、古い委任をしばらく覚えています。キャッシュに残る長さの上限が、ステップ 1/4 で控えたTTLです。

TTLは、そのレコードをもう一度問い合わせ直すまでのあいだキャッシュしてよい時間として定められています（RFC 1035 セクション3.2.1）。控えた秒数から次のように読めます。

これは上限です。必ずこの時間かかるという意味ではありません。RFC 2181 セクション8 は次のように書いています。

The TTL specifies a maximum time to live, not a mandatory time to live.

キャッシュはリゾルバごとに数え始めるので、全員が同時に切り替わるわけでもありません。キャッシュ側の仕組みは DNSが反映されないときで扱っています。

この表が示すのはキャッシュに古い委任が残る長さだけです。レジストラでの変更の手続きが終わっていなければ、そもそも委任が変わりません。切り替わったかどうかは、待つのではなく 1-3 をもう一度実行して確かめてください。

4-2 どちらを残すか決めてください

残すのはいま使いたいレコードが実際に入っているほうです。確かめ方は、それぞれの事業者のネームサーバーへ直接、必要なレコードを聞くことです。ステップ 2/4 と同じ形で種類を替えるだけです。

$ dig +norecurse +noall +comments +answer A example.com @<候補のネームサーバー>
$ dig +norecurse +noall +comments +answer MX example.com @<候補のネームサーバー>
$ dig +norecurse +noall +comments +answer TXT example.com @<候補のネームサーバー>

Windowsでは -type= の値を替えます。

> nslookup -norecurse -type=A example.com <候補のネームサーバー>
> nslookup -norecurse -type=MX example.com <候補のネームサーバー>
> nslookup -norecurse -type=TXT example.com <候補のネームサーバー>

ステップ 2/4 で Query refused が返ったサーバー、権威の応答にならなかったサーバー、何度試しても返らなかったサーバーは、残す集合から外します。

残す側に設定するネームサーバーの値は、その事業者が案内しているものを使ってください。診断はこの値を生成しません。事業者ごとの画面の場所は設定ガイドにまとめてあります。

4-3 外す前に確かめる3つ

外した側にしか無いレコードは、外した時点で引けなくなります。次を先に確かめてください。

1. 残す側の全部のサーバーが、権威の応答で同じ内容を返すこと。ステップ 2/4 の形で1台ずつ聞きます
2. 残す側に、必要なレコードが入っていること。まだ入れていないなら、外す前に入れます
3. DNSSECを使っているなら、DSレコードの扱いを先に決めること

2つ目の確かめ方から書きます。確実なのは外す側の管理画面でゾーンの内容を書き出し、残す側の内容と1行ずつ見比べることです。書き出せないなら、外す側の画面に並んでいるレコードを1件ずつ、4-2 の形で残す側へ問い合わせます。A と MX と TXT だけを見ると、CNAME、CAA、SRV、TLSA、DKIMのセレクタ、ワイルドカード、委任しているサブドメインが漏れます。

Windowsの nslookup には、種類として受け付けてもらえないものがあります。2026年9月1日にWindows Server 2022（ja-JP）で確かめた結果です。

指定できなかった種類は unknown query type: CAA のような行が出て、代わりに既定のAレコードとAAAAレコードを引いた結果が返ります。一覧の部分だけを読むとそのレコードがあるように見えてしまいます。この3種類は、外す側の管理画面の一覧で確かめるか、事業者へ問い合わせてください。

3つ目について補足します。RFC 6781 セクション4.3.5 は、DNSSECを使っているゾーンでDNS事業者を移す場合について、いまの事業者が協力する場合と協力しない場合の2つに分けて書いています。協力しない場合について、RFC 6781 セクション4.3.5.2 は次のように書いています。

The only viable operation for the registrant is to have his zone go Insecure for the duration of the change.

続けて同じ節は、上位のゾーンの側からDSを消してもらい、委任を新しい側へ変え、それが行き渡ってから新しい側のDSを入れる、という順を挙げています。協力する場合の方法は同じ節の1つ前（RFC 6781 セクション4.3.5.1）にあります。残す側と外す側の両方の事業者に、DSレコードをどう扱うかを確認してください。

DSレコードがあるかどうかは、上位のゾーンのサーバーへ聞けば分かります。

$ dig +norecurse +noall +answer +authority DS jprs.co.jp @a.dns.jp
jprs.co.jp.		7200	IN	DS	63574 8 2 5D5518EC26E3D8EED9411BA2373A0B9DB7014A54CF5440BC0AA0468A F943973B

DSが無いドメインでは、次のようにSOAだけが返ります。

$ dig +norecurse +noall +comments +answer +authority DS sitekensa.com @a.gtld-servers.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41169
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1788247850 1800 900 604800 900

Windowsの nslookup ではこの確認ができませんでした。2026年9月1日にWindows Server 2022（ja-JP）で確かめたところ、-type=DS は種類として解釈されず、unknown query type: DS を表示したうえで既定のAレコードを引いた結果を返しました。表示だけ見るとDSがあるように読めてしまいます。Windowsだけで作業しているなら、ドメインの管理画面のDNSSECの設定欄を見るか、事業者へ問い合わせてください。

4-4 手を入れる場所

直す場所は、どちらの側を変えるかで決まります。

上位のゾーンにある委任を変えるなら、残すほうの事業者が案内している値に置き換えます。1台だけを外すこともあります。集合をまるごと入れ替えることもあります。ドメイン自身の側は、事業者が割り当てた値に従う形になっていて編集できないことがあります。編集できない場合は、その事業者の窓口へ問い合わせてください。

行2（サーバーどうしで集合が違う）に当たったなら、直すのはDNSの管理画面の側です。同じゾーンを持つはずのサーバーが違う内容を返しているので、その事業者へ問い合わせてください。

ステップ 2/4 で答えを返さなかったサーバー、または権威の応答にならなかったサーバーがあった場合の直し方は2つです。委任からその名前を外すか、その事業者にそのゾーンを持たせるかです。どちらにするかは、その事業者へ問い合わせて決めてください。名前を外す場合は、残る名前が1つ以上あることを先に確かめます。

変更したら、ステップ 1/4 と 2/4 をもう一度実行して、行6の形になったことを確かめます。他の人からどう見えるかは、4-1 のぶんだけ遅れます。

元に戻すとき

戻す判断は、変更のあとにサイトかメールが止まったときです。名前が引けなくなったり、メールが届かなくなったりします。キャッシュの残り時間は人によって違うので、変更の直後ではなくしばらく経ってから出ることがあります。

戻すのはステップ 1/4 と 2/4 で控えた一覧です。変更前の名前をそのまま書き戻してください。ネームサーバーと同時にレコードも変えていたなら、変えた単位で戻すかどうかを決めます。ネームサーバーだけを戻して直らないなら、レコードの側の変更も見てください。

戻せなくなることがあります。外した側の契約を解約した場合、ゾーンを削除した場合、外した側のログイン情報が分からなくなった場合です。解約と削除は、行6の形になり、必要なレコードが残す側で全部引けることを確かめたあとにしてください。

戻したあと、他の人から見えるようになるまでにかかる時間は、そのときのキャッシュの残り方によって変わります。

サブドメインを診断したとき

mail.example.com のような、自分のネームサーバーを持たないサブドメインを診断すると「DNSの設定は ○○ 側で行います」と出ます。正常な状態です。委任されていないサブドメインは、自分のNSレコードを持ちません。レコードの追加や変更は、そのサブドメインを含むゾーンのDNSの管理画面で行います。

そのゾーンがどこかは、名前を1つずつ上へたどると分かります。www.shop.example.com を診断したなら、まず shop.example.com について、ステップ 1/4 の形で委任を聞きます。返らなければ example.com で同じことをします。委任が返ってきた最初の名前が、そのゾーンの頂点です。shop.example.com が別に委任されているなら、レコードはそちらの画面で追加します。

1-4 節で「名前はあるがNSレコードが無い」という答えが返った場合も、この状態にあたります。

この記事の手順で分からないこと

この診断が出す「ネームサーバーが複数の事業者にまたがっています」は、判別できる事業者の名前が2社以上当たったときに出ます。名前から事業者を判別できないネームサーバーが混ざっている場合は、この表示になりません。表示が出ていないことは、混ざっていないことの証明にはなりません。ステップ 3/4 の判定表で、事業者の案内と突き合わせてください。

この手順で見るのはNSレコードだけです。グルーレコードの内容、ゾーンの全レコードが揃っているか、DNSSECの署名が正しいかは、この範囲の外です。

まとめ

ネームサーバーの一覧は2か所にあります。1つは上位のゾーンにある委任、もう1つはドメイン自身のサーバーが返すものです。この2つは別々に設定されるので、片方だけ書き換わることがあります。

両方を直接出し、委任に載っているサーバーへ1台ずつ聞けば、どこが食い違っているかが分かります。手を入れるときは、残す集合のサーバーが権威の応答で同じ内容を返すことを先に確かめてください。外す側にしか無いレコードが残っていないことも確かめます。DNSSECを使っているなら、DSレコードの扱いを事業者に確認してから進めます。

委任が揃ったら、ドメインの診断でSPFやMXなどの設定も確認できます。