NS1 の移行方法｜NS1 から別の DNS サービスへ移すときの書き出し・Filter Chain の整理・切り替えの順番

NS1 で運用しているゾーンを別の DNS サービスへ移すときは、「NS1 独自の機能を何に使っているかを棚卸しする → レコードを API などで書き出す → Filter Chain や ALIAS を移行先で表現できる形に直す → 移行先で答えを確かめてから DNSSEC を外し、ネームサーバーを切り替える → NS1 のゾーンと API キーをしばらく残してから片付ける」という順で進めます。この記事は NS1 から出ていく側の手順をまとめたもので、ほかのサービスから NS1 へ入ってくる場合とは注意点が異なります。

NS1 は IBM の傘下に入り、製品名、ポータルの構成、契約の形態が変わってきています（2026年10月現在）。ここでは画面の表記に頼らず「何をするか」で説明します。API の項目名やエンドポイントは、作業の時点で NS1 の API ドキュメントを確認してください。

移行前の棚卸し：NS1 で何をしているか

NS1 は単純な権威 DNS としても使えますが、答えを条件で選ぶ仕組みや監視との連携を持っています。これらはゾーンファイルにそのまま書き出せないため、移行先でどう扱うかを先に決めておく必要があります。ゾーンごとに次の点を確認します。

• Filter Chain を設定したレコード: 一つのレコードに複数の答え（IP など）を持たせ、地域、重み、稼働状況などで返す答えを選んでいるもの。
• 監視（Monitor）とデータフィード: 監視の結果で答えの稼働状態を切り替え、フェイルオーバーさせているもの。移行先では監視の仕組みから作り直しになります。
• ALIAS レコード: 頂点を CDN やロードバランサーのホスト名に向けているもの。移行先が同様の機能（ALIAS、ANAME、CNAME のフラット化など）を持つかで書き方が変わります。
• セカンダリの設定: NS1 をプライマリにして他社へゾーン転送している、または他社のプライマリから NS1 が受けているもの。
• DNSSEC: 有効にしているゾーンは、切り替えの前に DS レコードの扱いを決めます。
• 自動化: API キーを使うスクリプト、Terraform、証明書の自動発行（DNS-01 チャレンジ）など、NS1 の API に依存している仕組み。

最後の項目は見落としやすい部分です。たとえば Let's Encrypt の証明書を DNS-01 で更新している場合、NS1 から移した後も古い設定のまま動き続け、更新の時期になって初めて失敗に気付く、ということが起こります。

レコードを書き出す

書き出しの方法は大きく二つあります。

一つ目は API でゾーンの情報を取得する方法です。ゾーンの情報にはレコードの一覧（名前、タイプ、TTL、答えの要約など）が含まれます。Filter Chain の設定や、答えごとのメタデータ（地域、重み、稼働状態）まで見るには、レコード単位の情報を取得します。

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

# ゾーンの情報（レコードの一覧を含む）を保存する
curl -sS -H "X-NSONE-Key: ${NS1_API_KEY}" \
  https://api.nsone.net/v1/zones/example.com > example.com.json

# 名前・タイプ・TTL・答えの要約を一覧にする（項目名は API ドキュメントで確認）
jq -r '.records[] | [.domain, .type, (.ttl|tostring), (.short_answers|join(" "))] | @tsv' example.com.json

# Filter Chain やメタデータを含め、レコード単位の詳細を保存する
curl -sS -H "X-NSONE-Key: ${NS1_API_KEY}" \
  https://api.nsone.net/v1/zones/example.com/www.example.com/A > www.example.com_A.json

書き出しに使う API キーは、読み取りだけの権限で新しく発行し、作業が終わったら無効にします。

二つ目は、移行先がセカンダリ DNS としてのゾーン転送（AXFR）に対応している場合に、NS1 をプライマリとしてゾーン転送を許可し、移行先に取り込ませる方法です。手で写すより漏れが出にくく、移行先がゾーン転送を受けられるなら有力な選択肢です。ただし、ゾーン転送で渡るのは「標準の DNS として表現できる部分」だけで、Filter Chain の条件や監視の設定は渡りません。

書き出した内容は、主要な名前について NS1 が実際に返している答えと照合します。

# 自分のゾーンに割り当てられた NS1 のネームサーバー名を確認する
dig +short example.com NS

# NS1 に直接問い合わせる（dns1.p01.nsone.net は上で確認した名前に置き換える）
dig @dns1.p01.nsone.net example.com A +norec +noall +answer
dig @dns1.p01.nsone.net example.com MX +norec +noall +answer
dig @dns1.p01.nsone.net example.com TXT +norec +noall +answer

Filter Chain と ALIAS を移行先の形に直す

Filter Chain を使ったレコードは、問い合わせのたびに答えが変わることがあります。dig で一度引いた答えだけを写すと、複数の答えのうち一つしか移らない、ということが起こります。レコード単位で取得した詳細から、登録されているすべての答えと、どの条件で選ばれていたかを確認します。

移行先での表現は、次のどれかになります。

• 移行先のルーティング機能で作り直す: 地域別や重み付けの機能を持つサービス（Route 53 など）なら、同等の振り分けを設定します。ただし、条件の判定方法や細かな動作は同じではありません。
• いったん単純なレコードにする: 移行の時点では答えを一つ、または複数の A レコードを並べた形にし、振り分けは切り替えが落ち着いてから作り込みます。移行作業と振り分けの変更を同時に行わないほうが、問題が起きたときに原因を切り分けやすくなります。
• 監視によるフェイルオーバーは別に用意する: NS1 の監視で答えを切り替えていた場合、移行先のヘルスチェック機能か、外部の監視とロードバランサーで代わりを用意します。用意できるまでは、フェイルオーバーがない状態になることを関係者と共有しておきます。

ALIAS レコードは、移行先が同様の機能を持っていれば、その書き方で登録し直します。持っていない場合は、頂点を A レコードの固定 IP にするか、頂点から www へリダイレクトする構成に変えるかを検討します。CDN の IP は変わることがあるため、固定 IP を写すのは避けます。

切り替えの準備：TTL と DNSSEC

切り替えの前日までに、NS1 側で主要なレコードの TTL を 300 秒程度に下げ、元の TTL の時間が過ぎるまで待ちます。こうしておくと、切り替え後に値の誤りが見つかっても短い時間で直せます。

DNSSEC を有効にしている場合は、レジストラに NS1 の鍵に対応する DS レコードが登録されています。このまま移行先に切り替えると、DNSSEC を検証するリゾルバは移行先の答えを検証できず、名前が引けなくなります。単純で安全なのは、レジストラで DS レコードを削除し、その TTL が過ぎるのを待ってから切り替え、移行先で改めて DNSSEC を有効にする順番です。移行中に保護が途切れない方法もありますが、両方の事業者が対応している必要があるため、両社のドキュメントで確認してください。

切り替えと確認

移行先に割り当てられたネームサーバーへ直接問い合わせ、NS1 の答えと1件ずつ見比べます。違いがなければ、レジストラでネームサーバーを移行先のものに変更します。

# 移行先のネームサーバーに直接問い合わせる（ns1.new-dns.example は実際の名前に置き換える）
dig @ns1.new-dns.example example.com A +norec +short
dig @ns1.new-dns.example example.com MX +norec +short

# 切り替え後に委任と公開リゾルバの答えを確認する
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 の管理画面へのログイン、問い合わせフォームからのメール、外部からのメール受信もあわせて確認します。証明書の自動更新を DNS-01 で行っている場合は、移行先の API を使う設定に変えたうえで、テスト用の発行（certbot なら --dry-run）で動くことを確かめます。

NS1 側の片付け

切り替え後も、古いネームサーバーをキャッシュしているリゾルバからは NS1 に問い合わせが届きます。NS1 のゾーンはすぐに削除せず、1週間程度は残しておき、その間は NS1 側のレコードを変更しないようにします。

Terraform で NS1 のゾーンを管理していた場合は、コードから NS1 のリソースを消して apply すると、その時点で NS1 のゾーンが削除されます。切り替え直後に削除が走らないよう、移行先のコードを別に用意し、NS1 側のリソースは terraform state rm で state から外すか、待機期間が終わるまで残しておきます。どちらにするかは、待機期間の後に誰がどう削除するかとあわせて決めておきます。

待機期間が終わったら、NS1 のゾーンを削除し、移行のために発行したものも含めて API キーを無効にし、契約を整理します。

まとめ

• 移行の前に、Filter Chain、監視、ALIAS、セカンダリ、DNSSEC、API に依存する自動化を棚卸しします。
• レコードは API で書き出すか、移行先が対応していればゾーン転送で渡します。どちらでも Filter Chain の条件や監視は移らないため、別に扱います。
• 振り分けは移行時はいったん単純にし、切り替えが落ち着いてから移行先の機能で作り直します。
• TTL を下げて待ち、DNSSEC の DS レコードを外してから切り替えます。
• NS1 のゾーンは1週間程度残し、Terraform の削除が切り替え直後に走らないようにします。最後に API キーを無効にします。

• DNS の TTL の設定方法と考え方
• dig コマンドで DNS を調べる方法