Cloud DNS の概要

このページでは、Cloud DNS の特長と機能の概要について説明します。Cloud DNS は、高パフォーマンスで復元力を備えたグローバル ドメイン ネーム システム（DNS）サービスで、費用対効果の高い方法でグローバル DNS にドメイン名を公開します。

DNS は、IP アドレスやその他のデータを格納し、名前でそれらを検索できる階層型分散データベースです。Cloud DNS を使用すると、独自に DNS サーバーやソフトウェアを管理する負担なく、ゾーンとレコードを DNS で公開できます。

Cloud DNS は、一般公開ゾーンと限定公開マネージド DNS ゾーンの両方を提供します。一般公開ゾーンは公共のインターネットに公開され、限定公開ゾーンは指定した 1 つ以上の Virtual Private Cloud（VPC）ネットワークにのみ公開されます。ゾーンの詳細については、DNS ゾーンの概要をご覧ください。

Cloud DNS は、プロジェクト レベルと個々の DNS ゾーンレベルの Identity and Access Management（IAM）権限をサポートします。個々のリソースの IAM 権限を設定する方法については、特定の IAM 権限を持つゾーンを作成するをご覧ください。

一般的な DNS 用語のリストについては、一般的な DNS の概要をご覧ください。

Cloud DNS の主な用語については、主な用語をご覧ください。

Cloud DNS の使用を開始するには、クイックスタートをご覧ください。

使ってみる

Google Cloud を初めて使用される方は、アカウントを作成して、実際のシナリオでの Cloud DNS のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Cloud DNS 無料トライアル

共有 VPC に関する考慮事項

共有 VPC で Cloud DNS 限定公開マネージド ゾーン、Cloud DNS 転送ゾーン、または Cloud DNS ピアリング ゾーンを使用するには、ホスト プロジェクトにゾーンを作成し、そのゾーンの承認済みネットワークのリストに 1 つ以上の共有 VPC ネットワークを追加する必要があります。また、クロス プロジェクト バインディングを使用して、サービス プロジェクト内にゾーンを設定することもできます。

詳しくは、Cloud DNS 限定公開ゾーンのベスト プラクティスをご覧ください。

DNS 転送の方式

Google Cloud の限定公開ゾーンでは、受信 DNS 転送と送信 DNS 転送を利用できます。DNS 転送は、転送ゾーンまたは Cloud DNS サーバー ポリシーを作成することで構成できます。次の表に、この 2 つの方法をまとめます。

DNS 転送 Cloud DNS 方式
受信

受信サーバー ポリシーを作成して、オンプレミスの DNS クライアントまたはサーバーが DNS リクエストを Cloud DNS に送信できるようにします。DNS クライアントまたはサーバーは、VPC ネットワークの名前解決順序に従ってレコードを解決できます。

オンプレミス クライアントは、VPC ネットワークが承認済みとなっている限定公開ゾーン、転送ゾーン、ピアリング ゾーンでレコードを解決できます。オンプレミス クライアントは、Cloud VPN または Cloud Interconnect を使用して VPC ネットワークに接続します。
送信

VPC ネットワーク内の VM を構成して、次の操作を実施できます。

  • DNS リクエストは、任意の DNS ネームサーバーに送信します。ネームサーバーは、同じ VPC ネットワーク内、1 つのオンプレミス ネットワーク、またはインターネット上に配置できます。
  • VPC ネットワークで転送ゾーンの使用が承認されている場合に、その転送ゾーンの転送先として構成されているネームサーバーでホストされているレコードを解決します。 Google Cloudで転送先の IP アドレスにトラフィックがルーティングされる方法については、転送先とルーティング方法をご覧ください。
  • VPC ネットワーク用の送信サーバー ポリシーを作成し、すべての DNS リクエストを代替ネームサーバーに送信します。代替ネームサーバーを使用すると、VPC ネットワーク内の VM が Cloud DNS 限定公開ゾーン、転送ゾーン、ピアリング ゾーン、Compute Engine 内部 DNS ゾーン内のレコードを解決できなくなります。詳細については、名前解決の順序をご覧ください。

VPC ネットワークの受信 DNS 転送と送信 DNS 転送を同時に構成できます。双方向転送を使用すると、VPC ネットワーク内の VM が、オンプレミス ネットワーク内のレコードも、別のクラウド プロバイダでホストされているネットワーク内のレコードも解決できます。このタイプの転送では、オンプレミス ネットワーク内のホストがGoogle Cloud リソースのレコードを解決することもできます。

Cloud DNS のコントロール プレーンは、転送先の選択順序に従って転送先を選択します。転送先に到達できない場合や転送先がすぐに応答しない場合は、送信転送クエリで SERVFAIL エラーが発生することがあります。トラブルシューティングの手順については、送信転送クエリが SERVFAIL エラーを受け取るをご覧ください。

サーバー ポリシーを適用する方法については、DNS サーバー ポリシーの作成をご覧ください。転送ゾーンを作成する方法については、転送ゾーンの作成をご覧ください。

DNSSEC

Cloud DNS はマネージド DNSSEC をサポートしており、なりすまし攻撃やキャッシュ汚染攻撃からドメインを保護します。Google Public DNS などの検証リゾルバを使用すると、DNSSEC によりドメイン ルックアップの強力な認証機能が提供されます（暗号化は行われません）。DNSSEC について詳しくは、DNSSEC 構成の管理をご覧ください。

DNS64（プレビュー）

Cloud DNS の DNS64 を使用すると、IPv6 専用の Compute Engine 仮想マシン（VM）インスタンス（プレビュー）を IPv4 の宛先に接続できます。DNS64 では、合成された IPv6 アドレスが IPv4 の宛先ごとに提供されます。この合成アドレスは、Well-Known Prefix（WKP）の 64:ff9b::/96 と 32 ビットの宛先 IPv4 アドレスを組み合わせることによって作成されます。

IPv6 専用 VM インスタンス（プレビュー）がインターネット上の IPv4 宛先と通信できるようにするには、Public NAT（NAT64）で DNS64 とネットワーク アドレス変換を設定します。NAT64 を構成する際は、Cloud NAT ゲートウェイを作成するの手順に沿って操作します。

次の例は、vmipv6 という名前の IPv6 専用 VM インスタンス（プレビュー）が IPv4 専用の宛先の名前を解決する方法を示しています。

  1. VM インスタンス vmipv6 が、宛先の名前を IPv6 アドレスに解決するための DNS リクエストを開始します。

  2. AAAA レコード（IPv6 アドレス）が存在する場合は、Cloud DNS から IPv6 アドレスが返され、VM インスタンス vmipv6 はそのアドレスを使用して宛先に接続します。

  3. AAAA レコードが存在しない場合、DNS64 が構成済みであれば、Cloud DNS で A レコード（IPv4 アドレス）が検索されます。A レコードが見つかった場合は、その IPv4 アドレスに 64:ff9b::/96 が接頭辞として追加されて AAAA レコードが合成されます。

DNS64 では、IPv4 アドレスが合成 IPv6 アドレスに変換される。
DNS64 では、IPv4 アドレスが合成 IPv6 アドレスに変換される（クリックして拡大）。

たとえば、IPv4 アドレスが 32.34.50.60 の場合、合成された IPv6 アドレスは 64:ff9b::2022:323c になります（2022:323c はこの IPv4 アドレスの 16 進数表現です）。64:ff9b::/96 の接頭辞は RFC 6052 で定義されています。DNS レコードをオンプレミスでホストしている場合も、Cloud DNS で DNS 転送を有効にしている限り、このような IPv6 アドレスが合成されます。

DNS64 は、次のシナリオで使用できます。

  • IPv4 アドレスを割り当てずに IPv6 アドレスへの移行を義務付ける規制に準拠する。
  • 既存の IPv4 インフラストラクチャへのアクセスを維持しながら、段階的に IPv6 のみのアドレス インフラストラクチャに移行する。
  • IPv6 アドレスへの移行中に、従来の IPv4 アドレスを使用する環境への継続的なアクセスを確保することで、重要なサービスの中断を回避する。

VPC ネットワーク用に DNS64 を構成するには、DNS64 を構成するの手順に沿って操作します。

アクセス制御

Google Cloud コンソールの [IAM と管理] ページで、DNS レコードへの変更を許可されたユーザーを管理できます。変更を承認されたユーザーは、Google Cloud コンソールの [権限] セクションに DNS 管理者ロール（roles/dns.admin）が表示されています。DNS 読み取りロール（roles/dns.reader）は、Cloud DNS レコードに対する読み取り専用アクセス権を付与します。

これらの権限は、DNS サービスの管理に使用できるサービス アカウントにも適用されます。

これらのロールに割り当てられている権限については、ロールをご覧ください。

マネージド ゾーンのアクセス制御

プロジェクトのオーナーまたは編集者のロール（roles/owner または roles/editor）を持つユーザーは、管理している特定のプロジェクトのマネージド ゾーンを管理または表示できます。

DNS 管理者または DNS の読み取りのロールを持つユーザーは、アクセス権を持つすべてのプロジェクトのマネージド ゾーンを管理または表示できます。

プロジェクト オーナー、編集者、DNS 管理者、DNS の読み取りのロールを持つユーザーは、現在のプロジェクトの任意の VPC ネットワークに適用されている限定公開ゾーンのリストを表示できます。

リソースごとの権限アクセス

マネージド ゾーンなどの DNS リソースでポリシーを構成するには、そのリソースを所有するプロジェクトに対するオーナー アクセス権が必要です。DNS の管理者ロールに setIamPolicy 権限はありません。プロジェクト オーナーは、特定のニーズに合わせてカスタム IAM ロールを作成することもできます。詳細については、IAM カスタムロールについてをご覧ください。

パフォーマンスとタイミング

Cloud DNS は、エニーキャストを使用して、全世界の複数のロケーションからマネージド ゾーンをサポートし、高い可用性を提供します。リクエストは最も近いロケーションに自動的にルーティングされるため、レイテンシが低減され、ユーザーの権威名の検索パフォーマンスが改善されます。

変更の伝播

変更は、2 段階で伝播されます。まず、API またはコマンドライン ツールを介して送信する変更を、Cloud DNS の権威 DNS サーバーに push する必要があります。次に、DNS リゾルバがレコードのキャッシュ期限が切れたときにこの変更をピックアップする必要があります。

DNS リゾルバのキャッシュは、レコードに設定した有効期間（TTL）値（秒単位で指定）で制御されます。たとえば、TTL 値を 86,400（24 時間の秒数）に設定すると、DNS リゾルバにレコードを 24 時間キャッシュ保存することを指示したことになります。一部の DNS リゾルバでは、TTL 値を無視したり、レコードの完全な伝播を遅延させたりすることができる独自の値を使用します。

時間枠が非常に限られているサービスに対する変更を計画している場合は、その変更を行う前に、TTL の値を短くするとよい場合があります。更新した短い TTL 値は、リゾルバ キャッシュ内の以前の TTL 値の有効期限が切れた後に適用されます。この方法は、キャッシングの時間枠を短縮して、新しいレコードの設定に変更をより迅速に反映するのに効果的です。変更したら、TTL の値を元に戻して、DNS リゾルバの負荷を軽減できます。

次のステップ