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 のフラグ、各セクションの件数を見れば、委任・正常な答え・存在しない名前・預かっていないサーバーを見分けられます。
  • 権威サーバーの答えが正しければ、残る原因はキャッシュです。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲