既存の Cloud DNS 転送設定をアウトバウンド エンドポイントに移行する

このドキュメントでは、既存の Cloud DNS 転送設定を移行してアウトバウンド エンドポイントを使用するために必要な作業の概要について説明します。

既存の Cloud DNS 転送設定を移行する

既存の Cloud DNS 転送設定をアウトバウンド エンドポイントを使用するように移行するには、次の 4 つのフェーズがあります。

準備

準備フェーズでは、移行を開始する前に、プロキシ専用サブネット、通常のサブネット、アウトバウンド エンドポイントを作成します。また、オンプレミス ネットワークにリージョン プロキシ専用サブネットの IP アドレス範囲の戻りルートがあり、オンプレミス ファイアウォール ルールでリージョン プロキシ専用サブネットの IP アドレス範囲からのインバウンド DNS トラフィックが許可されていることを確認します。

  1. プロキシ専用サブネットを作成する: アウトバウンド エンドポイントをデプロイする各リージョンに、最小サイズ /26（64 個のアドレス）のプロキシ専用サブネットを作成します（まだ作成していない場合）。
  2. 通常のサブネットを特定または作成する: アウトバウンド エンドポイントをデプロイする各リージョンで、プライマリ IP 範囲で使用可能な内部 IPv4 アドレスを持つ通常のサブネットを特定または作成します。
  3. アウトバウンド エンドポイントを作成する: アウトバウンド エンドポイントを作成し、ターゲット VPC ネットワーク、リージョン、通常のサブネット（--subnetwork=REGULAR_SUBNET）、使用可能な内部 IPv4 アドレス（--endpoint-ip=IP_ADDRESS_STRING）に関連付けます。Cloud DNS は、静的 IP 予約リソースを自動的に作成して管理し、エンドポイントを VPC ネットワーク内のリージョン プロキシ専用サブネットにバインドします。

  4. オンプレミスのファイアウォールとルートを更新する: オンプレミス ネットワークに、リージョン プロキシ専用サブネットの IP アドレス範囲の戻りルートがあることを確認します。オンプレミス環境と外部環境にファイアウォール ルールを追加して、リージョン プロキシ専用サブネットの IP アドレス範囲から発信されるインバウンド DNS トラフィック（UDP ポート 53 と TCP ポート 53）を許可します。

確認（省略可）

必要に応じて、検証フェーズを使用してアウトバウンド エンドポイントの構成を検証できます。

  1. テスト転送ゾーンを作成する: テストドメイン（test.corp.example.com など）用に新しい一時転送ゾーンを作成します。
  2. エンドポイントを構成する: 新しいアウトバウンド エンドポイントを使用するようにテストゾーンを構成します。
  3. テスト VM を起動する: 関連する VPC ネットワークで、一時的なテスト VM を起動します。
  4. 解決を確認する: テスト VM から、dig または nslookup を使用して、テストゾーン内のホスト（dig host.test.corp.example.com など）をクエリします。DNS レスポンスが正常に返されることを確認します。オンプレミスまたは外部の DNS サーバーログで、サーバーが新しいリージョン プロキシ専用サブネットの送信元 IP アドレスからクエリを受信したことを確認します。また、dns_query ログで jsonPayload.egressPath が OUTBOUND_ENDPOINT に設定されていることを確認します。

本番環境の移行

本番環境の移行フェーズでは、アウトバウンド エンドポイントを使用するように転送ゾーンとサーバー ポリシーを更新し、クエリログを確認してクエリが正常に解決されていることを確認します。

  1. 転送ゾーンとサーバー ポリシーを更新する: 移行する転送ゾーンまたはサーバー ポリシーごとに、構成を編集し、順方向パスをデフォルトの 35.199.192.0/19 範囲からアウトバウンド エンドポイントに変更します。
  2. 解決と健全性をモニタリングする: Cloud DNS クエリログ（jsonPayload.egressPath=OUTBOUND_ENDPOINT、jsonPayload.outboundEndpoint、jsonPayload.egressError を確認）と、移行されたゾーンの既存のモニタリング指標を確認して、クエリが正常に解決されていることを確認します。
    • dns.googleapis.com/query/response_count を使用して、クエリ量とレスポンス ステータス コードを追跡します。
  3. 大量移行と事前ウォーミング戦略:
    • 自動スケーリングのレイテンシ: 基盤となる Google 管理のプロキシ インフラストラクチャでは、自動スケーリングのスピンアップ レイテンシが約 10 分あります。
    • 増分ロールアウト: 集計クエリの量がリージョンあたり 10,000 秒間クエリ数（QPS）を超える場合は、ゾーンを段階的に（一度に 1 ゾーンずつ）移行して、自動スケーリングのランプアップ中にクエリがドロップされないようにします。
    • サポートのプリウォーミング: リージョンあたり 10,000 QPS をすぐに超える大規模な単一ゾーンの移行では、トラフィックを徐々に増やします（例: 10%、25%、50%、100%）。または、移行を計画する前に Google Cloudアカウント チームまたはサポートに連絡して、スケジュールされたメンテナンスの時間枠中にインフラストラクチャのプリウォーミングをリクエストします。リクエストで、次の情報を指定します。
      • プロジェクト ID
      • ターゲット リージョン
      • 推定ピーク QPS

クリーンアップ

本番環境の移行が成功したことを確認したら、以前の転送メカニズムをクリーンアップする必要があります。

  1. 完全な移行を確認する: プロジェクト内の必要なすべての転送ゾーンとサーバー ポリシーで、デフォルトの 35.199.192.0/19 範囲が使用されていないことを確認します。
    • オンプレミスの DNS ログを確認し、安全な期間（24 時間など）にこの範囲から送信されるトラフィックがないことを確認します。
  2. 以前のファイアウォール ルールを削除する: すべてのトラフィックがアウトバウンド エンドポイントに移動されたことを確認したら、デフォルトの 35.199.192.0/19 範囲からのインバウンド DNS トラフィックを許可していたオンプレミスのファイアウォール ルールを安全に削除できます。このルールを削除または調整する前に、他の Google Cloud サービスがこのルールを使用していないことを確認してください。

ロールバック

移行をロールバックする必要がある場合は、次の操作を行います。

  1. 転送ゾーンまたはサーバー ポリシーを元に戻す: 影響を受けるゾーンまたはサーバー ポリシーを編集し、転送をデフォルトの 35.199.192.0/19 範囲に戻します。
  2. ファイアウォール ルールを復元する: 35.199.192.0/19 からのインバウンド DNS トラフィックを許可するルールが引き続き有効であることを確認します。移行が正常に完了してクリーンアップ フェーズに入るまで、このルールを削除しないでください。

次のステップ