概要 | Cloud DNS のドキュメント

このページでは、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

転送ゾーン

GCP 以外のネームサーバーと GCP の内部ネームサーバーの間の DNS 転送を設定できます。詳細については、DNS 転送をご覧ください。

ピアリングゾーン

2 つのネットワークがピアリングされているとき、それらは自動ではお互いの DNS 情報を共有しません。2 つの VPC ネットワーク間に DNS ピアリングを設定すれば、カスタマーネットワーク上のリソースが DNS リクエストを行ったときに、そのリクエストがプロデューサーネットワーク上の DNS リゾルバに転送されるようにできます。

ゾーンオペレーション

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

登録事業者

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

内部 DNS

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

委任されたサブゾーン

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

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

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

リソースレコードの変更

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

以下の図は、同時の追加と削除を示しています。

/projects/example-project

../managedZones/examplezone (example.com)

../rrsets

example.com.  SOA  admin@example.com.
example.com.  NS   zns-1.google.com.
example.com.  MX   10 mail.example.com.
www           A    2.3.4.5 3.4.5.6

../changes

3  user2@    2014-03-31T18:59:23.587Z  PENDING
   DEL  www  A  1.2.3.4
   ADD  www  A  2.3.4.5 3.4.5.6
2  user1@    2014-03-31T16:34:18.58Z  DONE
1  devops@   2014-03-28T12:46:09.23Z  DONE

../managedZones/myorg (example.org)

../rrsets

example.org.  SOA  admin@example.org.
example.org.  NS   zns-1.google.com.
www           A    7.8.9.0

../changes

2  user2@    2014-04-02T18:53:55.132Z  PENDING
   DEL  www  A  5.6.7.8
   ADD  www  A  7.8.9.0
1  devops@   2014-03-230T07:22:35.192Z  DONE

1 つのプロジェクトに複数のマネージドゾーンを含めることができます。

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 レコードを検索します。

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

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

VPC の名前解決の順序で説明しているように最長プレフィックスマッチングが使用されるため、カスタム 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.

in-addr.arpa. の 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 レコードがオーバーライドされます。

サポートされている 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 ネットワーク（prod と dev）を表しています。

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

VPC ネットワークピアリングを使用して 2 つの VPC ネットワークをピアリングすると、ピアリングされたネットワーク内のインスタンスは内部 IP アドレスを使用して互いにアクセスできます。ただし、ピアリングされたネットワークは自動的には DNS 情報をやり取りしません。DNS ピアリングを使用することで、DNS リクエストを転送するネットワーク（コンシューマネットワーク）に DNS ピアリングゾーンを構成し、DNS リクエストを別のネットワーク（プロデューサーネットワーク）の DNS リゾルバに向けて処理するように構成できます。

DNS ピアリングは一方向にのみ機能し、1 つのピアリング関係で可能となるのは、DNS リクエストをあるネットワークから別のネットワークへ転送することのみです。双方向ピアリングには、2 つのピアリング関係が必要になります。

DNS ピアリングを確立するには、次が必要です。

DNS リクエストを解決するネットワーク内に、1 つ以上の限定公開ゾーンまたは転送ゾーン
リクエストを他のネットワークに転送するネットワーク内に、1 つのピアリングゾーン
ピアリングゾーンが限定公開ゾーンのあるネットワークにリクエストを転送するための権限（dns.peer IAM 役割を使用）

ユースケース

SaaS の例

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

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

組織内設定

通常、限定公開ゾーンは、1 つのプロジェクト内のすべてのネットワークからアクセスできるように構成できます。しかし、組織内に多数のプロジェクトがあり、各プロジェクト内のすべてのネットワークが、内部でのすべての名前解決を単一の限定公開ゾーンで行う必要の生じる場合があります。これを実現するには、1 つのプロジェクト内に限定公開ゾーンを作成してから、その限定公開ゾーンを指すピアリングゾーンを他のすべてのプロジェクトに対して作成します。

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

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

限定公開ゾーンと共有 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.com と dev.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.com に bar.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 の使用を開始するには、クイックスタートをご覧ください。