Google Cloud DNS と DNSimple を比較する｜Terraform で管理する前提での選び方

Google Cloud DNS と DNSimple は、どちらも権威 DNS をマネージドで任せられるサービスですが、得意な場面がはっきり分かれます。GCP 上にシステムがあり、VPC 内の名前解決や IAM による権限管理まで一体で扱いたいなら Cloud DNS、ドメインの登録・DNS・証明書をひとつの画面と API でまとめたいなら DNSimple が向いています。この記事では、両者の違いを「WordPress サイトの DNS を Terraform でコード管理する」という前提で整理し、選ぶ基準と、乗り換えるときの手順までを説明します。

まず押さえる立ち位置の違い

最初に理解しておきたいのは、両者の守備範囲です。

Google Cloud DNS は、Google Cloud のプロジェクトの中で動く DNS サービスです。ゾーンは「マネージドゾーン」と呼ばれ、インターネットに公開するパブリックゾーンと、指定した VPC ネットワークからだけ引けるプライベートゾーンを作れます。ほかに、社内 DNS へ問い合わせを転送する転送ゾーンや、別の VPC の名前解決を借りるピアリングゾーンもあり、クラウド内部の名前解決まで含めて設計できるのが特徴です。一方で、Cloud DNS 自体はドメインを登録する機能を持たないため、ドメインの登録先（レジストラ）は別に用意する前提で考えます。

DNSimple は、ドメインの登録・更新、DNS ホスティング、SSL 証明書の発行などを一つのアカウントで扱えるサービスです。ドメインを DNSimple で登録すればネームサーバーの設定も同じ画面で完結しますし、他社で登録したドメインの DNS だけを DNSimple に置くこともできます。クラウド事業者に依存しないので、AWS・GCP・国内 VPS などが混在している環境でも中立に使えます。

この「クラウドの一部としての DNS」か「ドメイン運用全体の窓口としての DNS」かという違いが、以下のすべての比較の土台になります。

機能面の違い

WordPress サイトの運用で差が出やすい項目を並べると、次のようになります（2026年10月現在）。各社の公開情報をもとにした整理で、機能や提供条件は変わるため、契約前に公式ドキュメントを確認してください。

いくつか補足します。

頂点ドメインの扱いは、CDN やホスティングサービスに WordPress を載せている場合に効いてきます。DNS の仕様上、example.com のような頂点には CNAME を置けません。DNSimple の ALIAS レコードは、指定したホスト名を DNSimple 側で解決して A / AAAA として返す仕組みなので、頂点でもホスト名で向け先を指定できます。Cloud DNS で同じことをするには、向け先の IP アドレスを A レコードに書くか、Google Cloud のロードバランサーなど IP が固定されるものを前に置く形になります。

権限と監査は、組織で運用するときの大きな差です。Cloud DNS は IAM のロールで「このプロジェクトの DNS だけ編集できる」といった制御ができ、変更は監査ログに残ります。すでに Google Cloud で権限設計をしているなら、DNS を同じ仕組みに乗せられる利点は大きいです。DNSimple は DNS とドメインに特化している分、画面がシンプルで、クラウドの権限設計に詳しくない担当者でも扱いやすい傾向があります。

料金はどちらもゾーン数や問い合わせ量、プランによって決まりますが、体系が異なるうえ改定もあるため、本記事では金額の比較はしません。自分の運用規模（ゾーン数・月間クエリ数・必要なメンバー数）を書き出したうえで、各社の料金ページで見積もるのがいちばん信頼できる判断材料になります。

Terraform で管理したときの書き味

両者とも Terraform のプロバイダが用意されており、レコードをコードとして管理できます。書き方の違いを見ると、運用イメージがつかみやすくなります。

Google Cloud DNS の場合

resource "google_dns_managed_zone" "main" {
  name        = "example-com"
  dns_name    = "example.com."
  description = "WordPress production"
  visibility  = "public"
}

resource "google_dns_record_set" "apex" {
  managed_zone = google_dns_managed_zone.main.name
  name         = google_dns_managed_zone.main.dns_name
  type         = "A"
  ttl          = 3600
  rrdatas      = ["203.0.113.10"]
}

resource "google_dns_record_set" "www" {
  managed_zone = google_dns_managed_zone.main.name
  name         = "www.${google_dns_managed_zone.main.dns_name}"
  type         = "CNAME"
  ttl          = 3600
  rrdatas      = ["example.com."]
}

output "name_servers" {
  value = google_dns_managed_zone.main.name_servers
}

つまずきやすいのは末尾のドットです。dns_name やレコード名、CNAME の向け先は example.com. のように完全修飾名で書きます。ドットを忘れると plan の段階でエラーになるか、意図しない名前になります。また、ゾーンの name は Google Cloud 内での識別子で、ドメイン名そのものではありません。作成後に name_servers を出力し、その値をレジストラに登録して初めて公開されます。

DNSimple の場合

terraform {
  required_providers {
    dnsimple = {
      source = "dnsimple/dnsimple"
    }
  }
}

# 認証情報はコードに書かず、環境変数 DNSIMPLE_TOKEN と DNSIMPLE_ACCOUNT で渡す
provider "dnsimple" {}

resource "dnsimple_zone_record" "apex" {
  zone_name = "example.com"
  name      = ""
  type      = "A"
  value     = "203.0.113.10"
  ttl       = 3600
}

resource "dnsimple_zone_record" "www" {
  zone_name = "example.com"
  name      = "www"
  type      = "CNAME"
  value     = "example.com"
  ttl       = 3600
}

DNSimple のレコード名はゾーンからの相対名で、頂点は空文字で表します。Cloud DNS のように完全修飾名で書く癖のまま name = "www.example.com" とすると、www.example.com.example.com という別の名前ができてしまうので注意してください。古い記事では dnsimple_record というリソース名が使われていることがありますが、現在のプロバイダでは dnsimple_zone_record が案内されています。使っているプロバイダのバージョンのドキュメントで確認しておくと安心です。

どちらでも共通の注意点

• API トークンを Git に入れない: Google Cloud ならサービスアカウントの権限を DNS 管理に絞り、DNSimple ならアクセストークンを環境変数や CI のシークレットで渡します。
• state ファイルを共有ストレージに置く: 複数人で apply する場合、state をローカルに置いたままだと変更が衝突します。リモートバックエンドとロックを用意してから運用を始めます。
• 既存レコードは import で取り込む: 画面で作ったレコードを Terraform で上書きしようとすると、重複エラーになったり、意図せず削除されたりします。インポート時の ID の書式はプロバイダごとに違うため、各リソースのドキュメントで確認します。

選び方の目安

ここまでの違いを踏まえると、判断の軸は次のようにまとめられます。

Google Cloud DNS が合いやすいケース

• WordPress を Compute Engine や GKE、Cloud Run など GCP 上で動かしている
• データベースやキャッシュなど、VPC 内の内部名もあわせて管理したい
• 権限管理や監査ログを Google Cloud の仕組みに統一したい

DNSimple が合いやすいケース

• 複数のクラウドや国内 VPS にサイトが分散していて、DNS は中立な場所に置きたい
• ドメインの登録・更新と DNS を同じ画面で管理したい
• CDN を使っていて、頂点ドメインをホスト名で向けたい（ALIAS を使いたい）

どちらか一方に決めきれない場合、公開 DNS は DNSimple、GCP 内部の名前解決は Cloud DNS のプライベートゾーン、という分担も現実的な選択肢です。

乗り換えるときの手順

どちらからどちらへ移る場合でも、流れは同じです。DNS の移行で多い事故は、メール用の MX や認証用の TXT を移し忘れることなので、レコードの棚卸しを最初に行います。

1. 今のゾーンを書き出す: Cloud DNS なら gcloud dns record-sets export でゾーンファイル形式に出力できます。DNSimple からはゾーンファイルのエクスポート機能や API でレコード一覧を取得します。
2. TTL を短くしておく: 切り替えの前日までに、主要レコードの TTL を 300 秒程度へ下げます。問題が出たときに戻しやすくするためです。
3. 移行先にレコードを作る: Terraform で書く場合は、ここでコード化してしまうと後の管理が楽になります。
4. 移行先のネームサーバーへ直接問い合わせて確認する: dig @移行先のネームサーバー example.com A のように、切り替え前に新しい DNS の応答を確かめます。MX と TXT も同様に確認します。
5. レジストラでネームサーバーを変更する: NS レコードの TTL が切れるまでは新旧両方に問い合わせが来るため、しばらくは旧ゾーンを消さずに残します。

DNSSEC を有効にしている場合は特に注意が必要です。旧 DNS の DS レコードがレジストラに残ったままネームサーバーだけを切り替えると、検証に失敗して名前解決ができなくなります。いったん DNSSEC を解除して DS レコードの TTL が切れるのを待ち、移行後に新しい DNS で改めて有効にする手順が安全です。

まとめ

• Google Cloud DNS は「GCP の一部としての DNS」で、プライベートゾーンや IAM・監査ログとの統合が強みです。ドメイン登録は別途必要です。
• DNSimple は「ドメイン運用の窓口」で、登録・DNS・証明書を一つにまとめられ、ALIAS や URL レコードなど WordPress 運用で便利な機能があります。
• Terraform では、Cloud DNS は完全修飾名と末尾ドット、DNSimple は相対名と頂点の空文字という書き方の違いに注意します。
• 料金と機能の提供範囲は変わるため、運用規模を書き出したうえで公式ドキュメントで確認して選びます。
• 乗り換えはレコードの棚卸し、TTL の短縮、切り替え前の直接問い合わせ、DNSSEC の扱いの順に進めると事故を防げます。

• Terraform の tfstate を安全に管理する方法
• ネームサーバーを変更するときの注意点