ほかの DNS サービスから NS1 へ移行するときは、「旧 DNS のゾーンを書き出して NS1 に取り込む」「旧サービス独自のレコード（エイリアスや CNAME のフラット化など）を NS1 で使える形に直す」「NS1 のネームサーバーに直接問い合わせて答えを確かめる」「DNSSEC を外してからネームサーバーを切り替える」という順に進めるのが安全です。この記事では、移行の前準備から取り込み、確認、切り替え、旧 DNS の停止までを、NS1 に特有の注意点とあわせて説明します。
NS1 は IBM の傘下となり、製品名や管理画面（ポータル）の構成、契約の形態が変わってきています（2026年10月現在）。以下では画面の表記ではなく「何をするか」で説明しますので、実際の操作と API の仕様は NS1 の公式ドキュメントで確認してください。
移行の全体像
DNS の移行で関わるのは、レジストラ（ドメインを契約している事業者）、旧 DNS、新 DNS（NS1）の三つです。レジストラに登録するネームサーバーを旧 DNS から NS1 に変えると、世界中のキャッシュ DNS が少しずつ NS1 に問い合わせるようになります。この切り替えは一斉には起こらず、数日にわたって旧 DNS と NS1 の両方に問い合わせが届きます。両方が同じ答えを返す状態を作ってから切り替えれば、どちらに問い合わせが行っても利用者には違いが出ません。
手順1：旧 DNS のゾーンを書き出す
まず旧 DNS のレコードを漏れなく書き出します。書き出しの方法はサービスによって異なります。
- BIND 形式のゾーンファイルを書き出せるサービス: 管理画面のエクスポート機能で保存します。Cloudflare などはこの形式での書き出しに対応しています。
- 書き出し機能がないサービス: API や CLI でレコード一覧を取得し、BIND 形式に変換します。Route 53 の場合は
aws route53 list-resource-record-setsで JSON を取得できますが、ゾーンファイルへの変換は自分で行う必要があります。 - 自前の BIND などで運用している場合: ゾーンファイルをそのまま使えます。
書き出したら、主要な名前について旧 DNS が実際に返している値を dig で確認し、書き出した内容と食い違いがないかを照合します。
# 旧DNSのネームサーバー名を確認
dig +short example.com NS
# 旧DNSに直接問い合わせる（ns1.old-dns.example は上で確認した名前に置き換える）
dig @ns1.old-dns.example example.com A +noall +answer
dig @ns1.old-dns.example www.example.com CNAME +noall +answer
dig @ns1.old-dns.example example.com MX +noall +answer
dig @ns1.old-dns.example example.com TXT +noall +answerメール関連（MX、SPF、DKIM、DMARC）、所有権確認用の TXT、SSL 証明書発行用のレコード、CAA、SRV は写し忘れが多いので、一覧の中で特に念入りに確認します。
手順2：旧サービス独自のレコードを変換する
DNS サービスの多くは、標準の DNS にはない独自の仕組みを持っています。これらは標準のゾーンファイルにそのまま書き出せないか、書き出しても意味が変わってしまうため、移行の前に一つずつ確認して NS1 での表現に置き換えます。
- Route 53 のエイリアスレコード: CloudFront やロードバランサーを指すエイリアスは、書き出すと A レコードの固定 IP になったり、まったく出てこなかったりします。指している先のホスト名を確認し、NS1 では ALIAS レコードや、頂点以外なら CNAME で表現します。
- Cloudflare の CNAME フラット化とプロキシ: 頂点に CNAME を置いている設定や、プロキシを有効にしているレコードは、Cloudflare の中でだけ成り立つ動作です。プロキシ経由の IP をそのまま写すと、Cloudflare を外した後に通信先が合わなくなります。オリジンサーバーの本来の値を確認して登録し直します。
- 重み付け・位置情報などのルーティング: 旧サービスのルーティングポリシーは、NS1 では Filter Chain と呼ばれる仕組みで表現します。設定の考え方が異なるため、移行時はいったん単純なレコードで同じ答えを返す状態にし、振り分けは切り替えが落ち着いてから作り込むほうが安全です。
頂点（example.com そのもの）を CDN やロードバランサーのホスト名に向けたい場合、標準の DNS では CNAME を置けません。NS1 の ALIAS レコードはこの用途に使えますが、動作の細かな仕様は公式ドキュメントで確認してください。
手順3：TTL を下げて待つ
切り替えの前日までに、旧 DNS で主要なレコードの TTL を 300 秒程度に下げておきます。下げた設定が効き始めるのは、元の TTL の時間が過ぎた後です。元が 86400（1日）なら、下げてから1日以上待ちます。こうしておくと、切り替え後に値の誤りが見つかったときも短い時間で直せます。
ネームサーバー自体の切り替わりは、上位のレジストリが持つ NS レコードの TTL に左右され、利用者側では変えられません。切り替え後しばらくは旧 DNS にも問い合わせが届く前提で計画してください。
手順4：NS1 にゾーンを作り、レコードを取り込む
NS1 のポータルでゾーンを作成し、ゾーンファイルの取り込み機能を使うか、レコードを手で登録します。件数が多い場合や、複数のゾーンをまとめて移す場合は API や Terraform を使うと、作業の再現性が上がります。
API を使う場合は、NS1 のポータルで API キーを発行し、ヘッダーに付けて呼び出します。キーには必要最小限の権限だけを与え、スクリプトに直接書かず環境変数で渡してください。
# APIキーは環境変数で渡す（値をスクリプトやリポジトリに書かない）
export NS1_API_KEY='your-api-key'
# ゾーンを作成する
curl -sS -X PUT -H "X-NSONE-Key: ${NS1_API_KEY}" \
-d '{"zone":"example.com"}' \
https://api.nsone.net/v1/zones/example.com
# ゾーンの情報を取得する（割り当てられたネームサーバーなどを確認できる）
curl -sS -H "X-NSONE-Key: ${NS1_API_KEY}" \
https://api.nsone.net/v1/zones/example.comゾーンファイルを API で取り込む方法も用意されていますが、エンドポイントや指定の仕方は API ドキュメントで最新の仕様を確認してください。取り込んだ後は、ポータルでレコード一覧を開き、件数と主要な値が書き出した内容と合っているかを確かめます。NS と SOA は NS1 側で用意されるものを使い、旧 DNS の NS レコードを写す必要はありません。
Terraform で管理する場合は、NS1 が公開している公式のプロバイダーを使えます。移行の時点からコードで定義しておけば、その後の変更もレビューを通して行えます。
手順5：切り替える前に NS1 へ直接問い合わせる
NS1 では、ゾーンごとにネームサーバーが割り当てられます。ゾーンの情報やポータルの表示で割り当てられた名前を確認し、そのネームサーバーに直接問い合わせて、旧 DNS と同じ答えが返るかを確かめます。
# dns1.p01.nsone.net は、自分のゾーンに割り当てられた名前に置き換える
dig @dns1.p01.nsone.net example.com A +noall +answer
dig @dns1.p01.nsone.net www.example.com CNAME +noall +answer
dig @dns1.p01.nsone.net example.com MX +noall +answer
dig @dns1.p01.nsone.net example.com TXT +noall +answer旧 DNS の答えと1件ずつ見比べます。違いがあれば、ここで直しておきます。切り替え前ならまだ利用者に影響はありません。
手順6：DNSSEC を使っている場合は先に外す
旧 DNS で DNSSEC を有効にしている場合、レジストラには旧 DNS の鍵に対応する DS レコードが登録されています。この DS が残ったまま NS1 に切り替えると、DNSSEC を検証するリゾルバは NS1 の答えを検証できず、ドメインが引けなくなります。
単純で安全なのは、次の順番です。
- レジストラで DS レコードを削除する。
- DS レコードの TTL（上位ゾーンでの保持時間）が過ぎるまで待つ。
- ネームサーバーを NS1 に切り替え、安定するのを待つ。
- NS1 で DNSSEC を有効にし、新しい DS レコードをレジストラに登録する。
この方法では、移行中の一時期は DNSSEC による保護がなくなります。保護を途切れさせずに移す方法（両方の事業者の鍵を併用する構成）もありますが、両方の事業者の対応と手順の理解が必要になるため、事前に両社のドキュメントで対応状況を確認してください。
手順7：ネームサーバーを切り替えて確認する
レジストラの管理画面で、ネームサーバーを NS1 に割り当てられたものに変更します。切り替えたら、委任先が変わったことと、公開リゾルバ経由の答えを確認します。
dig +short example.com NS
dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 example.com MX +shortブラウザでサイトが開くこと、WordPress の管理画面にログインできること、問い合わせフォームのメールが届くこと、外部からのメールを受信できることもあわせて確認します。
手順8：旧 DNS はしばらく残す
切り替え後も、旧 NS をキャッシュしているリゾルバからは旧 DNS に問い合わせが届きます。旧 DNS のゾーンはすぐに削除せず、1週間程度は残しておき、その間は旧 DNS のレコードを変更しないようにします。問い合わせが来なくなったことを確認してから、旧 DNS を停止し、契約を整理します。
まとめ
- 旧 DNS のゾーンを書き出し、dig で実際の値と照合してから NS1 に取り込みます。
- エイリアス、CNAME のフラット化、プロキシ、ルーティングポリシーなど旧サービス独自の設定は、NS1 で使える形に置き換えます。振り分けは移行が落ち着いてから作り込みます。
- 旧 DNS の TTL を下げて待ち、NS1 の割り当てネームサーバーに直接問い合わせて答えを確かめてから切り替えます。
- DNSSEC を使っている場合は、DS レコードを外して待ってから切り替え、移行後に NS1 で有効にし直します。
- 切り替え後はサイトとメールを確認し、旧 DNS はしばらく残しておきます。