ネームサーバーとは、DNS（Domain Name System）でドメイン名に関する問い合わせへ応答するサーバーです。特にドメイン管理画面で「ネームサーバー」と呼ばれるものは、そのドメインの正式なDNS情報を保持・提供する権威ネームサーバー（権威DNSサーバー）を指すことが一般的です。
ただし、技術的には「ネームサーバー」「DNSサーバー」という言葉の使い方には幅があり、利用者の代わりにDNS情報を探す再帰リゾルバーもDNSサーバーやネームサーバーと呼ばれることがあります。したがって「ネームサーバーとDNSサーバーは別の装置」と単純に断定するのは正確ではありません。
本記事では、権威DNSとリゾルバーの役割、NSレコードが示す委任先、現在のネームサーバーを確認する方法に絞って解説します。Windowsの nslookup・Resolve-DnsName、macOSやLinuxの dig を使った読み取り専用の確認例も掲載します。実際にネームサーバーを変更する操作や、DNS障害の復旧作業は扱いません。DNSそのものの仕組みを最初から知りたい場合は「DNSとは？」の基礎記事、A・MXなどの用途を比較したい場合はDNSレコードの種類と役割をご覧ください。
ネームサーバーとは？最初に役割を理解する
ネームサーバーはDNSの問い合わせに応答する仕組みの一部です。ドメインを運営する側が設定する権威ネームサーバーと、利用者が問い合わせに使うリゾルバーでは、扱うデータと役割が異なります。
ドメイン管理画面でいうネームサーバーは通常「権威DNS」
例えばドメイン登録事業者の管理画面に「ネームサーバー1」「ネームサーバー2」と表示されている場合、そのドメインのDNS情報を管理する権威サーバーのホスト名を指定する欄であることが一般的です。例として、ns1.example.net と ns2.example.net のような名前が並ぶイメージです。
これらは説明用の架空のホスト名です。実際の管理画面では、契約先のDNSサービスから割り当てられた正式なネームサーバー名を確認します。名前に ns が含まれなくても権威サーバーである場合があります。
権威ネームサーバーは担当ゾーンの正式な情報に答える
権威ネームサーバーは、管理を任されたDNSゾーンのA、AAAA、MX、TXTなどのレコード情報を保持し、そのゾーンに関する問い合わせへ権威のある回答を返します。Webサーバーそのものではなく、Webサーバーなどへの接続先を見つけるための情報を提供する役割です。
例えば example.com の権威DNSを管理するサービスが www.example.com の接続先を公開している場合、再帰リゾルバーは権威DNSから回答を取得できます。権威サーバーがWebページのHTMLや画像を送るわけではありません。
再帰リゾルバーは利用者の代わりに回答を探す
再帰リゾルバー（Recursive Resolver）は、パソコンやブラウザから問い合わせを受け取り、必要なDNSサーバーを調べて回答を返す役割です。以前に得た結果をキャッシュしていれば、その情報から回答する場合もあります。
利用者が家庭のネットワークで使うDNSサーバー、会社のネットワークで指定されるDNSサーバー、公共DNSサービスなどは、通常この役割に相当します。特定ドメインのDNSレコードを管理する権威DNSとは、管理目的が異なります。
DNSサーバーとネームサーバーは何が違う？
「DNSサーバー」と「ネームサーバー」は、日常的には同じ意味で使われることがあります。違いを理解するときは言葉の名称よりも、権威DNSとして回答するのか、リゾルバーとして回答を探すのかを確認する方が正確です。
技術的には同じ言葉で呼ばれることがある
DNS用語を整理したIETFのRFC 9499では、「DNS server」「name server」は文脈によって指す機能を判断する必要があり、権威サーバーと再帰リゾルバーの両方に使われると説明されています。サーバー製品によっては、一つのソフトウェアが複数の機能を備える場合もあります。
したがって「ネームサーバー＝権威DNS」「DNSサーバー＝再帰リゾルバー」と絶対的に定義するのではなく、ドメイン管理画面でのネームサーバー指定は権威DNSを示すことが多いと理解するのが適切です。
権威DNSとリゾルバーの比較表
初心者が混同しやすい二つの役割を、問い合わせ相手・保有する情報・管理主体から比較します。サービスによって呼び名は違っても、どちらが誰のために動いているかを見れば区別できます。
| 比較項目 | 権威DNS（ネームサーバー） | 再帰リゾルバー |
|---|---|---|
| 主な役割 | 担当ドメインの正式なDNS情報を提供 | 利用者に代わり必要なDNS情報を取得 |
| 主な利用場面 | ドメインのDNS管理・委任 | ブラウザや端末の名前解決 |
| 回答の元 | 管理しているDNSゾーンのデータ | 権威DNSなどへの問い合わせやキャッシュ |
| 管理主体の例 | DNSホスティング・ドメイン管理事業者 | 通信事業者・組織・公共DNS |
| 確認するもの | NSレコード・担当ゾーン | 端末のDNS設定・問い合わせ結果 |
ここで「権威DNSが原本を持つ」といっても、DNSサービスの内部構成は複数サーバーでデータを同期する場合があります。一台のサーバーにすべてのドメイン情報があるという意味ではありません。
Google Public DNSなどは通常リゾルバー側
例えば公共DNSの 8.8.8.8 や 1.1.1.1 は、利用者向けに名前解決を提供するリゾルバーとして知られています。これらをPCで使う設定と、自分が管理するドメインの権威ネームサーバーを登録する設定は別です。
「パソコンのDNS設定を変更すること」と「ドメインのネームサーバーを変更すること」は、対象も影響範囲も違います。この記事では違いの理解までにとどめ、設定変更は別の記事で扱います。
NSレコードとは？「担当ネームサーバー」を知らせる情報
NS（Name Server）レコードは、そのDNSゾーンや委任された名前空間を扱うネームサーバーの名前を示すレコードです。名前解決の過程で「次にどのサーバーへ問い合わせるか」を知るために重要な情報になります。
NSレコードの値はネームサーバーのホスト名
NSレコードには、権威ネームサーバーの名前を指定します。例えば説明用の example.com について、架空の権威サーバーを ns1.example.net. と ns2.example.net. とする場合のイメージです。IPアドレスそのものをNSの値に書く形式ではありません。
NSが指す名前のIPアドレスを調べるため、別のA・AAAAの情報が必要になることがあります。DNSの上位ゾーンが委任先へ到達するために必要なアドレス情報を提供する仕組みには「グルーレコード（glue）」がありますが、すべてのNS設定に同じ形のglueが必要というわけではありません。
NSレコードの読み取り例
次はDNSのゾーン情報をイメージするために作成した説明用の架空例です。実際の example.com の現在の設定を示すものではなく、実行用の設定ファイルでもありません。
example.com. 3600 IN NS ns1.example.net.
example.com. 3600 IN NS ns2.example.net.左から対象の名前、TTL、クラス IN、レコード種類 NS、ネームサーバーのホスト名を表します。最後のドットは完全修飾ドメイン名の表記です。実際のドメインで有効なNSを確認するときは、管理画面や次の章のDNS問い合わせを使います。
上位ゾーンの「委任」と担当ゾーン内のNSを区別する
例えば example.com では、上位にある .com のDNS側が「example.com はどのネームサーバーに問い合わせるか」という委任情報を持ちます。一方、example.com 側のゾーンにも権威ネームサーバーを表すNSレコードがあります。
これらは正しく対応していることが望まれますが、管理画面の変更途中などで結果が一致しない場合があります。特に「現在、インターネット上でどこへ委任されているか」を確かめるときは、キャッシュ済みのNS回答だけで判断せず、上位ゾーンの委任情報を確認する必要があります。
名前解決でネームサーバーはどの順番に登場する？
利用者がURLを入力してからDNSの回答を得るまでに、端末・リゾルバー・ルートDNS・TLDのDNS・権威DNSが関わることがあります。ただし、DNSリゾルバーにキャッシュが残っていれば、毎回すべてをたどるわけではありません。
①利用者の端末から再帰リゾルバーへ問い合わせる
ブラウザで www.example.com を開こうとすると、端末は必要な接続先を調べます。キャッシュなどで答えが得られなければ、設定されたリゾルバーに問い合わせます。
利用者から見えるDNSサーバーの設定値は通常、ここで使う再帰リゾルバーを表します。ドメイン管理画面に指定された権威ネームサーバーの名前と同じである必要はありません。
②リゾルバーがルートとTLDの委任情報をたどる
必要な情報がキャッシュにない場合、リゾルバーはルートDNS、.com などのTLDを扱うDNSサーバーを通じ、対象ドメインの権威サーバーを探します。ルートDNSは個々のサイトのHTMLを保持するのではなく、次の階層をたどるための情報を返します。
このとき重要になるのがNSレコードなどの委任情報です。「example.com はこのネームサーバーが担当する」という情報を手掛かりに、次に問い合わせる先を決めます。
③権威ネームサーバーが対象のDNS情報を返す
リゾルバーが権威DNSへ到達すると、対象の名前に関するDNSレコードを取得します。Webサイトへの接続に必要な情報ならA・AAAAなどが関係します。宛先にCNAMEが使われていれば、別名をたどって必要なアドレス情報を取得する場合もあります。
権威DNSは、自分の担当するゾーンについて回答する役割であり、全世界のDNS名を代わりに探す役割ではありません。再帰的な問い合わせを行うリゾルバーと区別しましょう。
④リゾルバーが端末へ結果を返しWeb接続へ進む
リゾルバーは取得した回答を端末へ返します。ブラウザは必要なアドレス情報を利用してWebサーバーやCDNへ接続し、HTTPSの場合はTLS通信の確認を経てページを取得します。ネームサーバー自体がWebページの描画まで担当するわけではありません。
詳しいWebページ表示までの流れはDNSの全体像の記事で扱い、ここでは問い合わせ先の選び方と権威DNSの役割に注目しています。
今使っているネームサーバーを確認する3つの方法
現在のネームサーバーを確認するときは、管理画面に登録された名前、DNS問い合わせで返るNS、上位ゾーンから見た委任先を区別してください。情報が一致するかを確認することで、誰がDNSを管理しているか判断しやすくなります。
方法1：ドメイン登録事業者の管理画面で確認する
ドメインを契約している事業者の管理画面では、「ネームサーバー設定」「DNSサーバー」「委任先」などの項目から、現在登録されているネームサーバー名を確認できる場合があります。表示名称は事業者によって異なります。
ここで確認したいのは、実際に設定されているネームサーバーのホスト名と、その設定を管理するアカウントです。確認だけなら設定値を変更する必要はありません。誤って保存や変更を行わないよう、対象ドメイン名を確認してから画面を開きましょう。
登録事業者とDNSホスティング事業者が別のケースもあります。管理画面に表示された会社名だけで「この会社がWebサーバーも管理している」とは判断しないでください。
方法2：Windows・macOS・LinuxのDNSコマンドで確認する
管理画面へログインできなくても、公開されているNS情報をDNS問い合わせで取得できます。Windowsなら nslookup やPowerShellの Resolve-DnsName、macOSやLinuxなら dig などを利用できます。コマンド例は次の章で紹介します。
DNS問い合わせから得られる結果は、指定したリゾルバーのキャッシュや問い合わせ先により異なる場合があります。特に移行途中は、管理画面の設定と一時的に異なる情報が返ることがあります。
方法3：上位ゾーンの委任情報を追跡して確認する
「どの権威ネームサーバーへ委任されているのか」をより直接的に確かめるには、ルートからTLDへと委任先をたどる方法があります。dig +trace はその過程を表示できるため、管理画面とDNS問い合わせの結果が食い違う場合に役立ちます。
ただし追跡できたからといって、各権威DNSが正常に回答し、WebサイトのHTTPSまで正常であることを一度に保証するものではありません。用途は委任情報の確認であり、障害復旧の詳細は別記事に分けます。
Windowsでネームサーバーを確認する手順
Windowsからは、標準で利用できることが多い nslookup と、PowerShellの Resolve-DnsName を使う方法があります。どちらもDNSへ問い合わせて結果を表示する読み取り操作です。ここで示す例は設定変更を行いません。
コマンドプロンプトでnslookupを実行する
まずコマンドプロンプトを開き、次のコマンドを入力します。example.com は説明用のドメインなので、確認したいドメイン名へ置き換えてください。
nslookup -type=NS example.com出力には、問い合わせに使ったDNSサーバーと、対象ドメインのNSレコードに関する回答が表示されます。ネームサーバー名が複数表示される場合もあります。表示された値を、ドメイン管理画面の設定と照合してください。
nslookup の出力にある Server や Address は、コマンドが問い合わせたDNSサーバーの情報であり、必ずしも対象ドメインの権威ネームサーバーではありません。NSの回答部分と混同しないことが重要です。
PowerShellでResolve-DnsNameを実行する
Windows PowerShellには、DNSへ問い合わせる Resolve-DnsName コマンドレットがあります。DNSClientモジュールを利用できる環境では、次のようにNSレコードを指定できます。
Resolve-DnsName -Name example.com -Type NS通常は応答に名前、種類、TTL、ネームサーバー名などの情報が表示されます。実際の表示形式はWindowsやPowerShellの環境で異なる場合があります。このコマンドはマイクロソフトのResolve-DnsName公式資料にあるNS問い合わせ方式に基づきます。
「問い合わせ先DNS」と「確認されたNS」を区別する
Windowsのネットワーク設定にDNSサーバーのIPアドレスが表示されていても、それは通常そのPCが名前解決に使うリゾルバーです。nslookup -type=NS で得たドメインのNSレコードは、そのドメインの権威サーバーに関係する情報です。
「WindowsでDNSサーバーが設定されているから、自社ドメインもそこで管理している」という判断は誤りです。どちらの役割を調べているかを区別してください。
macOS・Linuxでdigを使ってNSレコードを確認する
macOSやLinuxなど、dig を利用できる環境では、対象ドメインのNS情報を短く表示できます。コマンドがインストールされているかは環境によって異なるため、使えない場合はDNS管理画面やほかの確認方法を利用してください。
dig +short NSでレコードの値を表示する
最初に、通常のDNSリゾルバー経由でNSレコードを問い合わせる例です。結果を簡潔に表示します。
dig +short NS example.comNSが存在する場合は、ネームサーバー名が複数行で返されることがあります。順序に優先順位があるという意味ではありません。DNSの設定や利用環境によって、返る名前と行数は異なります。
dig +traceでルートから委任先を追う
ドメインの委任先を追跡する場合は、次のように +trace を使えます。このコマンドもDNSへの問い合わせを行う読み取り操作で、ドメインの設定を変更しません。
dig +trace example.com NS出力はルートDNSやTLDのネームサーバー、対象ゾーンからの回答など複数段階に分かれます。重要なのは、上位ゾーンが対象ドメインをどの権威サーバーへ委任しているかを確認することです。上位ゾーンの応答と対象ゾーン自身のNSレコードの回答が同じとは限らないため、それぞれ区別して読みます。
ISCのdig +traceの公式解説は、通常の問い合わせが設定済みリゾルバーを利用するのに対し、+trace はルートから委任先をたどって問い合わせることを説明しています。追跡にも環境によっては初期のDNS解決などが必要です。
複数の確認結果が違う場合に見る箇所
通常の dig NS と dig +trace、ドメイン登録事業者の管理画面で結果が違う場合、キャッシュが残っている可能性や、委任情報の反映状態、親ゾーンと子ゾーンのNSの不一致などを確認する必要があります。違いがあるという事実だけで、どちらかのサービスが故障していると断定しないでください。
Cloudflareの公式トラブルシューティングでも、管理画面に表示される設定と親ゾーンが実際に返す委任情報を区別して確認する方法が示されています。本記事は確認までとし、変更による修復は取り上げません。
親ゾーンと子ゾーンのネームサーバー情報が違う理由
ネームサーバーを確認していると、「管理画面に登録されている値」と「権威DNS側で公開されるNS」と「手元のリゾルバーが返すNS」が一致しない場合があります。これは参照している情報の場所が違う可能性があるためです。
親ゾーンには子ドメインへの委任情報がある
例えば example.com の親に相当する .com のDNSには、example.com を担当する権威ネームサーバーへの委任情報があります。リゾルバーはその情報を使って、次に問い合わせるべきサーバーを知ります。
この上位ゾーン側のNSが、実際の名前解決でどこをたどるかを決める重要な手掛かりです。ドメイン登録事業者の管理画面で設定した内容が、最終的に親ゾーンへ反映される必要があります。
子ゾーン自身にもNSレコードがある
一方、example.com のDNSゾーン自身にもNS情報があります。上位から委任されたサーバーと、ゾーン内のNSが食い違う構成では、複数の問い合わせ経路やキャッシュ状態によって回答が異なる可能性があります。
両者が違うことに気付いても、即座にNSレコードを削除したりネームサーバーの設定を変更したりするのは適切ではありません。まずどの情報をどこから取得したのかを整理し、権威DNSを管理する担当者へ確認しましょう。
キャッシュの影響はNSにも及ぶ
DNSリゾルバーは取得したレコードを一定期間キャッシュすることがあります。NSレコードや委任先に関係する情報もキャッシュの影響を受けるため、管理画面で値を変更した直後は以前の情報が返る場合があります。
ただし、反映待ちが原因かどうかは実際の問い合わせ結果と管理状態から判断すべきです。特定の時間待てば必ず直ると断定せず、公式の管理画面と公開DNSの確認結果を照合してください。
ネームサーバーが複数あるのはなぜ？
ドメイン管理画面で「ネームサーバー1」「ネームサーバー2」など複数の欄が用意されているのは、複数の権威サーバーでDNS情報を提供するためです。これは単純に表示順で優先順位を決める設定とは異なります。
複数の権威サーバーが同じゾーンの情報を提供する
例えば2台以上の権威ネームサーバーが同じドメインのDNS情報を提供していれば、一方へ問い合わせできない状況でも別のサーバーで回答できる可能性があります。大規模DNSサービスでは、複数拠点や任意の地点から利用できる構成が採用される場合があります。
ただし複数台登録しているだけで、全サーバーの情報が正しく同期されているとは限りません。運用上は、委任されたすべての権威サーバーが必要な回答を提供できることが重要です。
「ネームサーバー1が常に先、2が予備」とは限らない
ドメイン管理画面の「1」「2」という番号を、Webサーバーの優先度やメール配送先のMX優先度と混同しないでください。一般的なNSレコードそのものに、MXレコードのような数値の優先度はありません。
リゾルバーは実装や通信状況などに応じて問い合わせ先を選ぶ場合があります。NSの表示順だけで、常に最初のサーバーへアクセスするという意味ではありません。
レコードを複数登録してもWebサーバーの冗長化にはならない
権威DNSの冗長化と、Webサイトのコンテンツを提供するサーバーの冗長化は別の問題です。ネームサーバーが複数あってもWebサーバー自体が停止すれば、サイトの表示ができないことがあります。
反対にWebサーバーが正常でも、必要なDNS情報が取得できない場合には、利用者がドメイン名から接続できなくなる可能性があります。DNSとWebサービスは別の管理対象として考えます。
ドメイン登録会社・DNS事業者・Webサーバーはどう関係する？
ドメイン運用では、レジストラ（ドメイン登録事業者）、権威DNSを運営するDNS事業者、Webサイトを提供するホスティング会社が同じ場合も、別々の場合もあります。「どの会社が何を管理しているか」を区別することが重要です。
ドメイン登録事業者は委任先の設定窓口になる
多くのドメインでは、ドメインの登録事業者や販売代理店の管理画面から、登録済みネームサーバーの名前を確認できます。変更が必要な場合もここが窓口になることがありますが、サブドメインの個別委任では親ゾーンのDNS管理者が担当します。
「ネームサーバーをどこで確認するか」という問いには、まずドメイン登録の管理場所を確認するのが分かりやすい方法です。ただし、現在の公開委任先は上位DNSの実際の応答でも確認します。
DNSホスティング事業者は権威DNSの情報を管理する
権威DNSを提供するサービスでは、対象ゾーンのA・AAAA・CNAME・MX・TXTなどのレコードを管理します。実際の入力画面や権限はサービスごとに異なります。ドメイン登録先と権威DNS提供者が違っても、正しく委任されていれば運用できる場合があります。
例えばドメインをA社で登録し、権威DNSをB社が提供し、WebサイトをC社へ設置する構成も考えられます。いずれも実在の特定契約を表すものではなく、役割を示す説明例です。
WebサーバーはDNSとは別にページを提供する
Webホスティング会社は、HTMLやアプリケーション、Webサイトのデータを提供するサーバーを運用します。権威DNSが示す接続先とWebサーバーの接続先が一致するように設定されますが、DNSが正しいからといってWebアプリの正常動作まで保証されるわけではありません。
CDNやロードバランサーを使う場合には、DNSがそれらの設備のアドレスを返すこともあります。通信の経路は運用構成によって変わるため、ドメインとDNSとWebサーバーの契約先を別々に記録することを推奨します。
サブドメインのネームサーバーは別にできる？
ドメインの一部を別のDNS事業者や担当者へ委ねる場合、サブドメインを別の権威ネームサーバーへ委任する構成があります。これはDNSの委任の仕組みによるもので、単にCNAMEを設定するのとは役割が異なります。
親ドメインから子のDNSへ委任できる
例えば example.com の中で shop.example.com を独立したDNSゾーンとして管理する場合、親ゾーンにそのサブドメインの委任用NSレコードを用意し、別の権威サーバーへ問い合わせが進む構成があります。
このようなサブドメインの委任は、ドメイン登録事業者の「ルートドメインのネームサーバー変更」とは別の操作である場合があります。Cloudflareの公式資料でも、サブドメインを委任する場合は親ゾーンにNSレコードを設定することを説明しています。
委任とCNAMEによる別名指定は違う
CNAMEはDNS上のある名前が別の名前を参照する関係を表します。一方、NSによる委任は、名前空間の一部をどの権威DNSが管理するかを示します。目的と動作が異なるため、CNAMEとNSを「同じ転送設定」として扱わないでください。
サブドメインを外部サービスへ接続する場合、必要なのがCNAMEなのか、子ゾーンへの委任なのかは提供サービスの正式仕様によって異なります。レコードごとの一般的な役割はDNSレコードの比較記事で整理しています。
変更の必要がない場合は委任先だけ確認する
単にどの事業者が shop.example.com を管理しているか確認したいのであれば、まず親ゾーンの委任情報を調べます。委任がなければ親のDNSゾーンの一部として管理されている構成もあります。
確認結果だけで設定変更を決めず、対象サービスの運営者、親ドメインの管理者、サブドメインの管理者と情報を照合することが重要です。
ネームサーバーの確認でよくある見間違い
ネームサーバーを調べるときは、画面やコマンドの出力が似ているため、異なる種類の情報を同じものとして扱ってしまうことがあります。代表的な見間違いを確認します。
WindowsのDNSサーバー設定を権威DNSと誤認する
Windowsのネットワーク設定に表示されるDNSサーバーのIPアドレスは、通常その端末が利用するリゾルバーです。自社ドメインの権威ネームサーバーとは限りません。ドメインのNSを確認するコマンドを使って区別しましょう。
nslookupのServer表示を対象ドメインのNSと思う
nslookup の先頭付近に表示されるサーバー名とIPアドレスは、問い合わせ先DNSの情報であることが多いです。対象ドメインのネームサーバーを調べる場合は、-type=NS の回答を確認する必要があります。
NSの名前とWebサイトのIPアドレスを同じものと思う
NSの値は権威ネームサーバーのホスト名で、A・AAAAの値はIPアドレスです。NSに表示された名前をブラウザのURLへ入力しても、そのまま管理対象サイトが表示されるとは限りません。
親と子のNSが異なる結果を「どちらかの嘘」と判断する
異なる場所で取得したNSの結果が違う場合は、上位ゾーンの委任情報、担当ゾーン内の情報、キャッシュされた回答など、参照元を分けて記録します。差異は設定途中や構成の不一致を示している可能性がありますが、それだけで理由を確定することはできません。
ネームサーバーが複数あれば必ず障害に強いと考える
同じ情報を適切に提供できる権威サーバーが複数あることは可用性に役立ちます。しかし、複数の名前だけ登録されていても、すべてが正常に応答する保証はありません。DNS管理者は登録情報と稼働状況を別々に把握する必要があります。
ネームサーバーについてよくある質問
初心者の方が迷いやすい用語や、実際の確認作業の疑問を整理します。設定変更やトラブル対応を始める前に、何を調べたいのかを明確にしましょう。
Q．ネームサーバーとは一言で何ですか？
DNSの問い合わせへ応答するサーバーです。ドメイン管理の文脈では、主にそのドメインの正式なDNS情報を提供する権威ネームサーバーを指します。
Q．ネームサーバーとDNSサーバーは同じですか？
文脈によっては同じ意味です。RFC 9499では、どちらの言葉も権威サーバーと再帰リゾルバーに対して使われると説明しています。実務では何の機能を指しているか確認してください。
Q．NSレコードはIPアドレスを登録するものですか？
いいえ。NSレコードは権威ネームサーバーのホスト名を示します。IPv4やIPv6のアドレスを示すA・AAAAとは役割が違います。
Q．ネームサーバーは必ず2つ必要ですか？
DNSゾーンを複数の権威サーバーで提供することは可用性の観点で重要です。DNSの基本仕様RFC 1034はゾーンを複数サーバーで提供することを述べています。ただし契約サービスによる表示数や運用構成は異なるため、利用事業者の正式な条件に従ってください。
Q．ネームサーバーの確認にコマンドは必要ですか？
必須ではありません。ドメイン登録事業者の管理画面でも設定されたネームサーバーを確認できる場合があります。公開DNSのNSレコードや委任経路を確認したい場合に nslookup、Resolve-DnsName、dig が役立ちます。
Q．nslookupで表示されたServerは権威ネームサーバーですか？
通常は、その問い合わせに利用したDNSサーバーです。対象ドメインの権威ネームサーバーを確認するにはNSの回答部分を見てください。両者を混同しないようにします。
Q．ドメインを登録した会社とDNSを管理する会社が違ってもよいですか？
はい。ドメイン登録事業者と権威DNSを提供する事業者は別の場合があります。さらにWebサイトを提供するホスティング会社が別でも、適切に設定されていれば運用できます。
Q．サブドメインだけ別のネームサーバーにできますか？
可能な構成があります。親ゾーンに子ゾーンへの委任を示すNSレコードを設定し、別の権威ネームサーバーに管理を任せます。具体的な設定は利用DNSサービスによって異なります。
Q．設定を変更しなくても現在の委任先を確認できますか？
はい。DNSへの問い合わせは読み取り操作です。dig +trace などでルートからの委任経路を調べたり、ドメイン管理画面の設定値と照合したりできます。
Q．NSの結果が違う場合はすぐ変更すべきですか？
いいえ。キャッシュ、上位ゾーンの委任情報、子ゾーン自身のNS、変更手続きの反映など、複数の要因があります。参照先と結果を分けて記録し、正しい管理担当者へ確認してください。
エンリンクでドメインの管理先を整理する場合
複数のドメインを運営している場合は、ネームサーバーがどこに設定され、誰が管理しているかを把握できることが重要です。エンリンクの公開機能の範囲と、利用者側で確認・変更する作業を区別します。
ドメイン管理会社と管理画面URLをサイト単位で整理
エンリンクの公式機能一覧では、ドメイン管理会社と管理画面のURLをサイト単位で記録する機能を案内しています。複数サイトを管理している場合、契約先や管理画面を探し直す手間を減らせます。
ただしドメイン管理会社の登録と、権威DNSの自動変更・DNSサーバーの運用は異なります。ネームサーバーの設定そのものがエンリンクで自動変更されるという意味ではありません。
DNS診断・Web監視の情報と委任先の管理は異なる
公開機能ページにはDNS診断・セキュリティ確認、HTTP・SSL監視などが案内されています。しかし、全ドメインの親ゾーンの委任先を自動的に突き合わせたり、ネームサーバーの登録値を変更したりする機能まで提供しているとは、確認した公開仕様だけでは断定できません。
本記事の dig・nslookup は一般的なDNS確認方法の解説です。実際の設定変更はドメイン登録事業者や権威DNSサービスの管理者が扱うものとして区別します。
無料プランで最大5サイトを登録できる
確認時点の料金ページでは、無料プランの登録可能サイト数は最大5サイト、定期監視は1日2回と案内されています。これらはすべてのNSレコードを自動検査する頻度や、委任先の即時反映を保証するものではありません。
複数サイトのドメイン契約・管理情報を整理したい場合は、無料登録から始められます。機能と更新作業の範囲を区別してご利用ください。
まとめ：ネームサーバーの役割と現在の委任先を正しく確認
ネームサーバーはDNSの問い合わせに応答するサーバーで、ドメイン管理画面では通常、そのドメインの権威DNSサーバーを指します。利用者に代わって名前解決を行う再帰リゾルバーも「DNSサーバー」と呼ばれるため、言葉の違いよりも誰が正式な情報を持ち、誰が回答を探すのかで理解することが重要です。
NSレコードは権威ネームサーバーの名前を示し、上位ゾーンから子のDNSへ問い合わせ先をたどる委任に関わります。現在のネームサーバーを確認する方法には、ドメイン登録事業者の管理画面、Windowsの nslookup・Resolve-DnsName、macOS・Linuxの dig、委任経路を追う dig +trace があります。
管理画面、親ゾーン、子ゾーン、リゾルバーのキャッシュが異なる情報を返す場合もあるため、表示内容だけで原因を断定したり設定を変更したりしないでください。DNS全体の動作を学びたい方はDNSの仕組み、各レコードの用途を確認したい方はDNSレコード5種類の比較をご参照ください。
エンリンクでは、機能一覧でドメイン管理会社と管理画面URLなどの情報整理を案内しています。複数サイトを管理する場合は料金プランを確認のうえ、無料アカウント登録からご利用いただけます。ネームサーバーの変更を自動代行するという意味ではありません。
参考資料・確認日
ネームサーバー・権威DNS・リゾルバー・委任と確認コマンドは、以下の一次資料で確認しています（確認日：2026年10月26日）。本文の example.com・example.net を用いたNSの例は実在環境の現在の設定ではありません。
- IETF RFC 9499：DNS Terminology — ネームサーバー、権威サーバー、リゾルバーの用語。
- IETF RFC 1034：Domain Names — Concepts and Facilities — NSレコード、ゾーン、階層と委任の仕組み。
- Google Cloud：一般的なDNSの概要 — 権威DNSと再帰リゾルバーの違い。
- Cloudflare：Nameservers — ドメイン管理でのネームサーバーの意味と利用場面。
- Cloudflare：親ゾーンの委任情報を確認する方法 — 管理画面と親ゾーン、dig +traceの確認。
- Microsoft Learn：Resolve-DnsName — WindowsでのNSレコードの問い合わせ。
- ISC：digと+traceの違い — キャッシュ済みNSとの違いと委任の追跡。
