2026年6月13日
2026年6月13日
nslookup と DNSViz の違いと使い分け|ネームサーバー変更時に委任の食い違いを見つける手順
ネームサーバーを変更するときは、nslookup で親ゾーン(TLD)と各ネームサーバーに1台ずつ問い合わせて答えを比べ、最後に DNSViz で委任全体を解析して見落としを拾う、という使い分けが効率的です。nslookup は「このサーバーは何と答えるか」を手元で素早く確かめる道具、DNSViz は親子のゾーンと全ネームサーバーの答えを突き合わせて食い違いを一覧にする道具だからです。この記事では、委任でよく起きる不整合と、それぞれのツールでの見つけ方を、ネームサーバー変更の流れに沿って説明します。
委任でよく起きる不整合
ドメインの名前解決は、親ゾーン(.com や .jp など)に登録された NS をたどって、そのドメインの権威サーバーにたどり着く仕組みです。この「委任」の部分で起きやすい問題は次のとおりです。
- 親ゾーンの NS と、権威サーバー自身が返す NS が食い違っている
- NS に載っているサーバーの一部が、そのゾーンを持っていない(応答しない、拒否する、権威の無い答えを返す)。この状態は lame delegation と呼ばれます
- ネームサーバーがそのドメイン自身の配下にある場合(例:
ns1.example.com)に、親ゾーンに登録するアドレス(グルー)が誤っている、または古い - 複数の権威サーバーで SOA のシリアルが違い、ゾーンの内容がそろっていない
- DNSSEC を使わなくなったのに、親ゾーンに DS が残っている
どれも、ある環境では名前が引けて別の環境では引けない、という分かりにくい症状になりがちです。どのサーバーに当たるかで結果が変わるためです。
nslookup と DNSViz の役割の違い
nslookup は指定した1台のサーバーに問い合わせ、その答えを表示します。Windows・macOS・Linux のどれでも使え、問い合わせ先を自由に変えられるので、「親ゾーンは何と言っているか」「ns1 は何と言っているか」を順番に確かめるのに向いています。ただし、複数の答えを比べて食い違いを見つけるのは人の作業です。
DNSViz は、ルートから対象ドメインまでの委任をたどり、親ゾーンと各権威サーバーに IPv4・IPv6 の両方で問い合わせて結果を突き合わせます。食い違いや応答しないサーバーはエラーや警告として一覧に出るため、人が見落としやすい点を拾えます。一方で、解析は DNSViz のサーバーの位置から行われるため、社内向けの DNS や、外部から到達できないサーバーは対象になりません。
nslookup で1台ずつ確かめる
親ゾーンの登録内容を見る
まず TLD のネームサーバーを調べ、そこに再帰なしで対象ドメインの NS を問い合わせます。対話モードを使うと、設定を保ったまま続けて問い合わせられます。
nslookup
> set type=NS
> com.
> set norecurse
> server a.gtld-servers.net
> example.com
TLD のサーバーは対象ドメインの答えそのものではなく委任先を返すため、結果は「Authoritative answers can be found from:」といった見出しの下に、NS と(グルーがあれば)そのアドレスとして表示されます。表示の細かな形は OS によって異なります。ここに出る NS が、レジストラに登録されている内容です。.jp のドメインなら、jp. の NS を調べて同じように問い合わせます。
各権威サーバーの答えを比べる
次に、親ゾーンに載っていた NS のそれぞれに、同じ質問をします。
nslookup -type=SOA example.com ns1.example.net
nslookup -type=SOA example.com ns2.example.net
nslookup -type=NS example.com ns1.example.net
見るべき点は3つです。1つ目は、回答に「Non-authoritative answer」(日本語版 Windows では「権限のない回答」)が付いていないことです。権威サーバーに直接聞いたのにこの表示が出る、あるいは拒否やタイムアウトになる場合、そのサーバーはゾーンを持っておらず、lame delegation の疑いがあります。2つ目は、SOA のシリアルがすべてのサーバーで同じであることです。3つ目は、権威サーバーが返す NS が親ゾーンの NS と一致していることです。
TTL も見たい場合は、-debug を付けると応答の詳細とともに TTL が表示されます。
公開リゾルバの答えを見る
最後に、利用者の多くが実際に使う公開リゾルバの答えを確認します。
nslookup -type=NS example.com 8.8.8.8
nslookup www.example.com 1.1.1.1
権威サーバーの答えが正しいのに公開リゾルバが古い答えを返す場合は、キャッシュの期限切れ待ちです。
DNSViz で委任全体を確かめる
dnsviz.net でドメイン名を入力して解析すると、ゾーンのつながりを描いた図と、エラー・警告の一覧が表示されます。過去の解析結果が表示されることもあるので、解析日時を確かめ、変更後は解析し直します。画面の構成やボタン名は更新で変わることがあり、ここでの説明は執筆時点(2026年10月現在)の一般的な構成にもとづきます。
委任の確認で注目するのは、エラー・警告の一覧のうち次のような内容です。
- 親ゾーンと子ゾーンで NS の組み合わせが違う
- 一部のネームサーバーが応答しない、または権威を持たない答えを返す
- グルーのアドレスと、ネームサーバー名を引いた結果が違う
- IPv6 で到達できないネームサーバーがある
IPv6 に関する警告は、ネームサーバーに AAAA が登録されているのに IPv6 で応答しない場合によく出ます。AAAA を登録しているなら、そのアドレスで実際に DNS が応答するかを確認します。警告はすぐに名前解決が止まるとは限りませんが、一部の利用者だけ遅い・失敗する原因になり得ます。
DNSSEC を使っているドメインでは、同じ図で DS と DNSKEY の対応も確認できます。使っていないのに DS が残っていると、検証を行うリゾルバで解決に失敗するため、移転の前後では DS の有無も見ておきます。
ネームサーバー変更の流れでの使い分け
作業の流れの中で、どこでどちらを使うかをまとめます。変更作業の前には、現在のゾーンの内容(レコードの一覧)を控えておいてください。
- 新しいネームサーバーにゾーンを用意したら、レジストラで切り替える前に、nslookup で新しいサーバーを直接指定して主要なレコード(A、MX、TXT など)を引きます。ここで漏れがあると、切り替えた瞬間から一部のレコードが消えたように見えます。
- DNSSEC を使っている場合は、DS の扱いを DNS 事業者とレジストラの案内で確認し、手順を決めてから進めます。
- レジストラで NS を変更したら、nslookup で TLD のサーバーに再帰なしで問い合わせ、親ゾーンの NS が新しいものに変わったかを確認します。
- 親ゾーンの変更を確認できたら DNSViz で解析し、親子の NS の一致、全サーバーの応答、グルーに問題がないかを確かめます。
- 旧ネームサーバーのゾーンは、親ゾーンの NS の TTL(.com では2日程度)が過ぎるまで残します。期間が過ぎたら DNSViz で再度解析し、問題がなければ旧サーバーの設定を片付けます。
まとめ
- nslookup は1台ずつの答えを確かめる道具、DNSViz は委任全体の食い違いを一覧にする道具です。
- 権威サーバーに直接聞いて「Non-authoritative answer」や拒否が返るなら、lame delegation を疑います。
- 親ゾーンの NS は、TLD のサーバーに再帰なしで問い合わせると確認できます。
- 切り替え前に新しいサーバーのレコードを nslookup で確かめ、切り替え後に DNSViz で全体を点検します。
- 旧ネームサーバーは、親ゾーンの NS の TTL が過ぎるまで止めずに残します。