2026年6月12日

ConoHa DNS で複数ドメインを管理する方法｜台帳づくり・共通レコードのそろえ方・API での一括確認

DNS・名前解決

ConoHa DNS で扱うドメインが増えてきたら、レコードの入れ方よりも「どのドメインが何に使われ、どこを向いているか」を把握し続けることが課題になります。台帳を1つ作り、用途ごとに入れるレコードの型を決め、外からの dig と API の出力で定期的に照らし合わせる、という3点をそろえると、数十ドメインでも迷わず管理できます。この記事では、その手順と、ドメインを追加・廃止するときの流れ、放置したレコードが招く危険を説明します。

ConoHa のコントロールパネルの構成、DNS の API の仕様、ネームサーバー名は、サービスの世代や更新によって変わることがあります（2026年10月現在）。画面の表記は一般的な言い方で書くので、実際の操作は使っている環境の ConoHa のヘルプと API ドキュメントで確認してください。

対象を確かめる：どの「ConoHa の DNS」か

ConoHa には、VPS などのコントロールパネルで使う DNS と、レンタルサーバーの ConoHa WING のドメイン設定があり、管理する場所が異なります。この記事は VPS 側の DNS を前提にします。また VPS にも世代の違いがあり、コントロールパネルや API の接続先が別になっています。複数のドメインが別々の世代や別々のアカウントに分かれていると、それだけで把握が難しくなるので、最初にどこに何があるかを確認します。

ConoHa DNS は、ドメインをどこで登録したかに関係なく使えます。レジストラ側でネームサーバーを ConoHa のものに設定すれば、ConoHa に登録したレコードが使われます。逆に言えば、ConoHa の画面にゾーンがあっても、ネームサーバーが別の事業者を向いていれば、そのレコードは使われていません。複数ドメインの管理で最初につまずくのはこの食い違いです。

手順1：ドメインの台帳を作る

表計算ソフトなどで、ドメインごとに次の項目を1行にまとめます。

ドメイン名、登録しているレジストラ、有効期限
ネームサーバー（ConoHa か、それ以外か）
用途（WordPress サイト、メール、リダイレクトのみ、保有のみ）
向け先のサーバーの IP、使っているメールサービス
担当者、メモ（いつ何のために取ったか）

台帳を作る意味は、有効期限やメールの設定のように、ConoHa の DNS の画面だけでは分からない情報を一緒に見られることです。ドメインの登録先が ConoHa 以外にもある場合、更新の管理はそれぞれのレジストラで行うので、期限の列は特に重要です。

手順2：外から一括で状態を確かめる

台帳に書いた内容が実際の DNS と合っているかを、dig でまとめて確かめます。domains.txt に1行1ドメインで並べて実行します。

# 各ドメインの NS・頂点の A・MX・SPF・DMARC を一覧にする
while read -r d; do
  [ -z "$d" ] && continue
  echo "== $d"
  echo "NS:    $(dig +short NS "$d" | sort | tr '\n' ' ')"
  echo "A:     $(dig +short A "$d" | tr '\n' ' ')"
  echo "MX:    $(dig +short MX "$d" | tr '\n' ' ')"
  echo "SPF:   $(dig +short TXT "$d" | grep -i 'v=spf1')"
  echo "DMARC: $(dig +short TXT "_dmarc.$d")"
done < domains.txt > dns-check-$(date +%Y%m%d).txt

NS に ConoHa 以外の名前が出るドメインは、ConoHa の画面で何を変えても反映されません。台帳と照らして、ネームサーバーを変える予定なのか、ConoHa 側のゾーンが不要になっているのかを判断します。結果をファイルに残しておくと、次回の点検で diff を取るだけで変化に気づけます。

手順3：用途ごとにレコードの型を決める

ドメインごとに思いつきでレコードを入れていると、メール認証の設定がドメインによって違う、といったばらつきが生まれます。用途ごとに「入れるレコードの型」を決めておき、新しいドメインにはその型を当てはめます。

WordPress サイトのドメインは、頂点の A（IPv6 を使うなら AAAA）、www の CNAME または A、証明書を発行する認証局を限る CAA を基本にします。CAA を入れる場合は、サーバーで使っている証明書の発行元を確かめてからにします。

メールを送るドメインは、SPF、DKIM、DMARC をそろえます。SPF は1つのドメインに1つのレコードにまとめ、DMARC は最初は p=none で集計を受け取り、問題がないのを確かめてから強めます。

メールを使わないドメインは、なりすましの送信元に使われないよう、「このドメインからはメールを送らない」と宣言するレコードを入れておくと安全です。

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

最後の行は「このドメインはメールを受け取らない」ことを示す MX（Null MX）です。ConoHa の入力欄で値 . を受け付けるかどうかは画面で確かめ、受け付けない場合は SPF と DMARC だけでも効果があります。

リダイレクトだけのドメインは、301 を返すサーバーへの A だけにして、ほかのレコードを残さないようにします。

手順4：API でゾーンとレコードを書き出す

ConoHa の画面ではドメインを1つずつ開いて確認することになるため、数が増えたら API で一覧を書き出すと手間が減ります。流れは、API 用の認証情報からトークンを発行し、そのトークンを X-Auth-Token ヘッダーに付けて DNS の API に問い合わせる、という形です。トークンの発行方法と DNS の API の接続先は世代によって異なるので、コントロールパネルに表示される API の情報とドキュメントで確認します。

# 接続先とトークンは自分の環境のものに置き換える（スクリプトに直書きしない）
DNS_EP="https://dns-service.example.conoha.io"
TOKEN="$(cat ~/.conoha-token)"

# ドメイン（ゾーン）の一覧
curl -s -H "Accept: application/json" -H "X-Auth-Token: $TOKEN" \
  "$DNS_EP/v1/domains" | jq -r '.domains[] | "\(.id)\t\(.name)"'

# 1つのドメインのレコード一覧を保存する
curl -s -H "Accept: application/json" -H "X-Auth-Token: $TOKEN" \
  "$DNS_EP/v1/domains/your-domain-id/records" > records-example.json

応答の項目名はドキュメントで確認してください。ドメイン名は末尾にドットが付いた形（example.com.）で返ることがあるので、台帳と照らすときは表記をそろえます。API 用の認証情報は、権限を絞ったファイルや環境変数で渡し、リポジトリや共有のチャットには貼りません。トークンには有効期限があるため、定期実行するスクリプトでは発行からやり直す処理を入れます。

手順5：ドメインを追加・廃止するときの流れ

追加するときは、ConoHa にゾーンを作り、手順3の型に沿ってレコードを入れ、ネームサーバーを切り替えてから台帳に記入します。ほかの DNS から移してくる場合は、移す前に元の DNS のレコードをすべて書き出し、TTL を短くしておきます。DNSSEC を使っていたら、先にレジストラの DS レコードを外します。

廃止するときは、順番に注意します。

そのドメインのメールアドレスを、ほかのサービスのログイン ID や連絡先に使っていないか確かめ、変えておきます。
外部サービスを指す CNAME を消します。使わなくなったサービスを指す CNAME が残っていると、そのサービス上で第三者に名前を使われることがあります（サブドメインの乗っ取り）。
ネームサーバーを別の場所へ移す、またはドメインを手放すと決めてから、ConoHa のゾーンを削除し、台帳から外します。

つまずきやすい点

同じドメインのゾーンが複数ある：別のアカウントや別の世代の環境に同じドメインのゾーンが残っていると、どれが使われているのか分からなくなります。ネームサーバーの名前で使われている側を見分け、使われていないほうは整理します。
TTL がドメインごとにばらばら：普段は長め、切り替えの前だけ短く、という方針を型に入れておくと、作業のたびに迷いません。
点検が続かない：手順2のスクリプトを月に1回実行し、前回との差分だけを見る形にすると負担が小さくなります。

まとめ

複数ドメインの管理は、台帳、用途ごとのレコードの型、定期的な照合の3点で考えます。
ConoHa の画面のゾーンが使われているかは、dig で NS を引いて確かめます。
メールを使わないドメインには、送信しないことを示す SPF と DMARC を入れておきます。
数が増えたら API でゾーンとレコードを書き出し、台帳と照らし合わせます。
廃止するときは、メールアドレスの利用と外部を指す CNAME を先に片付けてから、ゾーンを削除します。