2026年6月9日
2026年6月9日
nslookup を使った DNS レコードのトレース手順|Windows でルートから権威サーバーまで委任を1段ずつたどる
nslookup には dig の +trace のような自動トレース機能はありませんが、再帰を止めるオプション -norecurse と問い合わせ先の指定を組み合わせれば、ルートサーバーから権威サーバーまでの委任を手作業でたどれます。この記事では、Windows に標準で入っている nslookup を使い、各段の応答の読み方と、途中で食い違いを見つけたときの判断のしかたを説明します。
手作業でトレースする理由
ふだん nslookup で名前を引くと、答えを返すのは PC に設定されたキャッシュサーバーです。キャッシュサーバーは裏でルート、TLD(.com や .jp など)、ドメインの権威サーバーへと順に問い合わせていますが、その途中で何が返ったかは表示されません。
トレースでは、この道のりを自分で再現します。各段のサーバーに「再帰しなくてよい」と伝えて問い合わせると、サーバーは自分の知っている範囲だけを答えます。ルートサーバーなら「.com はこのサーバーたちに任せている」という委任(referral)を、権威サーバーなら最終的な答えを返します。これを順に追えば、次のような問題を切り分けられます。
- レジストラに登録したネームサーバーが、親ゾーン(TLD)に正しく反映されているか
- 委任先のネームサーバーが、そのドメインの答えを本当に持っているか
- キャッシュサーバーが古い答えを持っているだけなのか、権威サーバーの設定そのものが違うのか
Linux や macOS で dig や doggo が使えるなら自動トレースのほうが手早いですが、手元に Windows しかない場面や、仕組みを理解したいときには、この手作業の方法が役に立ちます。
Windows の nslookup で先に知っておくこと
名前の末尾にドットを付ける
Windows の nslookup は、名前に DNS サフィックス(社内ドメインなど)を自動で付け足して問い合わせることがあります。www.example.com. のように末尾にドットを付けると、その名前そのものだけを問い合わせます。トレースでは毎回付けておくと結果が読みやすくなります。
先頭に出る in-addr.arpa の行と「Server: UnKnown」は無視してよい
nslookup は最初に、問い合わせ先サーバーの IP アドレスを逆引きしてサーバー名を表示しようとします。-norecurse を付けてルートサーバーなどに問い合わせると、この逆引きにも委任の答えが返ってくるため、出力の先頭に in-addr.arpa nameserver = ... のような関係のない行が並び、サーバー名が UnKnown と表示されます。調べたい名前の結果はその後ろ、Server: と Address: の行より下に出ます。
PowerShell の Resolve-DnsName はこの用途に向かない
PowerShell の Resolve-DnsName にも -NoRecursion がありますが、筆者の Windows 11 環境で試したところ、委任の応答に対しては一覧を表示せず「DNS server failure」のエラーになりました。権威サーバーに直接答えを聞く用途には使えますが、段をたどる作業には nslookup のほうが向いています。
手順1:ルートサーバーに聞いて TLD の担当を知る
ルートサーバーは a から m までの13の名前で運用されています。ここでは a.root-servers.net に、調べたい名前をそのまま問い合わせます。
nslookup -norecurse -type=A www.example.com. a.root-servers.net
ルートサーバーは example.com の答えを持っていないので、代わりに .com を担当するサーバーの一覧を返します。Windows の nslookup では、次のように Served by: の下にサーバー名、その IP アドレス、担当するゾーン名が並びます(出力は一部を省略しています)。
Server: UnKnown
Address: 198.41.0.4
Name: www.example.com
Served by:
- a.gtld-servers.net
192.5.6.30
2001:503:a83e::2:30
com
- b.gtld-servers.net
192.33.14.30
2001:503:231d::2:30
com
ここで「Address」の行に答えが出ていないのは正常です。委任が返ってきた、つまり「次はこのサーバーに聞け」という意味です。
手順2:TLD のサーバーに聞いて、ドメインの委任先を確かめる
手順1で出てきたサーバーのどれか1台に、同じ名前を問い合わせます。
nslookup -norecurse -type=A www.example.com. a.gtld-servers.net
今度は Served by: の下に、そのドメインのネームサーバーが並びます。これが親ゾーンに登録されている委任の情報で、レジストラの管理画面で設定したネームサーバーと一致しているべき値です。
トレースで最も大事な確認点はこの段です。DNS 事業者を乗り換えたのにここに旧事業者のネームサーバーが出ているなら、レジストラ側の変更が済んでいないか、反映を待っている途中です。.jp ドメインなら a.dns.jp など、TLD ごとに担当サーバーは異なりますが、手順1の結果に出てきた名前を使えば迷いません。
手順3:権威サーバーに聞いて、最終的な答えを得る
手順2で出てきたネームサーバーに問い合わせます。
nslookup -norecurse -type=A www.example.com. ns1.example.net
権威サーバーが答えを持っていれば、Name: と Address: の組が表示されます。キャッシュサーバー経由のときに出る「権限のない回答」(Non-authoritative answer)の表示が出ないことが、権威サーバー自身の答えである目安です。
委任先のネームサーバーが複数あるときは、すべてに同じ問い合わせをして答えをそろえて比べます。1台だけ値が違う、1台だけ応答しない、といった状態は、事業者側の同期の遅れや設定漏れの手がかりになります。
応答の中身を詳しく見る:-debug
表示が省略されていて判断しにくいときは、-debug を付けると応答のヘッダーと各セクションがそのまま表示されます。
nslookup -debug -norecurse -type=A www.example.com. ns1.example.net
見るべき行は次の3つです。
rcode =の値。NOERRORは正常、NXDOMAINは名前が存在しない、SERVFAILはサーバー側の失敗、REFUSEDは問い合わせを拒否された、を意味します。header flags:にauth. answerが含まれるか。含まれていれば権威ある答えです。委任先として登録されているのに、このフラグが無い答えやREFUSEDを返すサーバーは、そのドメインを預かっていない可能性があります(委任されているのに答えを持たない、lame delegation と呼ばれる状態)。answers =、authority records =、additional =の件数。答えが0件で authority records だけがあれば委任、NOERROR なのに answers が0件なら「名前はあるが、その種別のレコードが無い」状態です。
つまずきやすい場面
CNAME が返ってくる
権威サーバーが A ではなく CNAME(別名)を返した場合、-debug の出力に canonical name = の行が現れ、その先の名前の答えは含まれないことがあります。この場合は別名の先の名前について、手順1からもう一度たどります。別名の先が CDN やメール配信サービスなど別の事業者のゾーンなら、そちらの設定も確認対象になります。
応答が返らない、時間切れになる
DNS request timed out が続く場合は、そのサーバーの停止、通信経路の問題、または手元のネットワークが外部の 53 番ポートへの通信を制限している可能性があります。社内ネットワークでは、外部の DNS サーバーへ直接問い合わせることがファイアウォールで禁止されていることが多いため、別の回線で試すと切り分けられます。
応答が大きすぎる
ルートや TLD に NS を問い合わせると、応答が大きく truncated answer と表示されることがあります。筆者の環境では nslookup が自動で取り直して一覧を表示しましたが、うまくいかないときは -vc を付けて最初から TCP で問い合わせます。
確認が終わったら
権威サーバーが正しい値を返しているのに、ブラウザで古いサイトが表示されるなら、原因はキャッシュです。nslookup www.example.com. 8.8.8.8 のように公開のキャッシュサーバーに通常の問い合わせをして、古い値が残っていないかを見ます。PC 自体のキャッシュは ipconfig /flushdns で消せます。DNS の設定を変更する前には、DNS 事業者の管理画面で現在のレコードを書き出すか控えておき、元に戻せるようにしておくと安心です。
なお、ルートサーバーや TLD のサーバーの名前・アドレスは長く変わっていませんが、変わる可能性はゼロではありません(2026年10月現在)。手順1で返ってきた一覧を、その都度の正しい情報として使ってください。
まとめ
- nslookup に自動トレースはないものの、
-norecurseと問い合わせ先の指定で、ルート → TLD → 権威サーバーと委任を1段ずつたどれます。 - Windows では名前の末尾にドットを付け、先頭の in-addr.arpa の行や「UnKnown」の表示は読み飛ばします。
- 最も大事なのは TLD の段で、ここに出るネームサーバーがレジストラの登録と一致しているかを確かめます。
-debugで rcode、auth. answerのフラグ、各セクションの件数を見れば、委任・正常な答え・存在しない名前・預かっていないサーバーを見分けられます。- 権威サーバーの答えが正しければ、残る原因はキャッシュです。