NS1 で移行する手順｜NS1 をセカンダリ DNS にしてゾーン転送で並走させ、段階的に切り替える

旧 DNS がゾーン転送（AXFR）に対応しているなら、NS1 をセカンダリ DNS として旧 DNS からゾーンを受け取らせ、両方が同じ答えを返す状態で並走させてから切り替えると、レコードを手で写す作業と写し漏れをほぼなくせます。この記事では、旧プライマリでの転送許可、NS1 でのセカンダリゾーンの作成、転送の確認、ネームサーバーの段階的な切り替え、最後に NS1 をプライマリにするか旧 DNS を隠れたプライマリとして残すかの判断までを、手順に沿って説明します。

ゾーンファイルを書き出して NS1 に取り込む一般的な移行方法とは別のやり方です。旧 DNS がゾーン転送を出せない場合（多くのマネージド DNS は外部への転送を提供していないか、上位の契約に限っています）は、書き出しと取り込みによる方法を選んでください。

NS1 は IBM の傘下に入り、ポータルの構成や契約の形態が変わってきています（2026年10月現在）。セカンダリゾーンの設定項目や、NS1 がゾーン転送に使う送信元 IP アドレスは、作業の時点で NS1 の公式ドキュメントで確認してください。

この方法が向く場面

ゾーン転送による移行が特に役立つのは、次のような場合です。

• 旧 DNS が自前の BIND、PowerDNS、Knot DNS などで、転送の設定を自分で変えられる。
• レコード数が多い、または頻繁に更新されていて、書き出しから切り替えまでの間に変更が入る。
• 切り替えを一度に行わず、旧 DNS と NS1 を一定期間並べて様子を見たい。

逆に、旧 DNS 独自の機能（エイリアス、地域別の振り分けなど）に依存しているレコードは、ゾーン転送では標準の DNS レコードとしてしか渡りません。そうしたレコードがある場合は、どう渡るかを転送後に確認し、必要なら NS1 で作り直します。

手順1：旧プライマリでゾーン転送を許可する

NS1 から旧プライマリへ転送の要求が来るので、それを許可します。許可は TSIG（共有鍵による署名）で絞り、さらにファイアウォールで NS1 の転送元 IP アドレスからの接続だけを受け付けるようにすると、第三者にゾーンの中身を丸ごと取得される危険を減らせます。NS1 が TSIG に対応する範囲と使えるアルゴリズムは公式ドキュメントで確認してください。

BIND の場合の例です。作業前に設定ファイルとゾーンファイルのバックアップを取ります。

# TSIG 鍵を作る（出力された key ブロックを設定に取り込む）
tsig-keygen -a hmac-sha256 ns1-transfer > /etc/bind/ns1-transfer.key

// named.conf の例（IP は NS1 の公式ドキュメントで案内される転送元・NOTIFY 先に置き換える）
include "/etc/bind/ns1-transfer.key";

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    notify yes;
    allow-transfer { key "ns1-transfer"; };
    also-notify { 192.0.2.53; };
};

named-checkconf
named-checkzone example.com /etc/bind/zones/example.com.zone
rndc reload example.com

ファイアウォールで、NS1 の転送元からの TCP 53 番を許可することも忘れないでください。ゾーン転送は TCP で行われるため、UDP だけを開けていると転送が失敗します。

手順2：NS1 にセカンダリゾーンを作る

NS1 のポータルでゾーンを作るときに、セカンダリとして作成する選択をし、プライマリの IP アドレス（とポート、TSIG を使う場合はその鍵）を指定します。API や Terraform でも作れます。

# API キーは環境変数で渡す（値をスクリプトやリポジトリに書かない）
export NS1_API_KEY='your-api-key'

# セカンダリゾーンを作る（198.51.100.10 は旧プライマリの IP。項目名は API ドキュメントで確認）
curl -sS -X PUT -H "X-NSONE-Key: ${NS1_API_KEY}" \
  -d '{"zone":"example.com","secondary":{"enabled":true,"primary_ip":"198.51.100.10","primary_port":53}}' \
  https://api.nsone.net/v1/zones/example.com

Terraform の NS1 プロバイダーでも、ゾーンのリソースにプライマリの IP を指定してセカンダリとして定義できます。属性名はプロバイダーのバージョンで変わることがあるため、使うバージョンのドキュメントで確認してください。TSIG の秘密鍵は Terraform の変数を sensitive にし、tfvars をリポジトリに含めないようにします。

手順3：転送できたかを確かめる

転送が成功していれば、NS1 のネームサーバーが旧プライマリと同じ SOA のシリアル番号を返します。NS1 に割り当てられたネームサーバー名は、ゾーンの情報やポータルの表示で確認します。

# 旧プライマリと NS1 の SOA を比べる（dns1.p01.nsone.net は自分のゾーンに割り当てられた名前に置き換える）
dig @198.51.100.10 example.com SOA +norec +short
dig @dns1.p01.nsone.net example.com SOA +norec +short

# 主要なレコードを NS1 から引いて、旧プライマリの答えと比べる
dig @dns1.p01.nsone.net www.example.com A +norec +short
dig @dns1.p01.nsone.net example.com MX +norec +short
dig @dns1.p01.nsone.net example.com TXT +norec +short

シリアル番号が一致しない、または NS1 が答えを返さない場合は、旧プライマリのログを見ます。BIND なら転送の要求が届いているか、拒否されているか（allow-transfer や TSIG の不一致）がログに出ます。要求自体が届いていなければ、ファイアウォールか、NS1 に指定したプライマリの IP を疑います。

次に、旧プライマリでテスト用のレコードを一つ追加し、シリアル番号を上げてリロードします。NOTIFY が届いていれば、少し待つと NS1 からもそのレコードが返ります。届いていない場合でも、SOA の refresh の間隔が過ぎれば NS1 が自分から確認しに来ますが、更新の遅れが大きくなるため、NOTIFY が届く状態にしておきます。確認が終わったらテスト用のレコードは削除します。

手順4：ネームサーバーを段階的に切り替える

旧 DNS と NS1 が同じ答えを返す状態になったら、レジストラのネームサーバー設定を変えます。ここが、この方法の利点が出る部分です。どちらに問い合わせが行っても同じ答えなので、次のように段階を踏めます。

1. 並べる段階: レジストラに旧 DNS のネームサーバーと NS1 のネームサーバーを並べて登録します。リゾルバはどちらにも問い合わせるようになります。この状態で数日様子を見て、問題がないかを確かめます。
2. 置き換える段階: 旧 DNS のネームサーバーをレジストラの登録から外し、NS1 だけにします。

並べる段階では、ゾーンの頂点にある NS レコードの内容と、レジストラに登録したネームサーバーの組み合わせがずれないようにします。セカンダリは頂点の NS レコードもプライマリから受け取るため、旧プライマリのゾーンファイルの NS レコードに NS1 のネームサーバーを書き足しておくと、両者がそろいます。NS1 が頂点の NS レコードをどう扱うかは公式ドキュメントで確認してください。

登録できるネームサーバーの数はレジストラや TLD によって上限があるため、すべてを並べられない場合は、それぞれから数台ずつ選びます。

手順5：DNSSEC を使っている場合

旧プライマリで DNSSEC の署名を行っている場合、セカンダリに署名済みのゾーンを渡す形になるのか、NS1 側で署名するのかで手順が大きく変わります。署名済みのゾーンをセカンダリとして配信できるか、二つの事業者で鍵を併用する構成がとれるかは、事業者ごとに対応が異なります。

両社の対応がはっきりしない場合は、移行の前にレジストラの DS レコードを外し、その TTL が過ぎるのを待ってから並べる段階に入るのが安全です。移行が終わってから NS1 で DNSSEC を有効にし、新しい DS レコードを登録します。この間は DNSSEC による保護がなくなることを、関係者と共有しておきます。

手順6：最終形を決める

NS1 だけに切り替わった後の形は二つあります。

• 旧 DNS を隠れたプライマリとして残す: レコードの編集は旧プライマリで続け、NS1 は配信だけを担当します。編集の手順や自動化を変えずに済みますが、旧プライマリの停止や設定ミスが NS1 の更新の停止につながるため、旧プライマリの監視とバックアップを続けます。
• NS1 をプライマリにする: セカンダリゾーンをプライマリに切り替え、以後のレコードの編集は NS1 のポータル、API、Terraform で行います。切り替えたときにレコードが残るか、切り替えの操作方法は公式ドキュメントで確認し、操作の前にゾーンの情報を API で保存しておきます。切り替えた後は、旧プライマリでの編集が NS1 に反映されなくなるため、旧プライマリのゾーンは読み取り専用の扱いにするか停止します。

どちらの場合も、切り替えた後に旧プライマリの allow-transfer に不要な許可が残っていないかを見直します。

まとめ

• 旧 DNS がゾーン転送を出せるなら、NS1 をセカンダリにして同じ答えを返す状態を作ると、写し漏れのない移行ができます。
• 旧プライマリでは TSIG で転送を絞り、ファイアウォールで NS1 の転送元からの TCP 53 番を許可します。転送の成否は SOA のシリアル番号で確かめます。
• レジストラには旧 DNS と NS1 を並べてから NS1 だけにする、という段階を踏めます。頂点の NS レコードとの食い違いに注意します。
• DNSSEC は両社の対応を確認し、分からなければ DS を外してから進めます。
• 最後に、旧 DNS を隠れたプライマリとして残すか、NS1 をプライマリにするかを決めます。

• BIND で DNS サーバーを構築する方法
• DNS の NS レコードの役割と設定