2026年6月10日

NS1 で複数ドメインを管理する方法｜リンクゾーン・API・Terraformで揃えて運用する

DNS・名前解決

NS1 で複数のドメインを管理するときは、ドメインを「独自のレコードを持つゾーン」と「別のゾーンと同じ内容でよいゾーン」に分けるところから始めます。後者にはリンクゾーン（あるゾーンの内容をそのまま参照するゾーン）を使い、前者は API や Terraform でレコードを揃えると、ドメインが増えても管理の手間が増えにくくなります。この記事では、ドメインの棚卸し、リンクゾーンの使いどころ、API と Terraform での一括管理、権限と確認の手順を説明します。

NS1 は 2023 年に IBM に買収され、現在は IBM のブランド（IBM NS1 Connect）として提供されています（2026年10月現在）。管理画面の名称やメニュー構成、利用できる機能の範囲は契約やプランで異なり、変わることもあります。ここでは機能を目的で説明するので、実際の項目名は公式ドキュメントで確かめてください。

まずドメインを棚卸しする

複数ドメインの管理で起きる問題の多くは、「このドメインは何のためにあるのか」「誰が変更してよいのか」が決まっていないことから生まれます。作業の前に、管理しているドメインを一覧にして、次の項目を書き出します。

用途：本番サイト、キャンペーン用、ブランド保護のために取っただけ、メール専用、など
内容の独自性：独自のレコードがあるか、別のドメインと同じ内容（転送先が同じ Web サーバーなど）でよいか
担当：変更を決める人・部署
メールの有無：MX と SPF／DKIM／DMARC が要るか、メールを送らないドメインか

この表ができると、どのドメインをリンクゾーンにできるか、どのドメインに共通のテンプレートを当てるかが決まります。ブランド保護のためだけに取ったドメインでも、「メールを送らない」ことを示す SPF（v=spf1 -all）や DMARC のレコードを置いておくと、なりすましメールに使われにくくなります。

同じ内容のドメインはリンクゾーンにする

リンクゾーンは、元のゾーン（ソース）を指定して作るゾーンで、レコードを自分では持たず、ソースのレコードをそのまま使って応答します。たとえば example.com をソースにして example.net をリンクゾーンにすると、www.example.net への問い合わせには www.example.com に登録した内容で答えます。ソースのレコードを1か所直せば、リンクしたすべてのドメインに反映されるのが利点です。

リンクゾーンが向いているのは、綴り違いのドメインや、国別ドメイン（.jp と .com）で同じサイトを見せたい場合のように、内容を揃えておきたいドメインです。逆に、ドメインごとに違うメール設定や、サービスの所有確認用の TXT レコードが必要な場合は、リンクゾーンにできません。所有確認の TXT はドメインごとに値が違うことが多いため、検索エンジンやメールサービスの確認を通す予定のあるドメインは、通常のゾーンにしておくほうが安全です。

SOA や NS などゾーンの頂点のレコードがリンクゾーンでどう扱われるか、リンクを後から外せるかといった細部は、公式ドキュメントで確かめてから本番のドメインに使ってください。

API でゾーンを一覧・作成する

NS1 の API は、X-NSONE-Key ヘッダーに API キーを入れて呼び出します。キーはコードやスクリプトに直接書かず、環境変数で渡します。

export NS1_APIKEY="your-api-key"

# 管理しているゾーンの一覧
curl -s -H "X-NSONE-Key: $NS1_APIKEY" https://api.nsone.net/v1/zones \
  | jq -r '.[].zone'

リンクゾーンを API で作る場合は、ゾーン作成の要求で link にソースのゾーン名を指定します。

curl -s -X PUT -H "X-NSONE-Key: $NS1_APIKEY" \
  -d '{"zone":"example.net","link":"example.com"}' \
  https://api.nsone.net/v1/zones/example.net

NS1 の API は、作成に PUT、更新に POST を使う設計になっている点に注意します。一般的な REST の慣習と逆に感じるため、スクリプトを書くときに取り違えやすいところです。

一覧を定期的に取得して、棚卸しの表と比べる使い方も役に立ちます。表にないゾーンが増えていれば、誰かが手作業で作ったものなので、用途と担当を確認します。

Terraform で共通レコードを揃える

ドメインの数が多い場合は、Terraform でゾーンとレコードを定義すると、変更の差分を plan で確かめてから反映できます。NS1 のプロバイダーは Terraform Registry で ns1-terraform/ns1 として公開されています。API キーは環境変数 NS1_APIKEY から読み込めます。

terraform {
  required_providers {
    ns1 = {
      source = "ns1-terraform/ns1"
    }
  }
}

provider "ns1" {}

locals {
  own_zones    = toset(["example.com", "example.org"])
  linked_zones = { "example.net" = "example.com" }
}

# 独自のレコードを持つゾーン
resource "ns1_zone" "own" {
  for_each = local.own_zones
  zone     = each.value
}

# 同じ内容でよいゾーン（リンクゾーン）
resource "ns1_zone" "linked" {
  for_each = local.linked_zones
  zone     = each.key
  link     = ns1_zone.own[each.value].zone
}

# 独自ゾーンに共通の www を作る
resource "ns1_record" "www" {
  for_each = ns1_zone.own
  zone     = each.value.zone
  domain   = "www.${each.value.zone}"
  type     = "CNAME"

  answers {
    answer = each.value.zone
  }
}

ns1_record の domain には、ゾーン内の相対名ではなく完全な名前（www.example.com）を書きます。ここを相対名で書くと、意図しない名前のレコードになったりエラーになったりするため、最初に間違えやすい点です。

既存のゾーンやレコードがある場合は、terraform import（または Terraform 1.5 以降の import ブロック）で取り込んでから運用を始めます。取り込みの前に、API でゾーンの内容を JSON として保存しておくと、誤って変えたときに戻せます。取り込み後に terraform plan を実行して差分が出ないことを確かめ、差分が出る場合はコード側を実際の値に合わせます。

Terraform で管理するゾーンは、管理画面から直接変更しない決まりにします。画面で変えた値は、次の apply でコードの内容に戻されるためです。

権限とキーを分ける

複数のドメインを複数の担当で扱う場合、API キーや利用者の権限を用途ごとに分けます。NS1 には、キーや利用者ごとに操作できる範囲を設定する仕組みや、キーを使える接続元の IP アドレスを制限する仕組みがあります（細かな設定項目はプランや時期によって異なるため、公式ドキュメントで確認してください）。

Terraform を実行する CI 用のキーは、DNS の編集に必要な権限だけにする
監視や棚卸しのスクリプトには、読み取りだけのキーを使う
人が使うアカウントには二要素認証を設定し、退職や異動のときにすぐ無効にできるようにする

キーが漏れたときに被害を小さくするため、1つのキーを複数の用途で使い回さないことが大切です。

反映を確かめる

変更後は、NS1 のネームサーバーに直接問い合わせて応答を確かめます。ネームサーバー名はゾーンの詳細で確認できます。

dig @dns1.p01.nsone.net www.example.com CNAME +short
dig @dns1.p01.nsone.net www.example.net CNAME +short

リンクゾーンでは、ソースと同じ内容が返ることを確かめます。ネームサーバー名はアカウントによって違う場合があるため、例の名前は自分の環境のものに置き換えてください。キャッシュ DNS を通した確認では TTL が切れるまで古い値が返ることがあるため、権威サーバーへの直接の問い合わせと分けて考えます。

まとめ

最初にドメインを棚卸しし、用途・内容の独自性・担当・メールの有無を決める
同じ内容でよいドメインはリンクゾーンにして、ソースの1か所で管理する。所有確認の TXT が要るドメインは通常のゾーンにする
API は X-NSONE-Key ヘッダーで認証し、作成は PUT・更新は POST という設計に注意する
Terraform では ns1_record の domain に完全な名前を書き、既存分は import してから運用する
キーは用途ごとに分けて権限を絞り、機能名やプランの範囲は公式ドキュメントで確かめる