NS1 で複数ドメインを管理する方法｜委任・DNSSEC・メール設定・放置レコードを定期点検する運用

NS1 に置いたドメインが増えてくると、問題になるのはレコードの作り方よりも「いつの間にか壊れている設定に気づけないこと」です。この記事では、NS1 の API で全ゾーンのレコードを読み出し、委任（ネームサーバーの登録）、DNSSEC、メール関連のレコード、使われなくなった CNAME を定期的に点検する運用を説明します。リンクゾーンや Terraform でレコードを揃える方法は別の記事で扱っているので、ここでは「揃えたあとに崩れていないかを確かめる側」に絞ります。

NS1 は 2023 年に IBM に買収され、IBM NS1 Connect として提供されています（2026年10月現在）。管理画面のメニュー名、API の細かな項目、契約ごとに使える機能は変わることがあるため、以下は機能を目的で説明し、具体的な項目名は公式ドキュメントで確かめる前提で読んでください。

何を点検するのか

複数ドメインで実際に起きやすい事故は、だいたい次の五つに分けられます。

• 委任のずれ：レジストラ側のネームサーバーが NS1 を指していない、または一部だけ古い事業者のまま残っている
• DNSSEC の不整合：レジストラに DS レコードが残っているのに、NS1 側で署名していない（またはその逆の手順で切り替えた）
• メール関連の欠落：メールを送るドメインに SPF・DMARC がない、送らないドメインがなりすましに使われる余地を残している
• 放置レコード：削除済みのクラウドのリソースやサービスを指す CNAME が残っている
• ドメインの有効期限：NS1 は DNS の応答を担当するだけで、ドメインの契約更新はレジストラの管理です

どれも、一度設定したときには正しかったものが、担当の交代や外部サービスの解約をきっかけに崩れるという共通点があります。月に一度など周期を決めて、同じ手順で見ていくのが効果的です。

読み取り専用のキーで全ゾーンを書き出す

点検用のスクリプトには、レコードを変更できない読み取り専用の API キーを使います。点検は定期実行するため、キーがサーバーやCIの設定に長く残ります。漏れても書き換えられないキーにしておけば、被害を抑えられます。キーは環境変数で渡し、スクリプトやリポジトリに書き込まないでください。

#!/bin/bash
# NS1 の全ゾーンのレコードを JSON で保存する（読み取り専用キーを使う）
set -euo pipefail
: "${NS1_APIKEY:?NS1_APIKEY を設定してください}"
OUT="ns1-export-$(date +%Y%m%d)"
mkdir -p "$OUT"

curl -sf -H "X-NSONE-Key: $NS1_APIKEY" https://api.nsone.net/v1/zones \
  | jq -r '.[].zone' > "$OUT/zones.txt"

while read -r zone; do
  curl -sf -H "X-NSONE-Key: $NS1_APIKEY" \
    "https://api.nsone.net/v1/zones/$zone" > "$OUT/$zone.json"
  sleep 1   # API のレート制限に配慮して間隔を空ける
done < "$OUT/zones.txt"

ゾーンの詳細には、レコードの一覧（名前・種類・応答の値・TTL）が含まれます。毎回の書き出しを日付つきで残しておくと、前回との差分から「誰かが手作業で足した・消したレコード」を見つけられ、誤って消したときの復元にも使えます。応答 JSON の項目名は API のバージョンで変わる可能性があるため、最初に1つのゾーンを jq . で眺めて、実際の構造を確かめてからスクリプトを組んでください。

API には呼び出し回数の制限があります。ゾーン数が多いときは、上の例のように間隔を空けるか、エラー時に待って再試行する処理を入れます。

委任が NS1 を指しているか確かめる

NS1 にゾーンがあっても、レジストラで登録されたネームサーバーが別の事業者を指していれば、NS1 のレコードは誰にも使われていません。逆に、移行の途中で NS1 と旧事業者が混ざって登録されていると、問い合わせ先によって答えが変わる状態になります。

#!/bin/bash
# 公開DNS経由で各ゾーンの NS を取り、NS1 以外が混ざっていないか見る
while read -r zone; do
  ns=$(dig +short NS "$zone" @1.1.1.1 | sort | tr '\n' ' ')
  if [ -z "$ns" ]; then
    echo "NG  $zone : NS が返らない（期限切れや委任なしの可能性）"
  elif echo "$ns" | tr ' ' '\n' | grep -v '^$' | grep -qv 'nsone\.net\.$'; then
    echo "要確認 $zone : $ns"
  else
    echo "OK  $zone"
  fi
done < zones.txt

この例は、ネームサーバー名が nsone.net で終わる前提で判定しています。契約によっては独自の名前（ホワイトラベルのネームサーバー）を使っている場合があるので、自分のゾーンの詳細に表示されるネームサーバー名に合わせて条件を書き換えてください。「要確認」が出たドメインは、dig example.com NS +trace で上位の TLD サーバーが返す NS を見て、レジストラ側の登録を直します。

DNSSEC が壊れていないか確かめる

DNSSEC で一番怖いのは、レジストラに DS レコードが登録されているのに、権威サーバー側の署名がそれと合わない状態です。この状態では、DNSSEC の検証を行うキャッシュ DNS（多くの公開 DNS がそうです）から名前解決できなくなり、サイトもメールも届かなくなります。

# DS がレジストラ側に登録されているか
dig +short DS example.com @1.1.1.1

# 検証つきの問い合わせ。flags に ad が付けば検証成功
dig example.com A @1.1.1.1 +dnssec | grep -E 'flags:|status:'

# SERVFAIL のときは検証を止めて再度問い合わせ、DNSSEC が原因か切り分ける
dig example.com A @1.1.1.1 +cd +short

DS があって status: SERVFAIL、+cd（検証なし）なら答えが返る、という組み合わせなら DNSSEC の不整合が原因です。DS がないドメインは DNSSEC を使っていない状態で、それ自体はエラーではありません。DNSSEC を有効にするか、外すかの判断と手順はドメインごとに異なるため、変更するときは NS1 側での署名とレジストラでの DS 登録を、決まった順番で一つずつ行います。

メール関連のレコードをドメインの用途と照らし合わせる

棚卸しの表で「メールを送る」としたドメインと、「送らない」としたドメインで、確認する内容が変わります。

メールを送るドメインでは、SPF（v=spf1 で始まる TXT が1つだけあるか）、DMARC（_dmarc の TXT）、DKIM（送信サービスが指定したセレクタ名のレコード）を確認します。SPF を2つ置いてしまうと、受信側で SPF の評価が失敗扱いになることがあるため、書き出した JSON で TXT の数を数えると見つけやすくなります。

メールを送らないドメインには、なりすまし対策として次の3つを置くのが一般的です。

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject;"
example.net.         MX   0 .

最後の MX 0 . は「このドメインはメールを受け取らない」ことを示す Null MX（RFC 7505）です。ブランド保護のために取得しただけのドメインほど設定が漏れやすいため、点検の対象に含めておきます。

あわせて CAA レコードも見ておくと、証明書を発行できる認証局を制限できているかが分かります。証明書の発行元を変えたのに CAA が古いままだと、更新のときに発行が止まるので、発行元を変えたときの確認項目にも入れておきます。

使われていない CNAME を見つける

外部サービスやクラウドのリソースを解約したのに、それを指す CNAME が残っていると、第三者が同じ名前のリソースを取得して、自社のサブドメインでコンテンツを出せてしまうことがあります（サブドメインの乗っ取り）。放置されたレコードは見た目では分からないため、CNAME の向き先が今も名前解決できるかを機械的に調べます。

#!/bin/bash
# 書き出した JSON から CNAME を取り出し、向き先が解決できるか確認する
for f in ns1-export-*/*.json; do
  jq -r '.records[]? | select(.type=="CNAME") | "\(.domain) \(.short_answers[0])"' "$f"
done | while read -r name target; do
  status=$(dig "$target" A +noall +comments | grep -o 'status: [A-Z]*')
  if [ "$status" != "status: NOERROR" ]; then
    echo "要確認 $name -> $target ($status)"
  fi
done

NXDOMAIN が返る CNAME は、向き先がもう存在しない可能性が高いものです。ただし、名前解決できても、向き先のサービス側で自社のアカウントから外れている場合があります。「要確認」になったものに加えて、外部サービスを指す CNAME は担当者に今も使っているかを確認し、不要なら削除します。

ドメインの有効期限は別に管理する

NS1 の点検で見えるのは DNS の中身だけで、ドメイン自体の契約期限は分かりません。期限切れになると、NS1 の設定が正しくても名前解決できなくなります。ドメインはできるだけ同じレジストラにまとめ、自動更新と支払い方法の有効期限を確認し、更新通知が届くメールアドレスが今も読まれているかを点検の項目に入れておきます。期限は RDAP や whois で調べられますが、表示形式は TLD ごとに異なるため、レジストラの管理画面の一覧と照らし合わせるのが確実性の高い方法です。

点検を続けるための決めごと

• 点検の結果は毎回同じ形式で残し、前回からの差分を見る
• 変更は NS1 の操作履歴（アクティビティの記録）で誰がいつ行ったかを追えるようにし、共有アカウントは使わない
• 「要確認」の対応期限と担当を決め、放置しない
• 点検用のキーは読み取り専用、変更用のキーとは分ける

まとめ

• 複数ドメインの事故は、委任のずれ・DNSSEC の不整合・メール設定の欠落・放置された CNAME・期限切れの五つが中心です。
• 読み取り専用の API キーで全ゾーンを定期的に JSON で書き出し、前回との差分と合わせて点検します。
• DNSSEC は DS の有無と +dnssec・+cd の結果を組み合わせて切り分けます。
• メールを送らないドメインには SPF の -all、DMARC の p=reject、Null MX を置きます。
• API の項目名や管理画面の表記は変わることがあるため、公式ドキュメントで確かめながら運用してください。

• DNSSECを有効にする手順と注意点｜DS レコードの登録から無効化・移転時の落とし穴
• CAAレコードの設定方法｜SSL証明書を発行できる認証局を制限する