DNSimple で多数のドメインを管理するときは、アカウントの分け方と権限を先に決め、共通レコードはテンプレートでそろえ、API で全ドメインの状態を定期的に書き出す、という流れにすると、管理画面中心の運用でも取り違えや設定漏れを減らせます。この記事では、Terraform をまだ使わない（または一部のドメインだけ IaC 化している）チーム向けに、その具体的な手順を説明します。
Terraform でレコードを一元管理する方法は、同じシリーズの別記事で扱っています。この記事はそれより手前の段階、「画面と API で運用を整える」ことに絞っています。DNSimple の画面構成や機能の提供範囲はプランや時期によって変わるため（2026年10月現在）、ボタン名などの細部は公式のヘルプで確認してください。
最初に決めること：アカウントの分け方
DNSimple では、ドメインはアカウントに属し、ユーザーは複数のアカウントにメンバーとして参加できます。複数ドメインの管理で後から困りやすいのは、ドメインを置くアカウントの分け方です。
よく使われる分け方は次の2つです。
- 1つのアカウントにまとめる: 自社のドメインだけを管理する場合に向きます。請求と権限の管理が1か所で済みます。
- 顧客や事業ごとにアカウントを分ける: 制作会社が顧客のドメインを預かる場合などに向きます。担当者が顧客のアカウントだけに参加すれば、他の顧客のドメインに触れずに済みます。
迷ったら、「そのドメインの所有者と請求先が誰か」で分けます。後から別アカウントへドメインを移すことはできますが、作業と確認の手間がかかります。
あわせて、メンバーに与える権限を見直します。DNS の変更はサイトやメールを止める操作なので、日常的にレコードを触る人と、ドメインの登録・移管・更新設定を扱う人を分けておくと安全です。退職や契約終了のときにメンバーを外す手順も、棚卸しの一部として決めておきます。
ドメインごとに確認しておく設定
アカウントに入れたドメインごとに、次の項目を確認して一覧にまとめます。
- ネームサーバーが DNSimple を向いているか: DNSimple でレジストラだけ使い、DNS は別の事業者という構成もあり得ます。その場合、DNSimple のレコードを編集しても効きません。
- 自動更新: 登録しているドメインは、自動更新が有効か、支払い方法が有効かを確認します。
- DNSSEC: 有効にしている場合、レジストラ側の DS レコードと整合しているかを確認します。
- WHOIS の公開設定: 個人名や住所が公開されていないかを確認します。
ネームサーバーは次のように確かめます。DNSimple を使っている場合、dnsimple.com 系のネームサーバー名が返ります（具体的な名前は自分のアカウントの表示で確認してください）。
dig +short example.com NS共通レコードはテンプレートでそろえる
DNSimple には、レコードの組み合わせを「テンプレート」として保存し、ドメインに適用する機能があります。複数ドメインで同じ構成を使う場合、これを使うと入力の手間と入力ミスを減らせます。
例えば次のような単位でテンプレートを作ります。
- Web 公開用: www の CNAME、ルートドメインの ALIAS、CAA
- メール利用: MX、SPF の TXT、DMARC の TXT
- 送信しないドメイン用:
v=spf1 -allの TXT と、拒否ポリシーの DMARC
ルートドメイン（example.com そのもの）は DNS の仕様上 CNAME を置けませんが、DNSimple の ALIAS レコードを使うと、ホスト名を向き先にした設定ができます。CDN やホスティングサービスがホスト名での設定を求める場合に役立ちます。
テンプレートについて注意したいのは、適用は「その時点でレコードを追加する操作」として扱われる点です。テンプレートを後から修正しても、すでに適用したドメインへ自動で反映されるとは限りません。テンプレートを変えたら、適用済みのドメインを一覧で確認し、必要なものを個別に直します。適用前に、同じ名前の既存レコードと重複しないかも確認してください。
API で全ドメインの状態を書き出す
ドメインが増えると、画面を1件ずつ開いて確認するのは現実的ではありません。DNSimple には API（v2）があり、読み取り専用の用途から始めると安全に導入できます。
トークンは管理画面で発行します。アカウント単位のトークンを使い、スクリプトにはトークンを直接書かず、環境変数で渡します。トークンを Git に入れたり、チャットに貼ったりしないでください。
#!/usr/bin/env bash
# 事前に: export DNSIMPLE_TOKEN=your-api-token
# export DNSIMPLE_ACCOUNT=12345
set -euo pipefail
API="https://api.dnsimple.com/v2"
AUTH="Authorization: Bearer ${DNSIMPLE_TOKEN}"
out="dnsimple-$(date +%Y%m%d)"
mkdir -p "$out"
# ドメイン一覧（1ページ100件、ページ送りしながら取得）
page=1
while :; do
res=$(curl -fsS -H "$AUTH" -H "Accept: application/json" \
"$API/$DNSIMPLE_ACCOUNT/domains?page=$page&per_page=100")
echo "$res" | jq -r '.data[] | [.name, .state, (.auto_renew|tostring), (.expires_at // "")] | @tsv' >> "$out/domains.tsv"
total=$(echo "$res" | jq '.pagination.total_pages')
[ "$page" -ge "$total" ] && break
page=$((page+1))
done
# ドメインごとにゾーンファイルを保存
cut -f1 "$out/domains.tsv" | while read -r d; do
curl -fsS -H "$AUTH" -H "Accept: application/json" \
"$API/$DNSIMPLE_ACCOUNT/zones/$d/file" | jq -r '.data.zone' > "$out/$d.zone" || echo "skip: $d"
done
echo "saved to $out/"アカウント ID は、トークンを使って GET /v2/whoami を呼ぶと確認できます。検証は本番ではなく、DNSimple が用意しているサンドボックス環境（api.sandbox.dnsimple.com）で先に試すと安心です。サンドボックスは本番とは別のアカウントとトークンが必要です。
レスポンスの項目名は API ドキュメントで確認し、自分の環境で一度出力を見てから使ってください。保存したゾーンファイルは、前回分と diff で比べると、意図しない変更に気づけます。
diff -r dnsimple-20260901 dnsimple-20261001変更作業の進め方
複数ドメインに同じ変更を入れるときは、次の順で進めます。
- 上のスクリプトで現在のゾーンを保存しておく（戻すときの控えになります）
- 変更するレコードの TTL を前もって下げておく
- 影響の小さいドメインから1件ずつ変更する
- 権威サーバーに直接問い合わせて、新しい値が返るか確かめる
- サイトの表示やメールの送受信を確認してから、次のドメインへ進む
ns=$(dig +short example.com NS | head -n1)
dig +short example.com A @"$ns"API でレコードの変更まで自動化することもできますが、まずは読み取りと書き出しで運用を安定させ、変更の自動化は対象と手順を決めてから段階的に広げるほうが安全です。
Terraform へ移るタイミング
次のような状況になったら、Terraform などの IaC での管理を検討する段階です。
- 同じ変更を多数のドメインへ頻繁に入れる
- 変更内容をレビューしてから反映したい
- 誰がいつ何を変えたかを Git の履歴で追いたい
ただし、Terraform で管理するドメインのレコードを画面やテンプレートでも変更すると、定義と実際の状態がずれます。IaC 化したドメインは画面からの変更をやめる、とチーム内で決めてから移行してください。
まとめ
- アカウントの分け方は、ドメインの所有者と請求先で決め、メンバーの権限は役割で分けます。
- ドメインごとにネームサーバー、自動更新、DNSSEC、WHOIS の公開設定を一覧で確認します。
- 共通レコードはテンプレートでそろえますが、テンプレートの修正は適用済みのドメインへ自動では及ばない前提で扱います。
- API のトークンは環境変数で渡し、まずは読み取り専用でドメイン一覧とゾーンを定期的に書き出します。
- 変更が増えたら IaC へ移り、移したドメインは画面から触らないルールにします。