お名前.com で管理している DNS を Terraform でコード管理したい場合、まず知っておきたいのは「お名前.com DNS のレコードを操作する公式の Terraform プロバイダーは、執筆時点では確認できていない」という点です。そのため現実的な選択肢は、ドメインの契約はお名前.com に残したまま DNS のホスティングを Route 53 や Cloudflare など公式プロバイダーのある DNS へ移す方法と、お名前.com DNS のまま「あるべき状態」をリポジトリで管理して差分を検出する方法の二つになります。この記事では、両者の選び方と、それぞれの具体的な手順を説明します。
Terraform のプロバイダーや各社の提供状況は変わることがあります。この記事は執筆時点（2026年10月現在）の情報に基づきます。作業前に Terraform Registry と各社の公式ドキュメントで最新の状況を確認してください。
なぜお名前.com DNS を直接 Terraform で扱いにくいのか
Terraform は、プロバイダーが呼び出す API を通じてリソースを作成・変更します。DNS サービス側にレコード操作用の API と、それを使うプロバイダーがなければ、Terraform から直接レコードを変えることはできません。
Terraform Registry には、個人や第三者が公開しているプロバイダーが見つかる場合もあります。ただし、利用者向けに公開された API がないサービスに対しては、管理画面の操作を自動化するなど非公式な手段に頼っていることがあり、次のような問題を抱えがちです。
- 管理画面の変更で突然動かなくなる。
- ログイン情報をプロバイダーに渡す必要があり、漏えい時の影響が大きい。
- サービスの利用規約上、自動操作が認められているかが分からない。
- 更新が止まると、Terraform 本体のバージョンアップについていけなくなる。
試す場合は、公開者・ソースコード・最終更新日・課題の対応状況を確認し、本番ドメインの前に検証用のドメインで動作を確かめてください。この記事では、こうした非公式の手段は推奨しません。
二つの方法の選び方
方法A：DNS を公式プロバイダーのある DNS へ移すのが向いているのは、レコードの変更が頻繁にある場合、複数のドメインや環境をまとめて管理したい場合、プルリクエストでのレビューや CI からの適用まで含めてコード化したい場合です。お名前.com はレジストラとして使い続け、ネームサーバーの登録だけをお名前.com 側で行います。
方法B：お名前.com DNS のまま、状態をリポジトリで管理するのが向いているのは、レコードの変更が年に数回程度で、DNS の移行に伴う作業やリスクを取りたくない場合です。変更そのものは管理画面で行い、「あるべきレコード一覧」と「実際に返ってくる値」をスクリプトで比べて、ずれを見つけます。厳密には Terraform ではありませんが、コード管理の利点の一部（変更履歴、レビュー、ずれの検出）は得られます。
お名前.com のレンタルサーバーやメールなど、お名前.com DNS を前提にしたサービスを使っている場合は、方法Aで DNS を移すとそれらの自動設定が効かなくなることがあります。移す前に、どのサービスがどのレコードに依存しているかを確認してください。
方法A：Route 53 に移して Terraform で管理する
ここでは Route 53 を例にしますが、Cloudflare や Google Cloud DNS にも公式のプロバイダーがあり、流れは同じです。Cloudflare のプロバイダーはメジャーバージョンでリソース名が変わった経緯があるため、参照するドキュメントの版と、自分が使うプロバイダーの版を合わせてください。
手順A-1：現在のレコードを書き出す
お名前.com の管理画面で、対象ドメインの DNS レコード一覧を表示して書き写します。主要な名前は dig で実際の値を確認し、一覧との食い違いがないかを照合します。メール関連（MX、SPF、DKIM、DMARC）と所有権確認用の TXT は写し忘れが多い項目です。
手順A-2：Terraform でゾーンとレコードを定義する
ゾーンとレコードを定義します。状態ファイル（tfstate）にはゾーン ID などが記録されるため、チームで使う場合はリモートのバックエンドに置き、ロックを有効にしておきます。
terraform {
required_version = ">= 1.6.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
resource "aws_route53_zone" "main" {
name = "example.com"
# 誤って terraform destroy などでゾーンを消さないようにする
lifecycle {
prevent_destroy = true
}
}
resource "aws_route53_record" "apex_a" {
zone_id = aws_route53_zone.main.zone_id
name = "example.com"
type = "A"
ttl = 300
records = ["203.0.113.10"]
}
resource "aws_route53_record" "www" {
zone_id = aws_route53_zone.main.zone_id
name = "www.example.com"
type = "CNAME"
ttl = 300
records = ["example.com"]
}
resource "aws_route53_record" "mx" {
zone_id = aws_route53_zone.main.zone_id
name = "example.com"
type = "MX"
ttl = 3600
records = ["10 mail.example.net."]
}
resource "aws_route53_record" "spf" {
zone_id = aws_route53_zone.main.zone_id
name = "example.com"
type = "TXT"
ttl = 3600
records = ["v=spf1 include:_spf.example.net ~all"]
}
output "name_servers" {
value = aws_route53_zone.main.name_servers
}プロバイダーのバージョン指定は例です。実際には、使う時点の最新版と変更履歴を確認して固定してください。TXT の値が 255 文字を超える DKIM 鍵などは、文字列を分割して書く必要がある場合があります。プロバイダーのドキュメントにある書き方に従ってください。
terraform plan で作成内容を確認してから terraform apply を実行すると、Route 53 にゾーンが作られ、出力にネームサーバー4つが表示されます。
手順A-3：切り替える前に Route 53 へ直接問い合わせる
ネームサーバーを切り替える前に、Route 53 が正しい答えを返すかを確かめます。
# 出力されたネームサーバーの1つに直接問い合わせる（名前は実際の出力に置き換える）
dig @ns-123.awsdns-45.com example.com A +noall +answer
dig @ns-123.awsdns-45.com www.example.com CNAME +noall +answer
dig @ns-123.awsdns-45.com example.com MX +noall +answer
dig @ns-123.awsdns-45.com example.com TXT +noall +answer旧 DNS（お名前.com DNS）と同じ答えが返ることを確認できたら、お名前.com 側で主要レコードの TTL を下げ、元の TTL の時間が過ぎるのを待ちます。
手順A-4：お名前.com でネームサーバーを変更する
お名前.com の管理画面で、ドメインのネームサーバーを Terraform の出力に表示された4つに変更します。この操作はレジストラ側の手作業として残りますが、頻度は低いので問題になりにくい部分です。切り替え後は dig +short example.com NS で委任先が変わったことを確かめ、サイトとメールの動作を確認します。お名前.com DNS 側のレコードは、切り替えが行き渡るまでしばらく残しておきます。
運用のポイント
- レコードの変更は、プルリクエストで
terraform planの結果をレビューしてから適用します。CI で plan を自動実行し、結果をコメントに貼る運用にすると見落としが減ります。 - 管理画面から直接レコードを変えると、Terraform の定義とずれます。手作業での変更は原則として行わず、緊急時に変えた場合は定義にも反映させます。
- 既存の Route 53 ゾーンを後から Terraform 管理に取り込む場合は、import ブロックや
terraform importで状態に取り込み、plan で差分が出ないことを確認してから運用に乗せます。
方法B：お名前.com DNS のまま差分を検出する
DNS を移さない場合でも、「あるべき状態」をリポジトリで管理すると、誰がいつ何を変えたかが追え、意図しない変更にも気付けます。次の二つのファイルをリポジトリに置きます。
- names.txt: 確認したい「名前 種別」の一覧
- desired.txt: その名前と種別に対して返るべき値の一覧（下のスクリプトの出力と同じ形式）
#!/usr/bin/env bash
# dns-snapshot.sh: 権威DNSに問い合わせて「名前 種別 値」を1行ずつ出力する
# 使い方: ./dns-snapshot.sh example.com names.txt > actual.txt && diff -u desired.txt actual.txt
set -eu
zone="$1"
list="$2"
# 委任先の権威DNSを1つ選ぶ
ns="$(dig +short "$zone" NS | head -n 1)"
while read -r name type; do
[ -z "${name:-}" ] && continue
case "$name" in '#'*) continue ;; esac
dig +short @"$ns" "$name" "$type" | sort | while read -r value; do
printf '%s %s %s\n' "$name" "$type" "$value"
done
done < "$list"names.txt の例は次のとおりです。
# 名前 種別
example.com A
www.example.com CNAME
example.com MX
example.com TXT
_dmarc.example.com TXT管理画面でレコードを変えるときは、先に desired.txt を書き換えてプルリクエストでレビューし、承認されたら管理画面で同じ変更を行い、最後にスクリプトの結果と desired.txt が一致することを確認します。定期的に CI などで実行すれば、知らないうちにレコードが変わっていた場合にも気付けます。
この方法は、dig で個別に引ける名前しか確認できません。一覧に載せていない名前に追加されたレコードは検出できないため、管理画面の一覧と names.txt を定期的に見比べてください。
まとめ
- お名前.com DNS のレコードを操作する公式の Terraform プロバイダーは、執筆時点では確認できていません。非公式の手段は、動作の安定性・認証情報の扱い・規約の面でリスクがあります。
- 本格的にコード管理したい場合は、ドメインはお名前.com に残し、DNS を Route 53 や Cloudflare など公式プロバイダーのある DNS へ移します。お名前.com 側の作業はネームサーバーの変更だけになります。
- 移すときは、レコードを書き出し、Terraform で定義して新 DNS に直接問い合わせて確かめ、TTL を下げてからネームサーバーを切り替えます。
- DNS を移さない場合は、あるべき状態をリポジトリで管理し、dig の結果との差分を検出する運用でも、変更履歴とずれの検出という利点の一部が得られます。