Google PCNE: Cloud DNS、サービス ディスカバリ、ハイブリッド名前解決 — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Cloud DNSは、Google Cloudのスケーラブルで高可用性なDNSサービスであり、パブリックな権威ゾーンとVPC向けのプライベートDNSの両方をサポートします。また、オンプレミスDNSやマルチクラウドと統合するための、フォワーディング、ピアリング、インバウンドサーバー、レスポンスポリシー、DNSポリシーといったハイブリッド名前解決のプリミティブも提供します。このセクションでは、権威DNSのライフサイクル、プライベートゾーンの可視性と共有、ハイブリッド解決、サービスディスカバリーのパターン、セキュリティと整合性（DNSSECとゾーン転送を含む）、ルーティングポリシーによる高度なトラフィック管理、プライベートサービスエンドポイントのためのDNS、そしてトラブルシューティング、キャッシング、ロギング、移行/共存戦略などのDay-2オペレーションについて説明します。

権威DNSとDNSライフサイクル

• マネージドゾーンとレコード
  • マネージドゾーンは、単一のDNS名（ゾーンエイペックス）に対するリソースレコードセット（RRsets）のコンテナです。
  • レコードタイプ: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA（その他多数）。Cloud DNSはゾーンエイペックスでのCNAMEをサポートしていません。エイペックスのマッピングには、ロードバランサーのIPを持つA/AAAAレコードを使用します。
  • ライフサイクル: ゾーンの作成、レコードの追加/変更（トランザクション変更）、伝播、そして運用（監視/ログ/セキュリティ確保）。
  • 既存のBINDファイルからインポートして移行を加速します:
    • 例: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
• パブリックゾーンとプライベートゾーン
  • パブリックゾーンは、Googleのパブリック権威ネームサーバーを介してグローバルにアクセス可能です。親ゾーンのNSレコードを更新することで、レジストラーで委任します。
  • プライベートゾーンは、アタッチされたVPCネットワークに対してのみ応答します。それらは、それらのVPC内のインスタンスや、オプションでインバウンドフォワーディングを介したハイブリッドクライアントのために、GoogleのVPCスコープのリゾルバーによって解決されます。
• 伝播とTTL
  • Google Cloud内では、レコードの変更は数秒で有効になります。外部キャッシュの無効化はTTLに依存します。
  • TTLのトレードオフ: 短いTTLは俊敏性と安全な切り替えを可能にしますが、クエリ負荷を増加させ、キャッシュ効率を低下させる可能性があります。長いTTLは負荷を軽減しますが、古い応答が長引きます。一般的なプラクティス: 動的なサービスには60～300秒、安定したレコードには600～3600秒。切り替えの24～48時間前にTTLを短縮します。

プライベートゾーンの可視性、VPCとの関連付け、およびクロスプロジェクト設計

• プライベートゾーンのVPCへのアタッチ
  • プライベートゾーンは、1つ以上のVPCネットワークに明示的に関連付けられます。この関連付けは、プロジェクトをまたぐことができます（ゾーンに対するdns.adminなどの適切なIAMと、ネットワークをバインドする権限が必要です）。
  • 優先順位: VPCにアタッチされたプライベートゾーン間で、最長サフィックスが一致するものが優先されます。プライベートゾーンが重複する場合（例: svc.corp.internal. と corp.internal.）は注意が必要です。
• クロスVPC共有パターン
  • 直接アタッチ: 同じプライベートゾーンを複数のVPCにアタッチします。運用上はシンプルですが、影響範囲（ブラスト半径）を減らすために、不要な場所へのアタッチは避けてください。
  • 共有VPC: ホストプロジェクトでDNS管理を一元化し、サブネットのVPCをゾーンにアタッチすることで、サービスプロジェクトにDNSを公開します。
  • DNSピアリングゾーン: ネットワーク間でVPCピアリングが使用されている場合、コンシューマーVPC内のピアリングゾーンは、ゾーンを複製することなくプロデューサーVPCのプライベートレコードを解決できます。
• 障害モードとガードレール
  • シャドウイング: パブリックゾーンと同じ名前のプライベートゾーンがあると、アタッチされたVPC内のクライアントはプライベートな応答を優先し、パブリックエンドポイントへのアクセスを破壊する可能性があります。スプリットホライズンは意図的に使用し、文書化し、テストしてください。
  • 過剰なアタッチ: プライベートゾーンを広範囲にアタッチすると、内部名が漏洩する可能性があります。最小権限の原則に従い、スコープを限定するために個別のサブドメイン（リージョン/サービススコープ）を使用してください。
  • IAMの分離: 管理ドメインを分離するために、DNSの変更権限（dns.admin）とネットワークのアタッチ権限（ネットワークをバインドする権限）を別々に委任します。

簡単な例: プライベートゾーンの作成とアタッチ

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

ハイブリッド名前解決: フォワーディング、ピアリング、ポリシー

• フォワーディング ゾーン
  • サフィックス（例: onprem.corp.）に対するクエリを、特定のネームサーバー（オンプレミスや他のクラウド）に権威を持ってフォワードします。Cloud DNSでそのゾーンをホストしていないが、GCPからシームレスな名前解決が必要な場合に使用します。
  • ループを避ける: オンプレミスのフォワーダーが、同じサフィックスに対してCloud DNSを指し返さないようにします。
• ピアリング ゾーン
  • ピアリングされたVPCでホストされているプライベートゾーンを解決します。VPCピアリング接続が必要で、推移的ではありません。ハブ＆スポーク設計で、プライベートDNSをハブVPCに集約するために使用します。
• DNSポリシー
  • アウトバウンド フォワーディング: VPC内のインスタンスは、Cloud DNSプライベートゾーンで解決されないドメインについて、オンプレミスのリゾルバに再帰的なクエリを送信します。Cloud VPN/Interconnect経由で到達可能なターゲットネームサーバーのIPを持つDNSポリシーを介して設定します。
  • インバウンド サーバー: オンプレミスのリゾルバは、Googleが提供するインバウンド フォワーディングIP（自動割り当ての35.199.192.0/20）にクエリを転送し、Cloud DNSプライベートゾーンを解決します。GCPのプライベートDNSをオンプレミスや他のクラウドに拡張するために使用します。
  • クエリロギング: ポリシーレベルで有効にし、リゾルバのクエリログをCloud Loggingに送信して、分析やトラブルシューティングに利用します。パブリックゾーンの場合、権威クエリに対してゾーンごとのクエリロギングを有効にします。
• レスポンス ポリシー
  • レスポンスを修正するルールを定義します（例: 既知の悪意のあるドメインに対してNXDOMAINを返す、またはパブリックな応答を上書きするために内部のAレコードを合成する）。慎重に適用し、重要なサードパーティのドメインが意図せずブロックされていないことを検証します。
• 接続の前提条件
  • アウトバウンド/インバウンドが機能するためには、ハイブリッド接続（Cloud VPNまたはInterconnect）と、ファイアウォールルールで必要に応じてUDP/TCP 53の双方向通信が許可されていることを確認します。EDNS0とUDPのフラグメンテーションの挙動はネットワークによって異なります。MTUの問題が発生した場合は、TCPへのフォールバックを許可し、オンプレミスのリゾルバでEDNS(0)バッファのチューニングを検討します。
• よくある落とし穴
  • 非対称な到達可能性: アウトバウンド フォワーディングがオンプレミスのリゾルバを指しているが、戻りのトラフィックがファイアウォールや非対称なルーティングによってブロックされると、クエリはタイムアウトします。Cloud Routerが学習したルートを確認し、DNSレスポンスのフローを許可します。
  • サフィックスの分割: 重複する企業サフィックス（corp.local vs corp.internal）は、予期しないリゾルバの検索パスの一致を引き起こす可能性があります。検索パスとサフィックスの所有権を標準化します。

簡単な例:

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

サービス ディスカバリ、スプリットホライズン、プライベート エンドポイント

• スプリットホライズンDNS
  • 同じ名前に対して、内部と外部で異なる応答を返します。一般的なパターン: パブリックなfoo.example.comはパブリックAnycast IPに解決され、内部のfoo.example.comはILBのRFC1918アドレスに解決されます。同じ名前のパブリックゾーンとプライベートゾーンで実装し、プライベートゾーンのスコープを適切なVPCに慎重に設定します。
• 内部サービスの名前付け
  • 一貫した内部サフィックス（例: svc.corp.internal）と、サービス指向のレコード（A/AAAA, SRV, またはディスカバリ固有のTXT）を使用します。動的にスケールするサービスには低いTTLを維持します。
  • GKEのサービス ディスカバリ: クラスタ内部の名前はCoreDNS内（svc.cluster.local）に留まります。名前空間やVPCを越えて公開するには、ILBのVIPをCloud DNSプライベートゾーンに発行するか、Service Directoryとの統合を使用します。
• Service Directoryとの統合
  • Service DirectoryとCloud DNSを介してサービスエンドポイントをDNSに自動的に発行し、名前空間/サービスごとにSRVおよびAレコードを生成します。プロデューサーとコンシューマーを分離し、サービスインスタンスのヘルスアウェアなディスカバリをサポートするのに役立ちます。
• プライベート サービス エンドポイント
  • Google APIへのPrivate Service Connect (PSC): PSCエンドポイントを使用してgoogleapis.comをプライベートに誘導するか、Restricted Google APIs VIP（199.36.153.8/30）をgoogleapis.comのプライベートゾーンと共に使用します。PSCはエンドポイントごとの制御を備えたリージョンローカルなプライベートIP接続を提供します。Restricted VIPはよりシンプルですが、デフォルトルート経由で到達可能なパブリックIP範囲を使用します。
  • プロデューサーサービスへのPSC: プライベートゾーンにPSCエンドポイントまたはILB VIPを指すA/AAAAレコードを作成します。カスタム内部ドメインの場合、Cloud DNSでプライベートゾーンを管理し、コンシューマーVPCにアタッチします。
• トレードオフ
  • PSC vs Restricted VIP: PSCはきめ細かな制御を提供し、下り（egress）の検査パスを回避します。リージョンごとにエンドポイント/DNSの設定が必要です。Restricted VIPは迅速にデプロイできますが、共有VIPを使用し、下り（egress）のルーティングポリシーと相互作用する可能性があります。
  • スプリットホライズンのリスク: スコープ設定を誤ったプライベートゾーンは、パブリックSaaSへのアクセスをブラックホール化する可能性があります。広範な展開の前に、カナリアVMとクエリロギングを介して検証します。

簡単な例: 内部ILBのマッピング

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

セキュリティ、トラフィック管理、オペレーション、移行

• DNSSECと完全性
  • パブリックゾーン: Cloud DNSでDNSSEC署名を有効にし、レジストラでDSを公開して、スプーフィングやキャッシュポイズニングから保護します。鍵のロールオーバー期間を計画し、検証の失敗を監視します。
  • プライベートゾーン: 通常、信頼されたネットワーク上で名前解決が行われるため、DNSSECの検証/署名は不要です。トランスポートセキュリティ（ハイブリッドリンク）とリゾルバの強化に重点を置きます。
• マネージドゾーン転送
  • Cloud DNSはAXFR/IXFRのプライマリまたはセカンダリとして機能できます。TSIGを使用して転送の認証/認可を行い、NOTIFYを使用してタイムリーな伝播を実現します。ゾーン転送パターンは、移行中の共存を簡素化し、規制や回復性の要件のためにオンプレミスのセカンダリをサポートします。
  • 障害モード: ファイアウォールによる転送のブロック、TSIGキーの不一致、SOAシリアルがインクリメントされていない、またはプライマリでIXFRが無効になっていることによる完全なAXFRの発生。
• ルーティングポリシーとヘルスチェック
  • Cloud DNSは、トラフィックステアリングポリシー（加重、地理的位置、レイテンシ、フェイルオーバー）をサポートします。エンドポイントにヘルスチェックをアタッチして、不健全な応答を自動的に取り下げます。
  • 設計のヒント: ポリシーターゲットごとのレコードセットは小さく保ちます。ユーザーのフットプリントに合わせてリージョン単位のスコープ設定を優先します。低いTTLと障害検出間隔を組み合わせて、フェイルオーバー時間を制限します。
  • 落とし穴: 過度に詳細な地理的マップは運用の複雑さを引き起こす可能性があります。一貫したヘルスシグナルの欠如はフラッピングにつながります。安定化のしきい値と、アプリケーションの動作に合わせたヘルスチェックのタイムアウトを使用します。
• トラブルシューティング
  • ツール: dig/nslookupに+trace、+short、+dnssecオプションを付けてチェーンを検証します。リゾルバクエリログ（DNSポリシー）と権威クエリログ（マネージドゾーン）についてCloud Loggingを確認します。
  • キャッシュ: どのリゾルバをテストしているか確認します（VMの/etc/resolv.confは通常、GoogleのVPCリゾルバを指しています）。TTLの変更をテストする際は、ローカルリゾルバのキャッシュをフラッシュします。ネガティブキャッシュ（RFC 2308）を考慮します。NXDOMAIN応答はSOA MINIMUM/ネガティブTTLに従ってキャッシュされます。
  • 一般的な問題: アウトバウンド転送とオンプレミスの条件付きフォワーダー間のループ。UDP 53のブロックまたはMTUの問題による切り捨てられた応答。プライベートゾーンによるパブリックゾーンの上書き。
• 運用パターン
  • 変更管理: トランザクションで変更をバッチ処理し、切り替え前にTTLを短縮し、カナリアVPCアタッチメントを使用して可視性を検証します。
  • ロギングとモニタリング: クエリロギングを選択的に有効にします。傾向分析のためにログをBigQueryにエクスポートし、SERVFAIL/NXDOMAINの急増に対するアラートを作成します。
  • アクセス制御: レコード変更のロールとネットワークアタッチメントのロールを分離します。意図しないドメインブロックを避けるため、レスポンスポリシー編集者には最小権限を適用します。
• 移行と共存
  • 共存: オンプレミスDNSがプライマリのままで、AXFR/IXFRを介してCloud DNSをセカンダリとして立ち上げます。またはその逆（Cloud DNSがプライマリ、オンプレミスがセカンダリ）も可能です。TSIGと許可リスト登録を使用します。
  • 条件付き転送: オンプレミスに残るドメインについては、転送ゾーンまたはアウトバウンド転送ポリシーを作成します。ハイブリッドリンクが高可用性（異なるピアとCloud Routerを持つデュアルVPN）であることを確認します。
  • 複数組織間のブリッジング: VPCをCloud VPN/Cloud Router経由で接続し、必要に応じて相互の条件付き転送またはピアリングを確立し、再配置されるゾーンにはゾーン転送を使用します。レジストラのNSまたはDSを変更するかなり前にTTLを短縮します。

短い例:

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

実践的な問題シナリオ

Contoso RetailとFabrikam Paymentsは別々のGoogle Cloud組織であり、ネットワークとDNSを最小限のダウンタイムで統合する間、1年間相互運用する必要があります。各組織は重複しない10.0.0.0/8スペースを使用しています。Contosoはsvc.contoso.internalの下で内部サービスをホストし、Fabrikamはpay.fabrikam.internalをオンプレミスでホストし続けます。両者は互いのプライベート名を解決し、いくつかのゾーンを段階的にCloud DNSに移行する必要があります。

アプローチ:

1. 回復力のあるハイブリッド接続を確立する

   • ContosoのハブVPCとFabrikamのオンプレミスルーター間に2つのCloud VPNトンネルを作成し、それぞれを異なるFabrikamのパブリックIPに接続し、両方のトンネルでCloud Router BGPを使用します。
   • 理由: デュアルトンネルと動的ルーティングにより、パスの冗長性が提供され、DNSターゲットへのルートが自動的に伝播されるため、UDP/TCP 53の非対称ルーティングのリスクが軽減されます。

2. 双方向で条件付き名前解決を実装する

   • Contoso側で、fabrikam.internalという転送ゾーンを作成し、FabrikamのオンプレミスDNSサーバー（例: 172.20.10.53および172.20.11.53）に転送し、それをアプリVPCにアタッチします。
   • Fabrikam側で、オンプレミスDNSに条件付きフォワーダーを設定し、svc.contoso.internalを、Cloud DNSインバウンドポリシーによって提供されるContosoのCloud DNSインバウンド転送IPに転送します。
   • 理由: 転送ゾーンは権威の重複を避け、各々がDNSを現在の場所に保持できるようにします。インバウンドサーバーは、Fabrikamのリゾルバを広範囲に変更することなく、Cloud DNSのプライベート名前解決をFabrikamに拡張します。

3. 転送ループを防ぎ、可視性の境界を強制する

   • Fabrikamの条件付きフォワーダーが、Fabrikamがまだ所有している名前についてcontoso.internalをContosoに転送し返さないようにします。同様に、Contosoはfabrikam.internalのみを転送するようにします。
   • Contosoのプライベートゾーンは、それを必要とするVPCにのみアタッチします。影響範囲を減らすためにグローバルにアタッチしないでください。
   • 理由: DNS再帰ループを排除し、プライベートゾーンによるパブリックドメインのシャドウイングを防ぎます。

4. マネージドゾーン転送を使用して共有ゾーンを移行する

   • 現在FabrikamのBINDプライマリでホストされているレガシー共有ゾーンlegacy.shared.internalについて、Cloud DNSをTSIG付きのセカンダリとして設定し、AXFR/IXFRのためにFabrikamのプライマリを許可リストに登録します。共存期間中はFabrikamをプライマリとして維持します。
   • 理由: セカンダリモードは、クライアントを変更することなくライブ同期を提供します。これにより、単一の信頼できる情報源 (Single Source of Truth) を維持しながら、Contosoでの安全な検証が可能になります。

5. 外部に公開されるサービスにスプリットホライズンを導入する

   • 顧客向けにグローバルHTTPSロードバランサのIPを指すレコードを持つパブリックゾーンcontoso.exampleを作成します。同じ名前を内部ILBアドレスにマッピングする、同じ名前のプライベートゾーンを作成し、内部VPCにアタッチします。
   • 理由: 外部ユーザーは引き続きエッジロードバランサに到達します。内部サービスはRFC1918経由でプライベートILBに到達し、一貫したホスト名を維持しながらレイテンシとコストを最適化します。

6. ファイアウォール経由でエグレスせずにGoogle APIへのプライベートアクセスを提供する

   • 外部IPを持たないContoso VMのために、Private Service Connect for Google APIsを有効にし、PSCエンドポイントにマッピングされるgoogleapis.comのマネージドプライベートDNSゾーンを作成します。
   • 理由: BigQueryおよびPub/SubへのアクセスがVPC内でプライベートかつローカルに保たれることを保証し、サードパーティのエグレスアプライアンスを回避し、セキュリティポスチャを維持します。

7. 可観測性と制御を有効にする

   • 関連するVPCのContosoのDNSポリシーでCloud DNSクエリロギングをオンにし、パブリックゾーンで権威クエリロギングをオンにします。既知の悪意のあるドメインを組織全体でブロックするためのレスポンスポリシールールを作成します。
   • 理由: クエリのテレメトリはトラブルシューティングとキャパシティプランニングをサポートします。レスポンスポリシーは、すべてのリゾルバに触れることなく、セキュリティのための中央制御を提供します。

8. 安全なTTLで変更管理を実行する

   • 移行対象のレコードのTTLを、変更の1週間前に60秒に短縮します。検証と切り替え（例: サービスをオンプレミスからGCP ILBに切り替える）の後、TTLを徐々に300〜600秒に引き上げます。
   • 理由: 短いTTLは移行中のリスクを限定します。高いTTLに戻すことで、安定化後のキャッシュ効率が向上します。

9. テスト、検証、強化する

   • 両側のカナリアVMから、digを+trace付きで実行し、権威パスを検証し、ログにSERVFAIL/NXDOMAINの急増がないことを確認し、リンク障害をシミュレートしてVPN冗長性によるDNSの動作を観察します。
   • 理由: 事前検証により、ループや可視性の問題を早期に検出します。障害シミュレーションにより、ハイブリッド解決がユーザーへの影響なしにトランスポートのインシデントを乗り切れることを検証します。

← ロード バランシング、Cloud CDN、グローバル トラフィック管理 · すべてのドメイン · Google およびマネージド サービスへのプライベート接続 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →