概要

このページでは、Cloud DNS の特長と機能の概要について説明します。Cloud DNS の使用を開始するには、クイックスタートをご覧ください。

はじめに

Cloud DNS は、高パフォーマンスで復元力を備えたグローバル ドメインネーム システム(DNS)サービスで、費用対効果の高い方法でグローバル DNS にドメイン名を公開します。

コンセプト

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

DNS の一般的なコンセプト

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

Cloud DNS は、一般公開および限定公開のマネージド DNS ゾーンの両方を提供します。一般公開マネージド ゾーンは、公共のインターネットを通して表示され、限定公開ゾーンは、指定した 1 つ以上の VPC ネットワークでのみ表示されます。

限定公開ゾーンを使用すると、VPC ネットワークに固有の異なる DNS レコードセットを持つ限定公開ゾーンを作成し、スプリット ホライズン DNS 構成を作成できます。

Cloud DNS のコンセプト

Cloud DNS API は、プロジェクト、マネージド ゾーン、レコードセット、レコードセットへの変更を中心に構築されています。

プロジェクト
Google Cloud Platform Console プロジェクトは、リソースのコンテナであり、アクセス制御のためのドメインであり、さらには課金の構成と集計を行う場所でもあります。すべての Cloud DNS リソースは、プロジェクト内に存在しており、すべての Cloud DNS オペレーションでは、使用するプロジェクトを指定する必要があります。
マネージド ゾーン
マネージド ゾーンでは、同じ DNS 名サフィックス(example.com など)の DNS レコードが保持されます。プロジェクトには複数のマネージド ゾーンを含めることができますが、それぞれ一意の名前にする必要があります。Cloud DNS では、マネージド ゾーンは DNS ゾーンをモデル化するリソースです。マネージド ゾーン内のすべてのレコードは Google が運用する同じネームサーバー上でホストされています。これらのネームサーバーは、ゾーンの構成方法に応じて、マネージド ゾーンに対する DNS クエリに応答します。プロジェクトには複数のマネージド ゾーンを含めることができます。 マネージド ゾーンが存在する各ゾーンに対し、毎日料金が発生します。マネージド ゾーンでは、課金の整理に役立つラベルをサポートしています。ゾーンの管理では、ゾーン内のレコードの管理方法について説明します。
一般公開ゾーン

一般公開ゾーンはインターネットを通して表示されます。Cloud DNS には、クエリの発信元に関係なく、一般公開ゾーンに関するクエリに応答する一般公開された正式なネームサーバーがあります。一般公開ゾーンに DNS レコードを作成して、サービスをインターネットで公開できます。たとえば、パブリック ウェブサイト www.example.com では、一般公開ゾーン example.com に次のレコードを作成できます。

DNS 名 TTL(秒) データ
www.example.com A 300 [public_ip_address]

Cloud DNS は、一般公開ゾーンの作成時に一連のネームサーバーを割り当てます。一般公開ゾーン内の DNS レコードをインターネット経由で解決できるようにするには、登録事業者を通してドメイン登録のネームサーバー設定を更新する必要があります。

限定公開ゾーン

限定公開ゾーンを使用すると、基になる DNS データを公共のインターネットにさらすことなく、仮想マシン、ロードバランサ、その他の GCP リソースのカスタム ドメイン名を管理できます。限定公開ゾーンは、承認した 1 つ以上の VPC ネットワークによってのみ照会できる DNS レコードのコンテナです。

限定公開ゾーンは、定義されている同じプロジェクト内のリソースによってのみ照会できます。承認する VPC ネットワークは、限定公開ゾーンと同じプロジェクト内に配置する必要があります。他のネットワークとの DNS ピアリングを設定すると、この制限は無視されます。

限定公開ゾーンを作成または更新する際には、そのゾーンを照会できる承認された VPC ネットワークのリストを指定します。承認されたネットワークだけが限定公開ゾーンを照会できます。承認されたネットワークを指定しない場合、限定公開ゾーンの照会はまったくできません。

限定公開ゾーンは共有 VPC と併用できます。限定公開ゾーンと共有 VPC ネットワークの併用に関する重要な情報については、このページの限定公開ゾーンと共有 VPC をご覧ください。

限定公開ゾーンは DNSSEC(Domain Name System Security Extensions)をサポートしていません。

限定公開ゾーンでの DNS レコードのリクエストは、メタデータ サーバー 169.254.169.254 を介して送信する必要があります。このサーバーは、Google が提供するイメージから作成された VM のデフォルトの内部ネームサーバーです。このネームサーバーへのクエリは、承認された VPC ネットワークを使用する任意の VM から送信できます。

たとえば、dev.gcp.example.com に対して限定公開ゾーンを作成して、実験的なアプリケーション用の内部 DNS レコードをホストできます。次の表に、そのゾーン内のレコードの例を示します。データベース クライアントは、データベース サーバー db-01.dev.gcp.example.com に接続する場合、その IP アドレスの代わりに内部 DNS 名を使用できます。データベース クライアントは、VM 上のホストリゾルバを使用してこの内部 DNS 名を解決し、VM は DNS クエリをメタデータ サーバー 169.254.169.254 に送信します。このメタデータ サーバーは、限定公開ゾーンを照会する再帰リゾルバとして機能します。

DNS 名 TTL(秒) データ
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10
転送ゾーン

転送ゾーンとは、そのゾーンに対するリクエストを転送先の IP アドレスに送信する Cloud DNS 限定公開マネージド ゾーンのタイプです。詳細については、DNS 転送をご覧ください。

ピアリング ゾーン

ピアリング ゾーンは、別の VPC ネットワークの名前解決順序に従う Cloud DNS 限定公開マネージド ゾーンのタイプで、他の VPC ネットワークで定義されている名前の解決に使用できます。

ゾーン オペレーション

Cloud DNS のマネージド ゾーンに加えた変更はすべて、オペレーション コレクションに記録されます。ここには、マネージド ゾーンの更新内容(説明、DNSSEC 状態、または構成の変更)がリストされます。

登録事業者

ドメイン名登録事業者は、インターネット ドメイン名の予約を管理する組織です。登録事業者は、ジェネリック トップレベル ドメイン(gTLD)レジストリまたは国別コード トップレベル ドメイン(ccTLD)レジストリによる認可を受ける必要があります。

内部 DNS

GCP は、Cloud DNS を使用しない場合でも、VM に内部 DNS 名を自動的に作成します。内部 DNS の詳細については、内部 DNS のドキュメントをご覧ください。

委任されたサブゾーン

DNS では、ゾーンのオーナーが NS レコードを使用してサブドメインを別のネームサーバーに委任できます。リゾルバは、これらのレコードに従い、委任で指定されたターゲット ネームサーバーにサブドメインに関するクエリを送信します。

リソース レコードセット コレクション

リソース レコードセット コレクションは、マネージド ゾーンを構成する DNS レコードの現在の状態を保持します。このコレクションは読み取ることはできますが、直接変更しないでください。代わりに、変更コレクション内に Change リクエストを作成することで、マネージド ゾーン内のリソース レコードセットを編集します。リソース レコードセット コレクションには、すべての変更がすぐに反映されます。ただし、API で変更されてから、権威 DNS サーバーでそれらの変更が有効になるまでには、遅延があります。レコードの管理では、レコードの管理方法を説明します。

リソース レコードの変更

リソース レコードセット コレクションを変更する場合は、追加または削除を含む Change リクエストを送信します。追加と削除は、1 つのアトミック トランザクションで一括して行うことができ、それぞれの権威 DNS サーバーで同時に有効になります。

たとえば、次のような A レコードがあるとします。

www  A  203.0.113.1 203.0.113.2

そして、次のようなコマンドを実行します。

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

一括変更後のレコードは次のようになります。

www  A  203.0.113.1 203.0.113.3

ADD と DEL は同時に行われます。

SOA シリアル番号形式

Cloud DNS マネージド ゾーンで作成された SOA レコードのシリアル番号は、gcloud dns record-sets transaction コマンドを使用してゾーンのレコードセットに対するトランザクション変更が行われるごとに単調に増加します。SOA レコードのシリアル番号は任意の番号に手動で変更できますが、RFC 1912 で推奨されている ISO 8601 形式の日付を含める必要があります。たとえば、次の SOA レコードがあるとします。

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

Google Cloud Platform Console から直接シリアル番号を変更するには、レコードの 3 番目のスペース区切りフィールドに希望の値を入力します。

DNS サーバー ポリシー

DNS サーバー ポリシーにより、着信転送を使用して VPC ネットワーク内の GCP が提供する名前解決サービスにアクセスしたり、発信転送を使用して VPC の名前解決の順序を変更したりできます。

ドメイン、サブドメイン、委任

ほとんどのサブドメインは、親ドメインのマネージド ゾーンに含まれるレコードにすぎません。親ドメインのゾーン内に NS(ネームサーバー)レコードを作成することによって委任されたサブドメインには、独自のゾーンも設定する必要があります。 Cloud DNS で親ドメインのマネージド ゾーンを作成した後に、委任されたサブドメインのゾーンを作成してください。この操作は、別の DNS サービスに親ドメインをホストしている場合も行います。サブドメイン ゾーンが複数あるにもかかわらず親ゾーンを作成しなかった場合、後で Cloud DNS に移行することを決めたときに、親ゾーンを作成する作業が複雑になることがあります。

DNSSEC

DNSSEC(Domain Name System Security Extensions)は、Internet Engineering Task Force(IETF)による DNS に対する一連の拡張機能で、ドメインネーム ルックアップに対するレスポンスを認証します。DNSSEC はこれらのルックアップに対するプライバシー保護は行いませんが、攻撃者が DNS リクエストに対するレスポンスを改ざんまたは汚染できないようにします。

DNSKEY コレクション

DNSKEY コレクションには、DNSSEC 対応のマネージド ゾーンの署名に使用される DNSKEY レコードの現在の状態が保持されます。このコレクションは読み取りのみが可能です。DNSKEY に対する変更はすべて Cloud DNS によって行われます。DNSKEY コレクションには、ドメイン登録事業者が DNSSEC を有効にするために必要なすべての情報が含まれています。

VPC の名前解決の順序

VPC ネットワークは、VM インスタンスに DNS 名前解決サービスを提供します。VM がメタデータ サーバー(169.254.169.254)をネームサーバーとして使用する場合、GCP は次の順序で DNS レコードを検索します。

  1. 送信転送の代替ネームサーバーを指定する DNS ポリシーが VPC ネットワーク用に構成されている場合、GCP はすべての DNS クエリをそのサーバーにのみ送信します。詳細については、代替ネームサーバーを使用した送信 DNS 転送をご覧ください。
  2. GCP は、最長サフィックス マッチングを使用して、次の順序で GCP 名前解決サービスを照会します。
    • GCP は、VPC ネットワークで許可された Cloud DNS 管理の限定公開転送ゾーンを照会します。転送先の IP アドレスにリクエストが送信されます。
    • GCP は、VPC ネットワークに許可された Cloud DNS 管理の限定公開ゾーンを照会し、これらのゾーンのレコードを検索します。
    • GCP は、プロジェクトで自動的に作成された Compute Engine の内部 DNS レコードを検索します。
  3. GCP は、適切に構成された start-of-authority(SOA)に従って一般公開ゾーンを照会します。これには、Cloud DNS の一般公開ゾーンも含まれます。

限定公開ゾーンでの PTR レコードの使用

RFC 1918 アドレス用の PTR レコード

VPC の名前解決順序で記述されている最長プレフィックスの一致の結果として、RFC 1918 アドレス用のカスタム PTR レコードを使用してリバース ルックアップを行うには、少なくとも次のいずれかと同程度に限定的な Cloud DNS 限定公開ゾーンを作成する必要があります。

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa.17.172.in-addr.arpa. ... から 31.172.in-addr.arpa.

RFC 1918 アドレス用の Cloud DNS 限定公開ゾーンを作成すると、そのゾーン内の VM インスタンス用に作成したカスタム PTR レコードは、Compute Engine の内部 DNS が自動的に作成する PTR レコードによって上書きされます。これは、Compute Engine の内部 DNS PTR レコードは、上記にリストされている、より限定的なゾーンで作成されるためです。

たとえば、in-addr.arpa. の限定公開マネージド ゾーンで、IP アドレス 10.1.1.1 の VM インスタンスに対して次の PTR レコードを作成するとします。

1.1.1.10.in-addr.arpa. -> test.example.domain

1.1.1.10.in-addr.arpa. に対する PTR クエリには、これよりも限定的な 10.in-addr.arpa. Compute Engine 内部 DNS ゾーンが応答します。test.example.domain の Cloud DNS 限定公開ゾーン内の PTR レコードは無視されます。

VM に対して自動的に作成される Compute Engine の内部 DNS PTR レコードをオーバーライドするには、少なくともこのセクションで提示しているゾーンのうちのいずれかの、特定の限定公開ゾーン内でカスタム PRT レコードを作成してください。たとえば、10.in-addr.arpa. の限定公開ゾーン内で次の PTR レコードを作成すると、このレコードにより、自動的に生成されるレコードがオーバーライドされます。

1.1.1.10.in-addr.arpa. -> test.example.domain

ネットワーク ブロックの一部だけをオーバーライドする必要がある場合は、さらに具体的なリバース Cloud DNS 限定公開ゾーンを作成することもできます。たとえば、5.10.in-addr.arpa. の限定公開ゾーンを使用して PTR レコードを保持すれば、このレコードによって、10.5.0.0/16 アドレス範囲の IP アドレスを持つ VM に対して自動的に作成された Compute Engine の内部 DNS PTR レコードがオーバーライドされます。

RFC 1918 以外のアドレス用の PTR レコード

RFC 1918 以外のアドレス用の PTR レコードは、自動的に作成された Compute Engine の内部 DNS PTR レコードと競合しません。

VPC の名前解決順序により、限定公開ゾーンは、インターネット上の一般公開ゾーンより先にクエリが実行されます。

たとえば、一般公開インターネット上のクエリ PTR IN 2.2.0.192.in-addr.arpaexample.com が返される場合に、1 つ以上の VPC ネットワーク内の VM インスタンスでこれをオーバーライドしたいとします。これを実現するには、DNS 名が in-addr.arpa の限定公開ゾーンを作成し、次の PTR レコードを追加します。

2.2.0.192.in-addr.arpa -> test.com

この限定公開ゾーンへのクエリを許可されている VPC ネットワークに存在する VM が PTR IN 2.2.0.192.in-addr.arpa に対するクエリを行うと、レスポンスとして example.com ではなく test.com を受け取ります。

一般公開ゾーンでの PTR レコードの使用

RFC 1918 以外のアドレスに関して Cloud DNS 一般公開ゾーンにクエリを行うには、ユーザーの IP ブロックのルート委任 in-addr.arpa スペースの一部を Cloud DNS ネームサーバーに委任する必要があります。

一般的なリバース DNS の構成に関する詳細情報はこちらにあります。ただし、リバース DNS を構成する正確な手順はレジストリ オペレーターによって異なります。

サポートされている DNS レコード型

Cloud DNS でサポートされるレコード型は次のとおりです。

レコード型 説明
A

アドレス レコード。ホスト名を IPv4 アドレスにマップするために使用されます。

AAAA

IPv6 アドレス レコード。ホスト名を IPv6 アドレスにマップするために使用されます。

CAA

認証局(CA)認証。ドメインの証明書の作成をどの CA に許可するか指定します。

CNAME

正規名レコード。エイリアス名を指定するために使用されます。
Cloud DNS は、異なる限定公開マネージド ゾーンにわたる CNAME の再帰的解決(CNAME 追跡)をサポートしていません。詳細については、トラブルシューティングをご覧ください。

IPSECKEY

日和見暗号化を有効にするための IPSEC 対応クライアントの IPSEC トンネル ゲートウェイ データと公開鍵。

MX

メール エクスチェンジ レコード。メールサーバーへのリクエストのルーティングに使用されます。

NAPTR

RFC 3403 で定義された Naming Authority Pointer レコード。

NS

ネームサーバー レコード。DNS ゾーンを権威サーバーに委任します。

PTR

ポインタ レコード。DNS の逆引きによく使用されます。

SOA

Start of authority レコード。DNS ゾーンに関する信頼できる情報を指定します。SOA リソース レコードは、マネージド ゾーンを作成するときに自動的に作成されます。レコードは必要に応じて変更できます(たとえば、シリアル番号を日付ベースのバージョニングをサポートする任意の番号に変更できます)。

SPF

Sender Policy Framework レコード。以前、メール検証システムで使用されていたレコード型で、非推奨になりました(代わりに TXT レコードを使用してください)。

SRV

Service locator レコード。一部の VoIP やインスタント メッセージング プロトコルなどのアプリケーションで使用されます。

SSHFP

SSH クライアントが SSH サーバーの公開鍵を検証するための SSH フィンガープリント。

TLSA

TLS クライアントが X.509 サーバー証明書を検証するための TLS 認証レコード。

TXT

テキスト レコード。任意のテキストを含めることができ、セキュリティ情報や不正防止情報などのマシンが読み取れるデータを定義するためにも使用できます。TXT レコードには、1 つまたは複数のテキスト文字列を含めることができます。個々の文字列は 255 文字以下にしてください。複数の文字列がある場合は、メール エージェントや他のソフトウェア エージェントによって連結されます。各文字列は引用符で囲みます。次に例を示します。


"Hello world" "Bye world"

DNS レコードの操作方法については、レコードの管理をご覧ください。

ワイルドカード DNS レコード

ワイルドカード レコードは、NS レコードを除くすべてのレコード型でサポートされます。

DNSSEC

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

以下のコマンドを使用して、マネージド ゾーンに対して DNSSEC を有効にできます。

gcloud dns managed-zones update my-zone --dnssec-state on

新しく作成されたゾーンでも、DNSSEC を有効にすることができます。

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

また、デフォルト設定がデプロイで適切でない場合に指定できる DNSSEC パラメータも用意されています。

DNS 転送

GCP 以外のネームサーバーと GCP の内部ネームサーバー間の DNS 転送をセットアップできます。双方向転送を構成すると、VPC ネットワーク内のインスタンスがオンプレミスやマルチクラウドのネットワーク内に存在するホストのアドレスを検索できると同時に、リンクされたネットワーク上のホストが VPC ネットワーク内に存在するリソースのアドレスを検索することができます。

GCP は、次の方法で DNS 転送をサポートしています。

  • VPC ネットワークは、DNS サーバー ポリシーを使用して、受信と送信の両方の DNS 転送をサポートします。受信リクエストは、Cloud VPN トンネルまたは Cloud Interconnect(オンプレミスのデータセンターなど)経由で VPC に接続しているネットワーク内のシステムから送信されている必要があります。

  • Cloud DNS 限定公開マネージド ゾーンは、ゾーンの転送により送信 DNS 転送をサポートします。

次の例は、DNS 転送が構成された 2 つの VPC ネットワーク(proddev)を表しています。

オンプレミス DNS サーバーによる DNS 転送(クリックして拡大)
オンプレミス DNS サーバーによる DNS 転送(クリックして拡大)
  • dev ネットワークは、動的ルーティングを使用する Cloud VPN トンネル経由でヨーロッパのオンプレミス データセンターに接続します。
  • prod ネットワークは、動的ルーティングを使用する Cloud VPN トンネル経由でアジア、ヨーロッパ、米国のオンプレミス データセンターに接続します。
  • すべてのネットワークにグローバル動的ルーティングが構成されています。
  • 3 つのデータセンターは相互に接続されています。オンプレミスと VPC ネットワークで使用される IP アドレスは RFC 1918 の IP アドレスであり、重複はありません。
  • オンプレミス BIND サーバーは各オンプレミス データセンターに配置され、これらのネームサーバーは corp.example.com ゾーンに対応するように冗長構成になっています。
  • devprod の Cloud VPN ネットワークの両方に DNS ポリシーを作成して、オンプレミスのネームサーバーへの送信転送を有効にします。
  • GCP の VM がメタデータ サーバー(169.254.169.254)を使用して、GCP 内部 DNS、devprod ネットワークに対応する承認済みの DNS 限定公開ゾーン、公開 DNS ゾーン、オンプレミスの corp.example.com ゾーンを解決します。

DNS サーバー ポリシー

DNS サーバー ポリシーを使用すると、VPC ネットワークに受信と送信の DNS 転送を構成できます。特定の VPC ネットワークに 1 つの DNS サーバー ポリシーを適用できます。

詳細な手順については、DNS サーバー ポリシーの使用をご覧ください。

受信 DNS 転送

VPC ネットワークは、VM インスタンスに DNS 名前解決サービスを提供します。VM がメタデータ サーバー 169.254.169.254 をネームサーバーとして使用する場合、GCP は VPC の名前解決の順序に従って DNS レコードを検索します。

デフォルトでは、VPC ネットワークの名前解決サービスは外部のネットワークで利用できません。Cloud VPN または Cloud Interconnect 経由で接続しているオンプレミス ネットワーク内のシステムで利用可能にするには、VPC ネットワークへの受信 DNS 転送を有効にする DNS ポリシーを作成します。有効にすると、接続されたネットワーク内のシステムは、VPC ネットワークの内部 IP アドレスを照会し、名前解決サービスを利用できます。

VPC ネットワークへの受信転送を許可する DNS ポリシーの構成方法については、受信 DNS 転送を有効にする DNS ポリシーを作成するをご覧ください。構成すると、GCP は、VPC ネットワークのサブネット(リージョン内)に内部 IP アドレスを割り当て、受信 DNS リクエストのプロキシとして機能します。リージョンを指定するか、GCP が自動的に選択したリージョンを使用します。受信 DNS 転送の DNS ポリシーは、受信リクエストに対して単一のプロキシ IP アドレスを割り当てます。ただし、この単一の IP アドレスは、VPC ネットワークの名前解決サービスへのエントリ ポイントとして機能します。必要であれば、プロキシ アドレスに転送するようにオンプレミス ネームサーバーを構成できます。

代替ネームサーバーを使用する送信 DNS 転送

代替ネームサーバーのリストを含む DNS ポリシーを作成すると、VPC の名前解決の順序を変更できます。この場合、メタデータ サーバー 169.254.169.254 を使用して VPC 内の VM から送信されたすべての DNS リクエストに対し、GCP は代替ネームサーバーのみをソースとして照会するようになります。

送信転送の DNS ポリシーを構成する方法については、代替ネームサーバーを有効にする DNS ポリシーの作成をご覧ください。RFC 1918 形式の IP アドレスで代替ネームサーバーを指定する場合は、VPC ネットワーク内の他の GCP VM の内部 IP アドレスか、Cloud VPN または Cloud Interconnect 経由で VPC ネットワークに接続しているオンプレミス ネットワークのシステムを指定する必要があります。パブリック IP アドレスを使用して別のネームサーバーを指定する場合は、インターネット上でアクセス可能なアドレスを指定する必要があります。

DNS 転送ゾーン

代替ネームサーバー以外にも、転送ゾーンを定義することで、送信 DNS 転送を行うことができます。これは、DNS 名に関連付けられ、複数のネットワークにバインドできるという点では限定公開ゾーンの設定に似ています。ただし、転送ゾーンにはレコードが含まれていません。転送ゾーンに一致するクエリはすべて、一連の宛先 DNS サーバーに転送されます。代替ネームサーバーの場合と同様に、宛先は IP アドレスのリストになります。

システムは、すべての宛先ネームサーバーで名前を解決しようとします。上記の例では、一致するクエリが 172.16.1.28172.16.4.34172.16.8.50 のすべてまたはサブセットに転送されます。システムは、サーバーの応答とネットワーク状態の変化を考慮して、解決方法を変更する可能性があります。

複数の転送ゾーンの転送条件が重複している場合、クエリで最長一致のゾーンが他のゾーンよりも優先されます。たとえば、DNS サーバーに次の 3 つの転送ゾーンがあるとします。

  • 転送ゾーン 1: onprem.example.com、宛先: 172.16.8.40
  • 転送ゾーン 2: dev.onprem.example.com、宛先: 172.16.8.50
  • 転送ゾーン 3: prod.onprem.example.com、宛先: 172.16.8.60

mysvc.onprem.example.com のクエリはゾーン 1 に従って 172.16.8.40 に転送されます。mysvc.dev.onprem.example.com のクエリはゾーン 2 に従って 172.16.8.50 に転送されます。mysvc.prod.onprem.example.com のクエリはゾーン 3 に従って 172.16.8.60 に転送されます。

手順については、転送ゾーンの作成をご覧ください。

DNS ピアリング

DNS ピアリングを使用すると、あるゾーンのネームスペースからのレコードに対する要求を別の VPC ネットワークに送信できます。

DNS ピアリングを提供するには、Cloud DNS ピアリング ゾーンを作成し、そのゾーンのネームスペースのレコードが利用可能な VPC ネットワークで DNS ルックアップを実行するように構成する必要があります。DNS ピアリング ゾーンがルックアップを実行する VPC ネットワークは、DNS プロデューサー ネットワークと呼ばれます。

DNS ピアリングを使用するには、ピアリング ゾーンを使用するようにネットワークを承認する必要があります。ピアリング ゾーンの使用を承認された VPC ネットワークは、DNS コンシューマ ネットワークと呼ばれます。

承認されると、DNS コンシューマ ネットワーク内の GCP リソースは、ピアリング ゾーンのネームスペース内のレコードを、DNS プロデューサー ネットワーク内に存在するかのように検索できます。ピアリング ゾーンのネームスペース内のレコードの検索は、DNS プロデューサー ネットワークの名前解決順序に従います。したがって、DNS コンシューマ ネットワーク内の GCP リソースは、DNS プロデューサー ネットワークで利用可能な次のソースからゾーンのネームスペース内のレコードを検索できます。

  • DNS プロデューサー ネットワークによる使用が承認された Cloud DNS 限定公開マネージド ゾーン
  • DNS プロデューサー ネットワークによる使用が承認された Cloud DNS マネージド転送ゾーン
  • DNS プロデューサー ネットワーク内の Compute Engine の内部 DNS 名
  • DNS プロデューサー ネットワーク内で送信 DNS ポリシーが構成されている場合、代替ネームサーバー

DNS ピアリングを構成する場合、次の点に注意してください。

  • DNS ピアリングは一方向の関係です。これにより、DNS コンシューマ ネットワーク内の GCP リソースは、ピアリング ゾーンのネームスペース内のレコードを、GCP リソースが DNS プロデューサー ネットワーク内にあるかのように検索できます。
  • DNS プロデューサーおよびコンシューマ ネットワークは、GCP VPC ネットワークである必要があります。
  • DNS ピアリングと VPC ネットワーク ピアリングは異なるサービスです。DNS ピアリングは VPC ネットワーク ピアリングと組み合わせて使用できますが、VPC ネットワーク ピアリングは DNS ピアリングに必須ではありません

ピアリング ゾーンを作成するには、DNS プロデューサー ネットワークを含むプロジェクトの DNS ピア IAM 役割が必要です。

ユースケース

SaaS の例

ある SaaS プロバイダ(プロデューサー)が、SaaS の顧客(コンシューマ)に、ピアリングされたネットワークでホストされているサービスへのアクセス許可を検討しています。プロデューサーは、サービスをホストするネットワークを作成して、それをコンシューマ ネットワークにピアリングします。また、プロデューサーは、コンシューマがサービスにアクセスするために使用する DNS 名も提供する予定です。

この場合、コンシューマは、コンシューマ ネットワークにピアリング ゾーンを作成できるようになるサービス アカウントをプロデューサーが使用できるようにします。また、プロデューサーは使用できるようになったサービス アカウントに自身のネットワークの dns.peer 役割を付与して、ピアリング ゾーンからのリクエストがリゾルバゾーンに届くようにします。あるいは、プロデューサーがコンシューマに適切な設定方法を伝える方法もあります。

組織内設定

Cloud DNS 限定公開マネージド ゾーンは、同じプロジェクト内の複数の VPC ネットワークによる使用を許可できます。ただし、組織内にある複数プロジェクト間での DNS ゾーンの共有が必要になる場合があります。

DNS ピアリングを使用して、このニーズを満たすことができます。1 つのプロデューサー ネットワークに対して承認された単一の限定公開マネージド ゾーンを作成します。次に、別々のプロジェクト内の各コンシューマ ネットワークに許可されている同じネームスペースに対して、十分な数のピアリング ゾーンを作成します。同じプロデューサー ネットワークを使用するように各ピアリング ゾーンを構成して、コンシューマ ネットワーク内の GCP リソースがプロデューサー ネットワークの名前解決順序に従うようにします。これにより、プロデューサー ネットワークに対して承認された任意の限定公開マネージド ゾーンのネームスペース内のレコードを解決できます。

ピアリング ゾーンの次のステップ

手順については、ピアリング ゾーンの構成をご覧ください。

限定公開ゾーンと共有 VPC

限定公開ゾーンと共有 VPC を併用するには、ホスト プロジェクトで限定公開ゾーンを作成し、そのゾーンの承認済みネットワークのリストに適切な共有 VPC ネットワークを追加する必要があります。

重複するゾーン

1 つのプロジェクトに複数のマネージド ゾーンを含めることができます。一方のゾーンのオリジン ドメイン名が他方のゾーンのオリジンと同一であるか、そのオリジンのサブドメインである場合、これら 2 つのゾーンは互いに重複しています。たとえば、dev.gcp.example.com と gcp.example.com は重複するゾーンになっています。

重複する一般公開ゾーン同士は、同じ Cloud DNS ネームサーバー上に存在できません。重複するゾーンを作成すると、Cloud DNS はそれらを異なるネームサーバーに配置しようとします。それができない場合、重複ゾーンの作成は失敗します。

重複は、一般公開ゾーンと限定公開ゾーンの間で可能です。

また、スコープの VPC ネットワークが異なる限定公開ゾーン同士も重複が可能です。たとえば、2 つの VPC ネットワークはゾーン gcp.example.com 内に database.gcp.example.com というデータベース VM を持つことができます。database.gcp.example.com に対するクエリは、それぞれの VPC ネットワークで定義されたゾーンレコードに応じて異なる回答を受け取ります。詳細については、スプリット ホライズン DNS をご覧ください。

重複するゾーンでのクエリ解決

1 つのゾーンが他のゾーンのサブドメインでない限り、同じ VPC ネットワークからアクセス可能な 2 つの限定公開ゾーンは同一の起点を持つことはできません。メタデータ サーバーは、最長サフィックス マッチングを使用して、特定のゾーン内のレコードを照会する起点を決定します。

次の例は、メタデータ サーバーが DNS レコードを照会するときに使用する順序を示しています。これらの例では、gcp.example.comdev.gcp.example.com という 2 つの限定公開ゾーンを作成し、同じ VPC ネットワークからアクセスできることを前提としています。GCP は、VPC ネットワーク内の VM からの DNS クエリを次のように処理します。

  • example.com の限定公開ゾーンがないため、メタデータ サーバーが公開ネームサーバーを使用して myapp.example.com を解決します。
  • リクエストされた DNS レコードと使用可能な限定公開ゾーンの中で gcp.example.com が共通する最長サフィックスとなっているため、メタデータ サーバーが限定公開ゾーン gcp.example.com を使用して myapp.gcp.example.com を解決します。gcp.example.com 限定公開ゾーンに myapp.gcp.example.com のレコードが定義されていない場合、公開ネームサーバーで myapp.gcp.example.com にレコードが定義されていても、NXDOMAIN が返されます。
  • 同様に、myapp.dev.gcp.example.com に対するクエリは、限定公開ゾーン dev.gcp.example.com のレコードに従って解決されます。dev.gcp.example.com ゾーンに myapp.dev.gcp.example.com のレコードが定義されていない場合、別の限定公開ゾーンまたは一般公開ゾーンで myapp.dev.gcp.example.com のレコードが定義されていても NXDOMAIN が返されます。
  • リクエストされた DNS レコードと使用可能な限定公開ゾーンの中で gcp.example.com が共通の最長サフィックスとなるため、myapp.prod.gcp.example.com のクエリは限定公開ゾーン gcp.example.com のレコードに従って解決されます。

スプリット ホライズン DNS

スプリット ホライズン DNS 構成では、一般公開ゾーンと限定公開ゾーンの組み合わせを使用できます。限定公開ゾーンを使用すると、認可された VPC 内の VM からクエリが送信されたときに、同じレコードに対して異なるレスポンスを定義できます。開発環境、社内、本番環境に別々の VPC ネットワークを使用している場合、スプリット ホライズン DNS は便利です。

  • 限定公開ゾーンを定義して、開発環境の VPC ネットワークからのアクセスを許可します。そのネットワーク内の VM から同じゾーンの DNS レコードに対するクエリは同じネットワーク内の他の VM に送信されます。
  • 同じ DNS レコード(名前)に対して異なる回答を行う 2 番目の限定公開ゾーンを定義し、企業ネットワークからのアクセスを認可します。
  • 3 番目のゾーンとして、同じ DNS に対して本番環境に適した適切な回答を行うように一般公開ゾーンを定義します。

たとえば、gcp.example.com に一般公開ゾーンと限定公開ゾーンの両方を作成したとします。また、gcp.example.com が Cloud DNS ネームサーバーを使用するように登録機関を構成します。これにより、一般公開ゾーンがインターネットでアクセス可能となり、VPC ネットワークから限定公開ゾーンへのアクセスが許可されます。

限定公開ゾーンでは、次のように 1 つのレコードを作成します。

DNS 名 TTL(秒) データ
foo.gcp.example.com A 5 10.128.1.35

一般公開ゾーンでは、次の 2 つのレコードを作成します。

DNS 名 TTL(秒) データ
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

DNS レコードへのクエリは次のように解決されます。

  • VPC ネットワークの VM からの foo.gcp.example.com に対するクエリは 10.128.1.35 を返します。
  • インターネットからの foo.gcp.example.com に対するクエリは 104.198.6.142 を返します。
  • VPC ネットワークの VM からの bar.gcp.example.com に対するクエリは、限定公開ゾーン gcp.example.combar.gcp.example.com のレコードがないため、NXDOMAIN エラーを返します。
  • インターネットからの bar.gcp.example.com に対するクエリは 104.198.7.145 を返します。

アクセス制御

一般的なアクセス制御

Google Cloud Platform Console の [IAM と管理] ページで、DNS レコードへの変更を許可されたユーザーを管理できます。変更を行うことを承認されたユーザーは、GCP Console の [権限] セクションに editor または owner のいずれかとしてリスト表示されている必要があります。権限レベルが閲覧者の場合は、Cloud DNS レコードへの読み取り専用アクセスが付与されます。

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

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

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

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

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

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

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

変更の伝播

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

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

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

次のステップ

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud DNS のドキュメント