今使っているドメインにネームサーバーを1台（または1つのDNSサービス）追加するには、新しいサーバーがそのゾーンを正しく答えられる状態にしてから、ゾーンの中のNSレコードと、レジストラ（ドメインの登録事業者）に登録しているネームサーバーの両方に追加します。順序を逆にすると、答えられないサーバーに問い合わせが届き、名前解決が遅くなったり失敗したりします。この記事では、冗長化のためにネームサーバーを増やす場面を例に、準備・追加・確認の手順を説明します。
サブドメインを別のネームサーバーへ任せる「委任」のためのNSレコードや、ネームサーバーを丸ごと別のサービスへ入れ替える手順は、目的が違うため別の記事で扱っています。ここでは「今のネームサーバーは残したまま、1台増やす」場合に絞ります。
NSレコードは2か所にある
ドメインのNSレコードは、次の2か所に存在します。
- 親ゾーン（レジストリ）側:
.comや.jpなどのネームサーバーが持つ「このドメインはこのネームサーバーが担当」という情報です。利用者はレジストラの管理画面からネームサーバーを登録し、それがレジストリに伝わります。 - 自分のゾーンの中: ゾーンの頂点（
example.comそのもの）に書くNSレコードです。DNSサービスの管理画面やゾーンファイルで設定します。
キャッシュDNSは、まず親ゾーン側の情報を頼りにネームサーバーを探し、その後ゾーンの中のNSを見ることもあります。2か所の内容がずれていても多くの場合は動きますが、どちらかにしか載っていないサーバーは使われ方が不安定になり、障害時の切り分けも難しくなります。ネームサーバーを追加するときは、2か所をそろえることを目標にします。
追加する前に決めておくこと
最初に、新しいネームサーバーにゾーンの内容をどう持たせるかを決めます。方法は大きく3つあります。
- ゾーン転送（セカンダリ）: 今のネームサーバーをプライマリとし、新しいサーバーがゾーン転送（AXFR・IXFR）で内容を受け取ります。BINDやNSDなど自前のDNSサーバー同士、またはセカンダリ機能を持つDNSサービスで使えます。
- DNSサービスのセカンダリ機能: 外部のDNSサービスの中には、他のプライマリからゾーン転送を受ける機能を提供しているものがあります。対応の有無や利用できるプランはサービスごとに違うため、各サービスの説明で確かめます。
- 複数のDNSサービスに同じ内容を書く: ゾーン転送を使わず、それぞれの管理画面やAPIで同じレコードを登録する方法です。手作業だと内容がずれやすいため、octoDNS のような同期用のツールを使う例があります。
どの方法でも、追加するサーバーはゾーンのすべてのレコードを同じ内容で返せる必要があります。片方にしか無いレコードがあると、問い合わせ先によって答えが変わってしまいます。
ドメインでDNSSECを使っている場合は、もう一つ注意があります。ゾーン転送で署名済みのゾーンをそのまま受け取るなら問題になりにくいのですが、別々のDNSサービスがそれぞれ署名する構成では、鍵の情報を互いに共有する設定（RFC 8901で整理されている複数署名者の構成）が必要になります。ここを考えずに追加すると、検証に失敗して名前解決ができなくなる場合があるため、DNSSECを使っているときは事前に各サービスの対応状況を確かめます。
手順1：新しいネームサーバーにゾーンを用意する
ゾーン転送を使う場合の、BINDでの設定例です。IPアドレスは文書用の範囲を使っています。プライマリが 203.0.113.53、追加するセカンダリが 198.51.100.53 です。
// プライマリ側（named.conf の zone 定義）
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
allow-transfer { 198.51.100.53; };
also-notify { 198.51.100.53; };
notify yes;
};
// 追加するセカンダリ側
zone "example.com" {
type secondary;
primaries { 203.0.113.53; };
file "/var/cache/bind/example.com.zone";
};type primary type secondary primaries は比較的新しいBINDで使える書き方で、古いバージョンでは type master type slave masters と書きます。お使いのバージョンの説明書に合わせてください。ゾーン転送はIPアドレスでの制限に加えて、TSIG鍵で認証しておくと、他者にゾーンの内容を持ち出されるのを防げます。
設定を変える前に、設定ファイルとゾーンファイルのバックアップを取り、可能であれば検証用の環境で一度試します。
手順2：新しいサーバーが正しく答えるかを確かめる
NSレコードに載せる前に、新しいサーバーへ直接問い合わせて、権威のある答えを返しているかを見ます。
# 新しいサーバーにSOAを問い合わせる
dig @198.51.100.53 example.com SOA +norecurse
# 今のサーバーと比べる
dig @203.0.113.53 example.com SOA +norecurse +short
dig @198.51.100.53 example.com SOA +norecurse +short確かめる点は2つです。
flags:の欄にaaが付いていること。aaは「このサーバーがゾーンの担当として答えている」という印で、付いていなければゾーンを持っていません。- SOAのシリアル番号（
+shortの出力の3番目の数字）が今のサーバーと同じであること。違う場合は、ゾーン転送がまだ済んでいないか、失敗しています。
ゾーン転送が失敗しているときは、プライマリ側のログで転送を拒否していないか、ファイアウォールでTCPの53番ポートが閉じていないかを確かめます。ゾーン転送はTCPで行われるため、UDPだけ開けている環境ではつまずきやすい点です。
手順3：ゾーンの中にNSレコードを追加する
新しいサーバーが正しく答えることを確かめたら、ゾーンの頂点にNSレコードを1行追加します。
example.com. 86400 IN NS ns1.example-dns.jp.
example.com. 86400 IN NS ns2.example-dns.jp.
example.com. 86400 IN NS ns3.example.net. ; 追加ゾーンファイルで管理している場合は、SOAのシリアル番号を上げてから読み込み直します。シリアル番号を上げ忘れると、セカンダリは変更が無いものとして転送をしないため、追加したNSがセカンダリに届きません。
named-checkzone example.com /etc/bind/zones/example.com.zone
sudo rndc reload example.comDNSサービスの管理画面を使う場合、ゾーン頂点のNSレコードは自動で管理されていて編集できないことがあります。その場合は、サービスの説明に沿って「追加のネームサーバー」を設定する機能があるかを確かめます。
手順4：レジストラに追加する
最後に、レジストラの管理画面でネームサーバーの一覧に新しいサーバーを加えます。画面の名前や手順は事業者ごとに違いますが、多くは「ネームサーバーの変更」や「ネームサーバー設定」といった項目にあります。表記や画面の構成は事業者ごとに異なり、更新で変わることもあります（2026年10月現在）。
ここでつまずきやすいのが次の2点です。
- 既存のネームサーバーを消さない: 入力欄の書き換えで、既存のサーバーを上書きしてしまう例があります。登録後の一覧に、元のサーバーと新しいサーバーの両方が並んでいるかを見ます。
- ネームサーバーの名前が自分のドメインの中にある場合:
ns3.example.comのように、担当するドメインの中の名前を使うときは、親ゾーンにIPアドレス（グルーレコード）を登録する必要があります。レジストラによっては「ホスト登録」などの名前で別の画面になっています。
登録できるネームサーバーの数の上限は、レジストラやレジストリによって異なります。
手順5：親ゾーンとすべてのネームサーバーで確認する
親ゾーン側に反映されたかは、親ゾーンのネームサーバーへ直接問い合わせて確かめます。
# .com の場合
dig @a.gtld-servers.net example.com NS +norecurse
# .jp の場合
dig @a.dns.jp example.jp NS +norecurse
# ルートから順にたどる
dig example.com NS +trace親ゾーンの答えでは、ネームサーバーの一覧は AUTHORITY SECTION に出ます。ここに新しいサーバーが載っていれば、レジストラ側の登録は反映されています。
続けて、ゾーンの中のNSと、すべてのネームサーバーのSOAシリアルがそろっているかを確かめます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com SOA +norecurse +short
done親ゾーンのNSのTTLは長めに設定されていることが多く、.com では2日程度の値が使われています。新しいサーバーへの問い合わせが各地のキャッシュDNSから届き始めるまでには、その程度の時間がかかると考えておきます。追加した直後に古いサーバーを止めたり設定を変えたりせず、しばらくは全台が同じ内容を返す状態を保ちます。
追加したあとの運用
ネームサーバーが増えると、レコードを変えたときに「全台に反映されたか」を確かめる手間も増えます。ゾーン転送を使っている場合はシリアル番号の比較、複数のDNSサービスを使っている場合は主要なレコードの比較を、変更のたびに行うと安心です。DNSの監視サービスや自前のスクリプトで、各ネームサーバーのSOAシリアルを定期的に見比べておくと、転送の失敗に早く気付けます。
まとめ
- NSレコードは親ゾーン（レジストラで登録）とゾーンの中の2か所にあり、追加するときは両方をそろえます。
- 追加の前に、新しいサーバーが
aa付きで答え、SOAシリアルが既存のサーバーと同じであることを確かめます。 - 順序は「ゾーンを用意する → 答えを確かめる → ゾーンにNSを追加する → レジストラに追加する → 親ゾーンと全台で確認する」です。
- DNSSECを使っている場合は、別々のサービスがそれぞれ署名する構成に注意します。
- ゾーン転送はTCPの53番ポートを使い、シリアル番号を上げないと変更が届きません。