概要

このページでは、Cloud DNS の特長と機能の概要について説明します。クイックスタートで Cloud DNS の使い方を学習する。

はじめに

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

概念

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

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

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

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

Cloud DNS の概念

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

プロジェクト

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

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

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

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

限定公開ゾーンは、DNSSEC（Domain Name System Security Extensions）または NS タイプのカスタムレコードセットをサポートしていません。

限定公開ゾーンでの 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

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

DNS サーバーポリシー

DNS サーバーポリシーにより、着信転送を使用して VPC ネットワーク内の Google Cloud が提供する名前解決サービスにアクセスできます。また、発信転送を使用して 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）をネームサーバーとして使用する場合、Google Cloud は次の順序で DNS レコードを検索します。

送信転送の代替ネームサーバーを指定する DNS ポリシーが VPC ネットワーク用に構成されている場合、Google Cloud はすべての DNS クエリをそのサーバーにのみ送信します。詳細については、代替ネームサーバーを使用する送信 DNS 転送をご覧ください。
Google Cloud は、最長サフィックスマッチングを使用して、次の順序で Google Cloud 名前解決サービスを照会します。
- Google Cloud は、VPC ネットワークで許可された Cloud DNS 管理の限定公開転送ゾーンを照会します。転送先の IP アドレスにリクエストが送信されます。
- Google Cloud は、VPC ネットワークに許可された Cloud DNS 管理の限定公開ゾーンを照会し、これらのゾーンのレコードを検索します。これにはピアリングゾーンも含まれます。
- Google Cloud は、プロジェクトで自動的に作成された Compute Engine の内部 DNS レコードを検索します。
Google Cloud は、適切に構成された 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 レコードをオーバーライドするには、少なくともこのセクションで提示しているゾーンのうちのいずれかの、特定の限定公開ゾーン内でカスタム PTR レコードを作成してください。たとえば、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.arpaで example.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 以外のネームサーバーと Google Cloud の内部ネームサーバー間の DNS 転送をセットアップできます。双方向転送を構成すると、VPC ネットワーク内のインスタンスがオンプレミスやマルチクラウドのネットワーク内に存在するホストのアドレスを検索できると同時に、リンクされたネットワーク上のホストが VPC ネットワーク内に存在するリソースのアドレスを検索できます。

Google Cloud は、次の方法で 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 ポリシーを作成して、オンプレミスのネームサーバーへの送信転送を有効にします。
Google Cloud の VM がメタデータサーバー（169.254.169.254）を使用して、Google Cloud 内部 DNS、dev と prod ネットワークに対応する承認済みの DNS 限定公開ゾーン、公開 DNS ゾーン、オンプレミスの corp.example.com ゾーンを解決します。

DNS 転送の制限事項

転送ゾーンの転送先に、VPC ネットワークピアリング経由で推移的に到達することはできません。

設定例: オンプレミス環境が Cloud VPN トンネルまたは Cloud Interconnect 経由で 2 つの VPC ネットワーク（vpc-net-a と vpc-net-b）に接続しています。2 つの VPC ネットワークは、VPC ネットワークピアリングを使用して接続され、カスタムルートを交換するように構成されています。vpc-net-b に転送ゾーンを作成し、オンプレミスネットワーク内の転送先を指定すると、DNS 転送は機能しません。これを確認するには、次のテストを行います。

メタデータサーバー 169.254.169.254 にクエリを送信し、転送ゾーンで定義されたレコードを照会します。このクエリは失敗します。
同じレコードの転送先を直接照会します。このクエリは成功します。

この問題を解決するには、vpc-net-b に Cloud DNS ピアリングゾーンを作成します。ターゲットを vpc-net-a にし、vpc-net-a の転送ゾーンのターゲットをオンプレミスネームサーバーにします。アタッチメントまたはトンネルを使用して vpc-net-a と vpc-net-b の両方をオンプレミスに接続できますが、クエリをオンプレミスに転送できるのは片方だけです。もう一方でオンプレミスに転送を行うには、指定した VPC ネットワークと DNS ピアリングを行う必要があります。

DNS サーバーポリシー

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

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

受信 DNS 転送

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

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

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

代替ネームサーバーを使用した VPC ネットワーク名の解決順序

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

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

RFC 1918 以外の IP アドレスへの送信 DNS 転送

デフォルトでは、DNS 転送は限定公開パスまたは一般公開パス経由で転送先にクエリを送信します。限定公開パスは Google Cloud ネットワークを経由し、一般公開パスはインターネットを経由します。実際のパスは構成できません。Cloud DNS は、転送先の IP 範囲に基づいてパスを自動的に選択します。転送先が RFC 1918 アドレスの場合、限定公開ネットワーク経由でクエリが送信されます。転送先が RFC 1918 以外のアドレスの場合、インターネット経由でクエリが送信されます。

Cloud DNS では、任意の IP アドレスに対して限定公開のクエリパスを適用できます。この処理を行うには、1 つ以上の転送先を指定して転送ゾーンを作成または更新します。

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 に転送されます。

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

詳細については、Cloud DNS 転送ゾーンのおすすめの方法をご覧ください。

DNS ピアリング

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

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

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

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

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

DNS ピアリングの制限事項

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

DNS ピアリングは一方向の関係です。これにより、DNS コンシューマネットワーク内の Google Cloud リソースは、ピアリングゾーンのネームスペース内のレコードを、Google Cloud リソースが DNS プロデューサーネットワーク内にあるかのように検索できます。
DNS プロデューサーおよびコンシューマネットワークは、Google Cloud VPC ネットワークである必要があります。
DNS ピアリングと VPC ネットワークピアリングは異なるサービスです。DNS ピアリングは VPC ネットワークピアリングと組み合わせて使用できますが、VPC ネットワークピアリングは DNS ピアリングに必須ではありません。
DNS 転送は VPC ネットワークピアリングで機能しません。
推移的な DNS ピアリングはサポートされますが、単一の推移的なホップを通じてのみとなります。つまり、VPC1 から VPC2、VPC3 へのピアリングを確立できますが、それ以上はできません。

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

使用例

SaaS の例

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

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

組織内設定

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

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

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

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

限定公開ゾーンと共有 VPC

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

詳細については、Cloud DNS 限定公開ゾーンのおすすめの方法をご覧ください。

重複するゾーン

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 ネットワークからアクセスできることを前提としています。Google Cloud は、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 Console の [IAM と管理] ページで、DNS レコードへの変更を許可されたユーザーを管理できます。変更を行うことを承認されたユーザーは、Cloud 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 の使い方を学習する。
API クライアントライブラリについて学習する。