権威ネームサーバー（Authoritative Name Server）
概要
権威ネームサーバー（Authoritative Name Server） は、特定のドメインゾーンの DNS レコードを直接管理し、そのドメインに関する問い合わせに対して最終的な回答を返す DNS サーバーです。RFC 1035 で定義された DNS アーキテクチャにおける「正式な情報源」であり、キャッシュを参照せず自身のゾーンデータから回答します。
権威ネームサーバーと対をなすのが再帰リゾルバーです。再帰リゾルバーはクライアントの代わりに問い合わせを代行し、複数のネームサーバーに順番に問い合わせてキャッシュに記録します。権威ネームサーバーはその問い合わせの最終目的地として、自身が管理するゾーンデータから正確な回答を返します。
仕組み
権威ネームサーバーは DNS の階層的な委任構造の中で、ゾーンデータの正式な情報源として機能します。
DNS 解決の全体フロー
ブラウザーが example.com にアクセスしたとき、次の流れで名前解決が行われます。
- OS のスタブリゾルバーが再帰リゾルバー（通常は ISP や Google の
8.8.8.8）に問い合わせる - 再帰リゾルバーがルートネームサーバー（
.）に問い合わせる - ルートネームサーバーが
.comTLD ネームサーバーのアドレスを返す - 再帰リゾルバーが
.comTLD ネームサーバーに問い合わせる - TLD ネームサーバーが
example.comの権威ネームサーバーのアドレスを返す - 再帰リゾルバーが権威ネームサーバーに
example.comの A レコードを問い合わせる - 権威ネームサーバーが
93.184.216.34を返す
手順 5 で返ってくる「example.com の権威ネームサーバーのアドレス」は NS レコードによって示されます。
NS レコードとの関係
NS レコード（Name Server Record）は、そのドメインの権威ネームサーバーのホスト名を指定します。example.com の NS レコードが ns1.cloudflare.com を指していれば、example.com の権威ネームサーバーは Cloudflare のサーバーです。
example.com. IN NS ns1.cloudflare.com.
example.com. IN NS ns2.cloudflare.com.NS レコードは通常 2 本以上設定します。プライマリが応答しない場合、セカンダリが問い合わせを処理することで可用性を高めます。大規模なサービスでは 4〜6 本の NS レコードを設定していることもあります。
委任の仕組み
DNS は階層的な委任構造を持ちます。レジストラ（例: お名前.com）でドメインを取得すると、レジストラがレジストリ（.com を管理する Verisign）に対して「このドメインの権威ネームサーバーはこれだ」という NS レコードを登録します。これを 委任（delegation） と呼びます。
委任を変更するにはレジストラの管理画面でネームサーバーを更新する操作が必要です。DNS プロバイダーを Cloudflare に移行する場合も、この委任の更新が伴います。委任の変更は TLD ネームサーバーへの伝播に数時間かかることがあります。
プライマリとセカンダリ
権威ネームサーバーはプライマリとセカンダリに分かれます。プライマリは DNS レコードの変更を受け付ける書き込み元です。セカンダリはプライマリからゾーンデータを転送（ゾーン転送、AXFR）して同期します。ただし、Cloudflare、AWS Route 53、Google Cloud DNS のような現代のクラウド型 DNS サービスでは、この区別が内部的に抽象化されており、ユーザーは意識する必要がありません。
再帰リゾルバーとの違い
再帰リゾルバーは問い合わせを代行して結果をキャッシュする「仲介者」です。クライアントから見ると再帰リゾルバーが答えを返しているように見えますが、最終的な情報源は権威ネームサーバーです。
| 項目 | 権威ネームサーバー | 再帰リゾルバー |
|---|---|---|
| データの出所 | 自身のゾーンデータ | 他のサーバーへの問い合わせ結果 |
| キャッシュ | 使わない | 使う（TTL まで保持） |
| 担当範囲 | 特定のゾーン | 任意のドメイン |
| 例 | Cloudflare、Route 53 | 8.8.8.8（Google）、1.1.1.1（Cloudflare） |
確認方法
dig で権威ネームサーバーとその NS レコードを確認するには次のコマンドを使います。
dig NS example.com;; ANSWER SECTION:
example.com. 172800 IN NS ns1.cloudflare.com.
example.com. 172800 IN NS ns2.cloudflare.com.NS レコードの TTL は長め（172800 秒 = 48 時間）に設定されることが多く、変更の伝播に時間がかかります。
委任の経路をルートから全てトレースしたい場合は +trace を使います。
dig A example.com +traceルートネームサーバー → TLD ネームサーバー → 権威ネームサーバーの順に委任が辿られ、各ステップの応答が表示されます。
+norec オプションで再帰を無効にすると、権威ネームサーバーに直接問い合わせることができます。再帰リゾルバーのキャッシュを介さないため、最新のゾーンデータを確認できます。
dig A example.com @ns1.cloudflare.com +norec応答ヘッダーの flags: に aa（Authoritative Answer）フラグが立っていれば、権威ネームサーバーから直接回答を受け取っています。
;; flags: qr aa rd; QUERY: 1, ANSWER: 1SOA（Start of Authority）レコードの MNAME フィールドもプライマリネームサーバーを示します。
dig SOA example.com;; ANSWER SECTION:
example.com. 3600 IN SOA ns1.cloudflare.com. dns.cloudflare.com. (
2024010101 ; SERIAL
10000 ; REFRESH
2400 ; RETRY
604800 ; EXPIRE
3600 ; MINIMUM
)外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=NS"レスポンスの records.NS に権威ネームサーバーのホスト名が配列で返ります。
{
"success": true,
"data": {
"domain": "example.com",
"records": {
"NS": [
"ns1.cloudflare.com",
"ns2.cloudflare.com"
]
}
},
"error": null,
"meta": { "responseTime": 52 }
}dig と Labee API の結果が一致しない場合、再帰リゾルバーのキャッシュに古い NS レコードが残っている可能性があります。NS レコードの TTL（多くの場合 24〜48 時間）が切れるまで古いサーバーへの問い合わせが続きます。
よくある問題
権威ネームサーバーの運用で頻出するトラブルと対処法を整理します。
ネームサーバーを変更したが一部のユーザーに反映されない
NS レコードの TTL は長めに設定されていることが多く、古いレコードが再帰リゾルバーにキャッシュされているためです。変更後 24〜48 時間は新旧両方のネームサーバーが同じ応答を返せるように、移行期間中はレコードを並行して維持してください。
SOA の SERIAL を更新し忘れてゾーン転送が行われない
プライマリからセカンダリへのゾーン転送は SERIAL の増加を検知してトリガーされます。SERIAL を更新せずにレコードを変更すると、セカンダリが変更を認識せず古いデータを配信し続けます。ゾーンファイルを直接編集する場合は SERIAL の更新を必ず行ってください。クラウド型 DNS サービスでは自動で管理されます。
DNS プロバイダーを移行したのに古いネームサーバーに問い合わせが届く
レジストラの管理画面での NS 変更は、TLD ネームサーバーへの反映に数時間かかります。また、古い NS レコードが TTL まで再帰リゾルバーにキャッシュされているため、移行完了まで 48 時間程度見ておく必要があります。移行前に新旧両方のネームサーバーで同じレコードを配信することで、ユーザーへの影響を最小化できます。
権威ネームサーバーが 1 本しか設定されていない
NS レコードが 1 本だけの場合、そのサーバーが停止するとドメインの名前解決が全て失敗します。冗長性のために最低 2 本の NS レコードを設定し、それぞれ独立したネットワーク上に置くことが推奨されます。多くのレジストラは NS レコードが 2 本以上ないとドメイン登録を受け付けません。