Google Cloud DNS と DNSimple は、どちらも権威 DNS を任せられるマネージドサービスですが、向いている運用の形が違います。Google Cloud の中にシステムがあり、権限や監査を Google Cloud の仕組みにそろえたいなら Cloud DNS、ドメインの登録から DNS・証明書までを一つの窓口で扱いたいなら DNSimple が候補になります。この記事では、Terraform などのコード管理を前提にせず、管理画面と CLI で WordPress サイトの DNS を運用する立場から、日々の変更作業、権限の分け方、DNSSEC、障害時の切り替え、乗り換えやすさの5つの観点で両者を比べます。
なお、機能や提供条件、画面の構成は改定されることがあります。本記事は各社の公開情報をもとに整理しています（2026年10月現在）。契約や移行の前には、各社の公式ドキュメントで最新の内容を確認してください。料金は体系が異なり改定もあるため、本記事では扱いません。
前提となる立ち位置の違い
Cloud DNS は Google Cloud のプロジェクトの中で動くサービスです。ゾーンは「マネージドゾーン」と呼ばれ、インターネットに公開するパブリックゾーンのほか、指定した VPC からだけ引けるプライベートゾーンも作れます。Cloud DNS 自体はレジストラではないため、ドメインの登録と更新は別の事業者で行い、その事業者の管理画面で Cloud DNS のネームサーバーを指定する形になります。
DNSimple は、ドメインの登録・更新、DNS ホスティング、SSL 証明書などを一つのアカウントで扱うサービスです。DNSimple でドメインを登録すればネームサーバーの設定まで同じ画面で完結し、他社で登録したドメインの DNS だけを置くこともできます。特定のクラウドに依存しないため、サーバーが国内 VPS や複数のクラウドに分散していても中立に使えます。
つまり、Cloud DNS は「クラウド基盤の部品としての DNS」、DNSimple は「ドメイン運用の窓口としての DNS」です。以下の違いは、ほとんどがこの立ち位置から生まれています。
観点1：日々のレコード変更のしやすさ
WordPress サイトの運用で発生する DNS 作業は、サーバー移転に伴う A レコードの書き換え、メールサービス用の MX や TXT の追加、外部サービスの所有権確認用 TXT の追加などが中心です。
Cloud DNS では、Google Cloud コンソールのゾーン画面からレコードセットを追加・編集します。同じ名前と種類のレコードは「レコードセット」として一つにまとめて扱うため、TXT を2つ並べたいときは、一つのレコードセットに値を2つ入れる形になります。この考え方に慣れていないと、2つ目の TXT を別に作ろうとして重複エラーになることがあります。CLI の gcloud からも同じ操作ができ、作業手順を文書化しやすいのは利点です。
# Cloud DNS：ゾーン内のレコードを一覧する（ゾーン名は Google Cloud 内の識別子）
gcloud dns record-sets list --zone=example-comDNSimple は、ドメインごとのレコード一覧から種類を選んで追加する、一般的な DNS 管理画面に近い操作です。名前はドメインからの相対名で入れ、頂点は空欄にします。頂点ドメインを CDN などのホスト名へ向けたいときは、DNSimple 独自の ALIAS レコードを使えます。簡単な URL 転送用のレコードもあるため、旧ドメインから新ドメインへ転送するだけなら Web サーバー側の設定を用意せずに済む場合があります。
Google Cloud を普段から触っている担当者には Cloud DNS のほうが迷いが少なく、DNS 以外のクラウド操作に慣れていない担当者には DNSimple のほうが直感的に感じられることが多いでしょう。
観点2：権限の分け方と変更の記録
複数人で運用すると、「誰がどのドメインを変えられるか」と「いつ誰が何を変えたか」が問題になります。
Cloud DNS は Google Cloud の IAM で権限を管理します。DNS の管理者向けには roles/dns.admin、閲覧だけなら roles/dns.reader といった事前定義ロールがあり、プロジェクト単位で付与するのが基本です。ドメインごとに担当を分けたい場合は、プロジェクトを分ける、またはゾーン単位での権限付与が使えるかを確認する、といった設計が必要になります。変更は Cloud Audit Logs に記録されるため、既存の監査の仕組みにそのまま乗せられます。
DNSimple は、アカウントにメンバーを招待して権限を管理します。どこまで細かく分けられるか、変更履歴をどの範囲まで見られるかはプランによって異なるため、複数人で使う予定があるなら契約前に確認しておきます。
組織としてすでに Google Cloud の権限設計や監査ログの運用をしているなら、DNS も同じ仕組みに乗せられる Cloud DNS の利点は大きくなります。逆に、DNS のためだけに IAM の設計を学ぶのは負担が大きい、という小規模な運用では DNSimple の単純さが合います。
観点3：DNSSEC の扱い
DNSSEC は、DNS の応答が改ざんされていないことを検証できるようにする仕組みです。どちらのサービスも対応していますが、手順の重さが違います。
Cloud DNS では、ゾーンごとに DNSSEC を有効にでき、鍵の生成や署名の更新は Cloud DNS が行います。有効にしたあと、表示される DS レコードの情報をレジストラに登録して初めて検証が成立します。レジストラが別の事業者なので、この登録は自分で行う必要があります。
# Cloud DNS：ゾーンの DNSSEC を有効にする
gcloud dns managed-zones update example-com --dnssec-state=on
# 登録する DS レコードの情報を確認する（出力の形式はバージョンにより異なる）
gcloud dns dns-keys list --zone=example-comDNSimple では、DNSimple で登録しているドメインなら、DNSSEC の有効化と DS レコードの登録を同じアカウントの中で進められます。他社で登録したドメインの場合は、Cloud DNS と同じく DS レコードを自分でレジストラに登録します。
どちらを選ぶ場合も、DNSSEC を有効にしたままネームサーバーだけを切り替えると、古い DS レコードと新しい DNS の鍵が合わずに名前解決ができなくなります。乗り換えの際は、DNSSEC の扱いを最初に計画に入れておきます。
観点4：障害時の切り替え
WordPress サイトのサーバーが止まったときに、DNS で予備のサーバーやメンテナンス画面へ切り替えたい、という要望はよくあります。
Cloud DNS には、重み付けラウンドロビン、地域による振り分け、フェイルオーバーといったルーティングポリシーがあり、ヘルスチェックと組み合わせて応答を切り替える構成が取れます。ただし、ヘルスチェックの対象にできるリソースの種類や組み合わせには条件があるため、構成を決める前に公式ドキュメントで対応範囲を確認してください。Google Cloud のロードバランサーを前に置いているなら、切り替えはロードバランサー側で行い、DNS は固定の IP を返すだけにするほうが単純になることもあります。
DNSimple は DNS ホスティングとドメイン管理が中心で、ヘルスチェックによる自動切り替えを DNS の中心機能として打ち出しているサービスではありません。DNS で自動フェイルオーバーをしたい場合は、監視サービスと API を組み合わせて自分で切り替える、あるいはその用途に強い別のサービスを併用する、といった設計になります。
手動で切り替える運用なら、どちらでも差は小さく、重要なのは「切り替えるレコードの TTL を普段から短めにしておくこと」と「手順を文書にしておくこと」です。
観点5：乗り換えやすさと冗長化
将来の乗り換えや、別の DNS 事業者との併用（セカンダリ DNS）を考えるなら、ゾーンを外に出しやすいかも見ておきます。
Cloud DNS は、ゾーンファイル形式での書き出しと取り込みに対応しています。
# Cloud DNS：ゾーンをゾーンファイル形式で書き出す／取り込む
gcloud dns record-sets export example-com.zone --zone=example-com --zone-file-format
gcloud dns record-sets import example-com.zone --zone=example-com --zone-file-format一方で、Cloud DNS は外部のセカンダリ DNS へのゾーン転送には対応していないと案内されています。2社の DNS で同じゾーンを提供したい場合は、両方に同じレコードを書き込む仕組みを自分で用意する必要があります。
DNSimple はゾーンファイルの書き出しや API でのレコード取得ができ、セカンダリ DNS との連携機能も提供しています。どの事業者と組み合わせられるか、どのプランで使えるかは変わることがあるため、冗長化を重視する場合は事前に確認します。
選び方の目安
Cloud DNS が合いやすいのは、次のような場合です。
- WordPress を Compute Engine や GKE、Cloud Run など Google Cloud 上で動かしている
- VPC 内の内部名もあわせて管理したい
- 権限と監査を Google Cloud の IAM と Cloud Audit Logs にそろえたい
- ルーティングポリシーとヘルスチェックを使った切り替えを DNS で組みたい
DNSimple が合いやすいのは、次のような場合です。
- サーバーが複数の事業者に分散していて、DNS は中立な場所に置きたい
- ドメインの登録・更新、DNS、DNSSEC をひとつの画面で扱いたい
- 頂点ドメインを ALIAS で CDN へ向けたい、簡単な URL 転送も DNS で済ませたい
- セカンダリ DNS で冗長化したい
どちらか一方に決めきれない場合は、公開 DNS を DNSimple、Google Cloud 内部の名前解決を Cloud DNS のプライベートゾーン、という分担も選択肢になります。
まとめ
- Cloud DNS は Google Cloud の一部としての DNS で、IAM・監査ログ・プライベートゾーン・ルーティングポリシーとの統合が強みです。ドメイン登録は別の事業者で行います。
- DNSimple はドメイン運用の窓口で、登録・DNS・DNSSEC・証明書をまとめて扱え、ALIAS や URL 転送など小規模運用で便利な機能があります。
- Cloud DNS は同じ名前と種類のレコードを「レコードセット」としてまとめる点、DNSimple は名前を相対名で入れる点が、操作上の主なつまずきどころです。
- DNSSEC はどちらでも使えますが、乗り換え時は DS レコードの扱いを最初に計画します。
- 冗長化や将来の乗り換えを考えるなら、ゾーンの書き出しとセカンダリ DNS への対応状況を契約前に確認します。