Cloud DNS の概要

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

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

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

一般的な 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 転送は、転送ゾーンまたは 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 限定公開ゾーン、転送ゾーン、またはピアリング ゾーン内のレコードを解決できなくなります。詳細については、名前解決の順序をご覧ください。

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

Cloud DNS コントロール プレーンは、アルゴリズムを使用して転送先の応答性を判断します。送信転送クエリで SERVFAIL エラーが発生することがあります。この問題を回避する方法については、送信転送クエリが SERVFAIL エラーを受け取るをご覧ください。

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

限定公開ゾーンの RFC 1918 アドレス用 PTR レコード

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 レコードは、内部 DNS が自動的に作成する PTR レコードによってオーバーライドされます。これは、内部 DNS PTR レコードが、上記にリストされている、より限定的なゾーンで作成されるためです。

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

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

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

VM に対して自動的に作成される内部 DNS PTR レコードをオーバーライドするには、このセクションで提示しているゾーンの少なくとも 1 つと同程度に限定的な限定公開ゾーン内で、カスタム PTR レコードを作成してください。たとえば、10.in-addr.arpa. の限定公開ゾーン内で次の PTR レコードを作成すると、このレコードにより、自動的に生成されるレコード 1.1.1.10.in-addr.arpa. -> test.example.domain がオーバーライドされます。

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

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

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

レコードタイプ 説明
A

アドレス レコード。ホスト名を IPv4 アドレスにマッピングします。
AAAA

IPv6 アドレス レコード。ホスト名を IPv6 アドレスにマッピングします。
CAA

認証局（CA）承認。ドメイン証明書の作成を許可する CA を指定します。
CNAME

正規名レコード。エイリアス名を指定します。

Cloud DNS は、異なる限定公開マネージド ゾーンにわたる CNAME の再帰的解決（CNAME 追跡）をサポートしていません。詳細については、限定公開ゾーンで定義された CNAME レコードが機能していないをご覧ください。
DNSKEY

安全な転送のために、他のオペレーターから取得される DNSSEC キー。このレコード セットタイプを追加できるのは、転送状態の DNSSEC 対応ゾーンのみです。
DS

委任されたゾーンの安全を確保するための DNSSEC キー フィンガープリント。このレコード セットタイプは、委任されたゾーンに対して DNSSEC を有効にしません。有効にするには、このゾーンに対して DNSSEC を手動で有効にする必要があります。
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 レコード。一部の Voice over IP （VoIP）やインスタント メッセージング プロトコルなどのアプリケーションで使用されます。
SSHFP

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

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

テキスト レコード。任意のテキストを含めることができ、セキュリティ情報や不正防止情報などのマシンが読み取れるデータを定義するためにも使用できます。

TXT レコードには、1 つまたは複数のテキスト文字列を含めることができます。個々の文字列は 255 文字以下にしてください。複数の文字列がある場合は、メール エージェントや他のソフトウェア エージェントによって連結されます。各文字列は引用符で囲みます。

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

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

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

DNSSEC

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

転送ゾーン

Cloud DNS 転送ゾーンを使用すると、特定の限定公開ゾーン用に転送先ネームサーバーを構成できます。VPC ネットワークからの送信 DNS 転送を実装する方法の 1 つに、転送ゾーンの使用があります。

Cloud DNS 転送ゾーンは、特別なタイプの Cloud DNS 限定公開ゾーンです。ゾーン内にレコードを作成する代わりに、一連の転送先を指定します。各転送先は、VPC ネットワーク内に配置された DNS サーバーの IP アドレスか、Cloud VPN または Cloud Interconnect によって VPC ネットワークに接続されたオンプレミス ネットワーク内にある DNS サーバーの IP アドレスです。

転送先とルーティング方法

Cloud DNS は、3 つのタイプの転送先をサポートし、それらの転送先にトラフィックを標準または限定公開の方法でルーティングできます。

転送先 説明 標準ルーティングのサポート 限定公開ルーティングのサポート リクエスト元
タイプ 1 転送ゾーンの使用が許可されている同じ VPC ネットワーク内の Google Cloud VM の内部 IP アドレス。 RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 内部 IP アドレス（RFC 1918 以外のプライベート IP アドレスや、再利用されたパブリック IP アドレスなど） - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 35.199.192.0/19
タイプ 2 Cloud VPN または Cloud Interconnect を使用して、転送ゾーンのクエリが承認された VPC ネットワークに接続されている、オンプレミス システムの IP アドレス。 RFC 1918 の IP アドレスのみ - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 内部 IP アドレス（RFC 1918 以外のプライベート IP アドレスや、再利用されたパブリック IP アドレスなど） - トラフィックは、常に承認済み VPC ネットワーク経由でルーティングされます。 35.199.192.0/19
タイプ 3 インターネットからアクセス可能な DNS ネームサーバーの外部 IP アドレスまたは Google Cloud リソースの外部 IP アドレス（別の VPC ネットワークにある VM の外部 IP アドレスなど）。 インターネット ルーティング可能な外部 IP アドレスのみ - トラフィックは、常にインターネットまたは Google Cloud リソースの外部 IP アドレスにルーティングされます。 限定公開ルーティングはサポートされていません。限定公開ルーティングがオフになっていることを確認してください。 Google Public DNS ソース範囲

転送先を転送ゾーンに追加するときには、次の 2 つのルーティング方法のいずれかを選択できます。

  • 標準ルーティング: 転送先が RFC 1918 IP アドレスであるかどうかに基づいて、認可済みの VPC ネットワークまたはインターネット経由でトラフィックをルーティングします。転送先が RFC 1918 IP アドレスの場合、Cloud DNS は転送先をタイプ 1 またはタイプ 2 転送先に分類し、リクエストを認可済みの VPC ネットワークを通じて転送します。転送先が RFC 1918 IP アドレスでない場合、Cloud DNS は転送先をタイプ 3 として分類し、転送先がインターネットにアクセスできることが必要となります。

  • 限定公開ルーティング: 転送先の IP アドレスが RFC 1918 であるか否かにかかわらず、常に認可済みの VPC ネットワーク経由でトラフィックをルーティングします。したがって、タイプ 1 とタイプ 2 の転送先のみがサポートされます。

タイプ 1 またはタイプ 2 の転送先にアクセスするために、Cloud DNS は DNS クライアントが配置されている、認可済みの VPC ネットワーク内のルートを使用します。これらのルートは、転送先への安全なパスを定義します。

タイプ 1 転送先とタイプ 2 転送先のネットワーク要件の詳細については、転送先ネットワークの要件をご覧ください。

転送先の選択順序

Cloud DNS を使用すると、送信サーバー ポリシーの代替ネームサーバーのリストと、転送ゾーンの転送先のリストを構成できます。

転送先が複数ある場合、Cloud DNS は内部アルゴリズムを使用して転送先を選択します。このアルゴリズムでは、各転送先がランク付けされます。

リクエストを処理するため、Cloud DNS はまずランクが最も高い転送先に接続し、DNS クエリを試みます。このサーバーが応答しない場合、Cloud DNS はランクがその次に高い転送先にリクエストを再度試みます。応答する転送先がない場合、Cloud DNS は SERVFAIL レスポンスを合成します。

ランキング アルゴリズムは自動で、次の要因により転送先のランキングが増分されます。

  • 転送先で処理された、成功した DNS レスポンスの数が多いほど増分されます。成功した DNS レスポンスには NXDOMAIN レスポンスが含まれます。
  • 転送先との通信のレイテンシ（ラウンドトリップ時間）が少ないほど増分されます。

転送ゾーンの使用

VPC ネットワーク内の VM では、次の場合に Cloud DNS 転送ゾーンを使用できます。

  • VPC ネットワークで Cloud DNS 転送ゾーンを使用することが承認されている場合。同じプロジェクト内の複数の VPC ネットワークに対して転送ゾーンの使用を承認できます。
  • VPC ネットワーク内の各 VM のゲスト オペレーティング システムが、VM のメタデータ サーバー 169.254.169.254 をネームサーバーとして使用している場合。

重複する転送ゾーン

Cloud DNS 転送ゾーンは Cloud DNS 限定公開マネージド ゾーンの一種であるため、重複する複数のゾーンを作成できます。前述のように構成された VM は、サフィックスが最も長いゾーンを使用して、名前解決順序に従ってレコードを解決します。詳しくは、重複するゾーンをご覧ください。

キャッシュと転送ゾーン

Cloud DNS は、Cloud DNS 転送ゾーンに送信されたクエリに対するレスポンスをキャッシュに保存します。Cloud DNS は、到達可能な転送先からキャッシュに保存したレスポンスを次の期間のうち短いほうの期間維持します。

  • 60 秒
  • レコードの有効期間（TTL）

転送ゾーンのすべての転送先が到達不能になった場合、Cloud DNS はそのゾーンで以前にリクエストされたレコードのキャッシュを各レコードの TTL の期間維持します。

代わりにピアリングを使用する場合

Cloud DNS は、推移的ルーティングを使用して転送先に接続することはできません。次のシナリオで無効な構成について検討します。

  • Cloud VPN または Cloud Interconnect を使用して、オンプレミス ネットワークを vpc-net-a という名前の VPC ネットワークに接続しました。

  • VPC ネットワーク ピアリングを使用して VPC ネットワーク vpc-net-a を vpc-net-b に接続しました。カスタムルートをエクスポートするように vpc-net-a を構成し、それらをインポートするように vpc-net-b を構成しました。

  • vpc-net-a が接続されているオンプレミス ネットワークに転送先がある転送ゾーンを作成しました。vpc-net-b に対してその転送ゾーンの使用を承認しました。

このシナリオでは、vpc-net-b からオンプレミス ネットワークへの接続があるにもかかわらず、転送先によって提供されるゾーンのレコードを解決できません。このエラーを実際に確認するために、vpc-net-b の VM から次のテストを行います。

  • VM のメタデータ サーバー 169.254.169.254 に対して、転送ゾーンに定義されたレコードをクエリします。Cloud DNS では転送先への推移的ルーティングがサポートされていないため、このクエリは失敗します。転送ゾーンを使用するには、そのメタデータ サーバーを使用するように VM を構成する必要があります。

  • 転送先に対して同じレコードを直接クエリします。Cloud DNS はこのパスを使用しませんが、このクエリによって推移的接続が成功したことが確認できます。

この不具合を修正するには、Cloud DNS のピアリング ゾーンを使用します。

  1. vpc-net-a を転送先とする vpc-net-b に対して承認される Cloud DNS ピアリング ゾーンを作成します。
  2. 転送先がオンプレミス ネームサーバーである vpc-net-a に対して承認される転送ゾーンを作成します。

これらの手順は、任意の順序で行うことができます。これらの手順を完了すると、vpc-net-a と vpc-net-b の両方の Compute Engine インスタンスがオンプレミスの転送先をクエリできます。

DNS ピアリング

DNS ピアリングを使用すると、あるゾーンの名前空間を送信元とするレコードに対するリクエストを別の VPC ネットワークに送信できます。たとえば、SaaS プロバイダはそれ自体が管理する DNS レコードに SaaS 顧客がアクセスできるようにすることができます。

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 コンシューマ ネットワーク内の Google Cloud リソースは、ピアリング ゾーンの名前空間内のレコードを、Google Cloud リソースが DNS プロデューサー ネットワーク内にあるかのように検索できます。
  • DNS プロデューサー ネットワークとコンシューマ ネットワークは、VPC ネットワークである必要があります。
  • 通常、DNS プロデューサー ネットワークとコンシューマ ネットワークは同じ組織に属しますが、組織間の DNS ピアリングもサポートされています。
  • DNS ピアリングと VPC ネットワーク ピアリングは異なるサービスです。DNS ピアリングは VPC ネットワーク ピアリングと組み合わせて使用できますが、VPC ネットワーク ピアリングは DNS ピアリングに必須ではありません。
  • 推移的 DNS ピアリングはサポートされていますが、単一の推移的ホップを介した場合に限られます。つまり、3 つの VPC ネットワーク（中間のネットワークが推移的ホップとなる）の他に VPC ネットワークを含めることはできません。たとえば、vpc-net-b を転送先とするピアリング ゾーンを vpc-net-a に作成し、vpc-net-c を転送先とするピアリング ゾーンを vpc-net-b に作成できます。
  • DNS ピアリングを使用して転送ゾーンをターゲットにする場合は、転送ゾーンがあるターゲット VPC ネットワークの VM、VLAN アタッチメント、または Cloud VPN トンネルが、DNS ピアリング ゾーンを使用するソース VM と同じリージョンに配置されている必要があります。この制限の詳細については、コンシューマ VPC ネットワーク内の VM からプロデューサー VPC ネットワークへのクエリ転送が機能しないをご覧ください。

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

重複するゾーン

2 つのゾーンのうち、1 つのゾーンの起点のドメイン名がもう一方のゾーンの起点と同一であるか、その起点のサブドメインである場合、これらは互いに重複しています。次に例を示します。

  • gcp.example.com のゾーンと gcp.example.com の別のゾーンは、ドメイン名が同一であるため重複します。
  • dev.gcp.example.com のゾーンと gcp.example.com のゾーンは、dev.gcp.example.com が gcp.example.com のサブドメインであるため重複します。

重複するゾーンのルール

Cloud DNS では、重複するゾーンに対して次のルールが適用されます。

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

  • 限定公開ゾーンは、一般公開ゾーンと重複できます。

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

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

クエリ解決の例

名前解決順序で説明しているように、Google Cloud は Cloud DNS ゾーンを解決します。特定のレコードのクエリするゾーンを決定するとき、Cloud DNS はリクエストされたレコードとできるだけ多く一致するゾーンを探そうとします（最長サフィックス マッチング）。

送信サーバー ポリシーで代替ネームサーバーを指定しない限り、Google Cloud はまず、VPC ネットワークに対して承認された限定公開ゾーン（または転送ゾーンかピアリング ゾーン）でレコードを探し、その後、一般公開ゾーンでレコードを探します。

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

  • VPC ネットワークに対して承認された example.com の限定公開ゾーンがないため、メタデータ サーバーは一般公開ネームサーバーを使用して myapp.example.com.（末尾のドットに注意）のレコードを解決します。Compute Engine VM から dig を使用して、VM のデフォルトのネームサーバーにクエリを実行します。

    dig myapp.example.com.

    詳細については、メタデータ サーバーを使用して DNS 名を照会するをご覧ください。

  • メタデータ サーバーは、承認済みの限定公開ゾーン gcp.example.com を使用してレコード myapp.gcp.example.com を解決します。これは、リクエストされたレコード名と使用可能な限定公開ゾーンに共通する最長のサフィックスが 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 からの、同じレコードへのクエリに対して、異なるレスポンスを定義できます。スプリット ホライズン DNS は、発信元の VPC ネットワークに応じて同じ DNS クエリに異なるレコードを提供する必要がある場合に便利です。

例として次のスプリット ホライズンを検討します。

  • 一般公開ゾーン gcp.example.com を作成し、Cloud DNS ネームサーバーを使用するようにその登録事業者を構成しました。
  • 限定公開ゾーン gcp.example.com を作成し、VPC ネットワークに対してこのゾーンへのアクセスを承認しました。

限定公開ゾーンでは、次の表に示すように単一のレコードを作成しました。

レコード 型 TTL（秒） データ
foo.gcp.example.com A 5 10.128.1.35

一般公開ゾーンにレコードを 2 つ作成しました。

レコード 型 TTL（秒） データ
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

次のクエリは、ここで説明するとおりに解決されます。

  • 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 の [権限] セクションに編集者のロール（roles/editor）またはオーナーのロール（roles/owner）のいずれかが付与されている必要があります。閲覧者のロール（roles/viewer）は、Cloud DNS レコードに対する読み取り専用アクセス権を付与します。

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

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

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

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

プロジェクト オーナー、編集者、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 リゾルバの負荷を軽減できます。

次のステップ