内部 DNS タイプにゾーン DNS を使用する

ゾーン DNS は、複数リージョンにまたがる障害のリスクを軽減し、Compute Engine のプロジェクトの全体的な信頼性を向上させます。ゾーン DNS を使用すると、グローバル DNS の使用時に発生する可能性のある単一障害点の影響が軽減されます。

始める前に

• まだ設定していない場合は、認証を設定します。認証とは、Google Cloud のサービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

  2. Set a default region and zone.

  REST

  このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

必要なロール

ゾーン DNS への移行に必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

• 組織のポリシーを作成または更新する: フォルダまたは組織の組織のポリシー管理者（roles/orgpolicy.policyAdmin）
• フォルダがゾーン DNS に移行する準備ができているかどうかを判断する: フォルダまたは組織の参照者（roles/browser）
• ゾーン DNS を使用するようにプロジェクトを移行する: プロジェクトのプロジェクト編集者（roles/resourcemanager.projectEditor）
• プロジェクト内のゾーン DNS に VM を移行する: プロジェクトの Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）
• VM でサービス アカウントが使用されている場合: サービス アカウントまたはプロジェクトのサービス アカウント ユーザー（roles/iam.serviceAccountUser）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、ゾーン DNS への移行に必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

DNS 名について

ゾーン DNS 名には、VM の名前、VM が配置されているゾーン、VM があるプロジェクトが含まれます。グローバル DNS 名には、VM が配置されているゾーンは含まれません。

グローバル DNS 名を使用して VM を呼び出す場合:

• この名前はグローバル レベルで解決されます。
• 各 VM に固有の DNS 名が必要です。
• DNS 名の競合を回避するために、新規作成する VM の DNS 名を、同じプロジェクトに登録されている他のすべてのグローバル DNS 名と照らし合わせて確認する必要があります。

ゾーン DNS 名を使用して VM を呼び出す場合:

• この名前はゾーン内で解決されます。
• ゾーン DNS 名はゾーン内で一意である必要があります。たとえば、my-vm.zone1.google.com は zone1 に対して一意である必要があります。ただし、グローバル DNS 名とは異なり、ゾーン DNS を使用する場合、my-vm.zone2.google.com も有効な DNS 名です。

2018 年 9 月 6 日以降に作成された組織の Compute Engine は、デフォルトの内部 DNS の解決方法がゾーン DNS です。1 つのゾーン内のゾーン DNS 名は他のゾーンとは独立して機能するため、可用性特性に優れた、よりフォールト トレラントなマルチリージョン アプリケーションを構築できます。ゾーン DNS は無料で使用できます。ゾーン DNS は Cloud DNS とは異なります。

2018 年 9 月 6 日より前に作成されたプロジェクトは、デフォルトでグローバル DNS を使用するように構成されていました。これらのプロジェクトは引き続きグローバル DNS を使用できますが、ローカル リージョン リソースが別リージョンのサービス中断の影響を受けないように、これらのプロジェクトをゾーン DNS に移行することを強くおすすめします。ゾーン DNS を使用すると、DNS 登録で発生する障害が個々のゾーンに隔離されるため、グローバル DNS よりも信頼性が高くなります。これにより、単一障害点の影響が軽減されます。Google Cloud でサービスが停止しても、単一のゾーンに隔離され、リソースとコストに大きな影響は及びません。

グローバル DNS からゾーン DNS に移行する

2018 年 9 月 6 日以降に Google Cloud にオンボーディングしたすべての組織では、ゾーン DNS がデフォルトの内部 DNS タイプとしてグローバル DNS に置き換わっています。既存のプロジェクトでまだグローバル DNS が使用されている場合は、プロジェクトを移行して内部ゾーン DNS 名を使用することを強くおすすめします。ゾーン DNS に移行しないことで、次の問題が発生する恐れがあります。

• プロジェクトが現在ある、または過去にあったリージョンでも、コントロール プレーンの障害が発生しているリージョンは新しい VM を作成できない。
• マネージド インスタンス グループ（MIG）の自動スケーリングや自動修復など、ワークロードにとって重要な Compute Engine サービスの一部を使用できない。

グローバル DNS を使用するワークロードの信頼性を向上させる別の方法として、Cloud DNS の限定公開ゾーンに移行することもできます。Cloud DNS の限定公開ゾーンを使用すると、グローバル DNS で必要な名前の一意性チェックが不要になるとともに、障害を分離して DNS の名前解決が可能になります。このオプションの詳細については、Cloud DNS のドキュメントを参照するか、Cloud カスタマーケアまたはアカウント チームの担当者にお問い合わせください。Cloud DNS がゾーンやリージョンの停止を処理する方法については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。

移行プロセスの概要

ゾーン DNS の移行プロセスには、次の 2 つのレベルがあります。

• 組織またはフォルダレベル: フォルダまたは組織がゾーン DNS に移行する準備ができているかどうかを判断します。新しいプロジェクトがグローバル DNS を使用できないようにします。これは組織管理者が行います。
• プロジェクト レベル: 単一プロジェクトをグローバル DNS からゾーン DNS に移行します。通常はプロジェクト オーナーが行います。

通常、このプロセスには次の手順が含まれます。

1. ゾーン DNS への移行に向けた、フォルダまたは組織の準備状況を確認します。
2. フォルダまたは組織がゾーン DNS に移行する準備ができている場合:
   1. 組織管理者は、今後グローバル DNS が使用されないように、フォルダまたは組織に組織のポリシーを設定します。
   2. プロジェクト オーナーは、ゾーン DNS を使用するようにプロジェクトを移行します。
3. フォルダまたは組織がゾーン DNS に移行する準備ができていない場合:
   1. プロジェクト オーナーは、準備ができたプロジェクトをゾーン DNS に移行します。
   2. プロジェクト オーナーは、準備ができていないプロジェクトでのグローバル DNS の使用状況を調査します。
   3. プロジェクト オーナーは、検索パスの改善やその他の変更を適用して、プロジェクトをゾーン DNS に移行できるようにします。
   4. 組織管理者は、ゾーン DNS 移行に向けたフォルダまたは組織の準備状況を再度確認します。

制限事項

• ゾーン DNS はグローバル DNS を完全に置き換えるものではありません。一部のクエリタイプ（ゾーン間）は、検索パスの自動ルックアップを使用するゾーン DNS で解決されない可能性があります。移行前に、組織のフォルダとプロジェクトの移行準備状況を調べて、ゾーン DNS と互換性があることを確認してください。

• グローバル DNS からゾーン DNS への移行プロセスでは、検索パスに新しいドメイン（ZONE.c.PROJECT_ID.internal）が導入されます。Linux または Unix を実行している VM の検索パスにすでに 6 つのドメインがある場合は、VM が glibc バージョン 2.26 以降で実行されていることを確認します。glibc 2.25 以前の DHCP クライアントは、最大 6 つの検索ドメインしかサポートしないため、既存の検索ドメインを破棄する可能性があります。この上限は、以下を使用する VM には適用されません。

  • Windows のイメージ
  • Container-Optimized OS のイメージ
  • Debian 10 以降のイメージ
  • Fedora CoreOS（バージョン 27 以降）
  • RHEL 8 以降のイメージ
  • Ubuntu リリース 18.04 以降のイメージ
  • glibc バージョン 2.26 以降のその他のイメージ

• 検索パスの改善を有効にすると、NEIGHBOR_ZONE.c.PROJECT_ID.internal などの検索ドメインがいくつか追加されます。前述の制限事項で説明したように、glibc バージョン 2.25 以前を使用している場合、検索パスのドメイン上限を超えると、検索パスの既存のドメインが削除される可能性があります。

• Google Kubernetes Engine で検索パスの改善を使用するには、Google Kubernetes Engine バージョン 1.26 以降を使用する必要があります。

glibc のバージョンを確認する

VM で使用されている glibc のバージョンを確認するには:

1. Linux VM に接続します。
2. ldd --version を実行して glibc のバージョンを取得します。

glibc 2.25 以前を使用している場合は検索ドメインの数を確認する

1. Linux VM に接続します。

2. Linux VM の検索パスにすでに 6 つのドメインがあるかどうかを確認します。この情報を表示するには、cat /etc/resolv.conf を実行します。

組織管理者の手順

組織管理者は次のタスクを実行します。

• 組織がグローバル DNS をデフォルトで使用しているかどうかを確認する。
• フォルダまたは組織内のどのプロジェクトがグローバル DNS を使用しているかどうかを特定する。
• フォルダをゾーン DNS に移行する準備ができているかどうかを判断する。
• ゾーン DNS を新しいプロジェクトのデフォルトとして構成する。
• 組織のポリシーの制約から、ゾーン DNS に移行する準備ができていないフォルダを除外する。

組織でグローバル DNS をデフォルトで使用しているかどうかを確認する

組織の内部 DNS 名のデフォルトのタイプは、組織が作成された日と、組織のポリシーの制約 constraints/compute.setNewProjectDefaultToZonalDNSOnly が適用されているかどうかによって決まります。

フォルダまたは組織内のどのプロジェクトがグローバル DNS を使用しているかを特定する

グローバル DNS を使用しているプロジェクトの数を確認するには、BigQuery を使用して、組織の相対プロジェクトとそのメタデータを一覧表示するテーブルを作成することをおすすめします。このテーブルを使用して、グローバル DNS を使用するプロジェクトの合計数を表示するクエリを実行できます。

1. BigQuery データセットを作成します。

2. 組織のアセット メタデータを BigQuery テーブルにエクスポートします。

   1. Cloud Asset Inventory API が有効になっていることを確認します。
   2. Cloud Asset Inventory API の使用に必要な権限を構成します。

   3. 次の gcloud CLI コマンドを使用して、compute.googleapis.com/Project アセットをエクスポートします。

      gcloud asset export \
         --content-type resource \
         --organization 'ORGANIZATION_ID' \
         --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
         --asset-types='compute.googleapis.com/Project' \
         --output-bigquery-force
      

      次のように置き換えます。

      • ORGANIZATION_ID: 組織 ID 番号
      • PROJECT_ID: プロジェクト ID
      • DATASET_ID: BigQuery データセットの名前
      • TABLE_NAME: メタデータのエクスポート先のテーブル。テーブルが存在しない場合は作成されます。

3. Google Cloud コンソールの [BigQuery] ページに移動します。

4. [add_box クエリを新規作成] を選択します。

5. クエリエディタのテキスト領域に次の GoogleSQL クエリを入力して、[play_arrow 実行] をクリックします。

   SELECT
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
     count(*) as project_count
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   GROUP BY 1
   

   次のように置き換えます。

   • PROJECT_ID: プロジェクト ID
   • DATASET_ID: BigQuery データセットの名前
   • TABLE_NAME: 手順 2 でエクスポートされたメタデータを含むテーブル。

   vmDnsSetting の値が ZONAL_ONLY のプロジェクトにはゾーン DNS が構成されています。それ以外のプロジェクトはグローバル DNS を使用するように設定されています。

6. 省略可: 個々のプロジェクトの vmDnsSetting の詳細を表示するには、次の GoogleSQL クエリを入力して、[play_arrow 実行] をクリックします。

   SELECT
     SUBSTR(name,35) as project_id,
     JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   

フォルダをゾーン DNS に移行する準備ができているかどうかを判断する

この手順では、bash スクリプトと前のセクションで作成した BigQuery テーブルを使用して、フォルダの移行準備状況を判断します。

• すべてのプロジェクトで過去 30 日間にゾーン DNS と互換性のないクエリが行われていない場合、フォルダの準備はできています。
• フォルダが移行の準備ができていない場合、スクリプトは、移行の準備ができていない原因となっているフォルダ内のプロジェクト ID を返します。この結果リスト内のプロジェクトはまだゾーン DNS と互換性がないので、追加の操作が必要になります。

次の手順を完了します。

1. フォルダ ID を取得します。フォルダ ID が不明な場合:
   1. Google Cloud コンソールで、[マネージド リソース] ページに移動します。
   2. フィルタ Name:FOLDER_NAME を適用してフォルダ ID を取得します。

2. エクスポートされた compute.Project assets データを使用して、BigQuery テーブルにクエリを実行します。

   BigQuery テーブルの作成手順については、フォルダまたは組織内のどのプロジェクトがグローバル DNS を使用しているかを特定するをご覧ください。

   次の GoogleSQL クエリを入力して、[play_arrow 実行] をクリックします。

   SELECT
     SUBSTR(name,35) AS project_id,
   FROM PROJECT_ID.DATASET_ID.TABLE_NAME
   WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')
   

   次のように置き換えます。

   • PROJECT_ID: プロジェクト ID
   • DATASET_ID: BigQuery データセットの名前
   • TABLE_NAME: エクスポートされたメタデータを含むテーブル
   • FOLDER_NUMBER: フォルダ ID 番号

3. プロジェクト ID のリストをコピーして、ファイルに保存します。

4. 次の bash スクリプトを実行します。このスクリプトは、保存されたファイルに含まれるプロジェクト ID に対して反復処理を行い、フォルダが移行する準備ができているかどうかを判断します。

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

FILENAME は、プロジェクト ID リストを保存したファイルの名前に置き換えます。

移行の準備状況の分析結果をプロジェクト オーナーに伝えます。

• 安全に移行できるフォルダとプロジェクトについては、準備が整ったプロジェクトの移行を開始できることをプロジェクト オーナーに通知します。
• 安全に移行できないプロジェクトを含むフォルダについては、移行準備ができていないプロジェクトを変更するようプロジェクト オーナーに依頼してください。

新しいプロジェクトにデフォルトでゾーン DNS を適用する

2018 年 9 月 6 日より前に作成された組織で新しいプロジェクトを作成すると、そのプロジェクトで使用される内部 DNS タイプは、デフォルトでグローバル DNS になります。DNS 登録で発生する障害を個々のゾーンに隔離するには、組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly を組織レベルまたはフォルダレベルで適用します。

デフォルトの内部 DNS タイプをオーバーライドするように組織のポリシーを設定すると、新しく作成されたプロジェクトはデフォルトでゾーン DNS を使用します。この組織のポリシーは、Compute Engine API がすでに有効になっている既存のプロジェクトには影響しません。既存のプロジェクトをゾーン DNS に移行するには、既存のプロジェクトのゾーン DNS への移行をご覧ください。

このポリシーの変更を適用するには、フォルダまたは組織レベルで、IAM ロール roles/orgpolicy.policyAdmin のアクセス権が必要です。

フォルダや組織のポリシーを設定するには、次の手順に沿って操作します。

1. Google Workspace か Cloud Identity の特権管理者として Google Cloud コンソールにログインします。

2. コンソールで [組織のポリシー] ページに移動します。

   [組織のポリシー] に移動

3. 組織のポリシーを表示するフォルダまたは組織を選択します。Google Cloud コンソールに、使用可能な組織のポリシー制約のリストが表示されます。このリストは複数のページにまたがっている場合があります。

4. ゾーン DNS を適用するポリシーを見つけるには、[フィルタ] をクリックして [名前] を選択し、フィルタ名を [新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] に設定します。

5. ポリシー名をクリックして、その詳細を確認します。

   ポリシーの詳細ページには、制約に関する情報と、制約がどのように適用されているかが表示されます。

   デフォルトでは、フォルダまたは組織に対する適用は定義されていません。ただし、親フォルダに適用が定義されている場合は、適用を持つ最も近い親フォルダからその適用が継承されます。詳細については、階層評価についてをご覧ください。

6. 組織のポリシーをカスタマイズするには、[編集] をクリックします。

7. 編集ページで [カスタマイズ] を選択します。

8. [適用] で [オン] を選択します。

   これにより、組織内のすべての新しいプロジェクトで、デフォルトの内部 DNS タイプがゾーン DNS に設定されます。

9. [保存] をクリックします。

組織のポリシーの変更を確認するには、フォルダまたは組織のもとで新しいプロジェクトを作成して、VM インスタンスを作成して起動し、VM がゾーン DNS に対して有効になっているかどうかを確認します。

ワークロードに組み込まれた DNS 名クエリを解決するためにグローバル DNS が必要な場合は、適用を無効にすることで、組織レベルまたはフォルダレベルでこの変更をロールバックできます。

ゾーン DNS に移行する準備ができていないフォルダを除外する

組織内にゾーン DNS に移行する準備ができていないフォルダが数個しかない場合は、組織レベルで組織のポリシーを設定すると同時に、まだ移行の準備ができていないフォルダには除外を適用することをおすすめします。

次の例は、1 つのフォルダのみがゾーン DNS に移行する準備ができていない組織階層を示しています。

組織/Example.com

• folders/101
  • projects/301（移行準備完了）
  • folders/201
    • projects/303（準備未完了）
    • projects/304（移行準備完了）
• folders/102
  • projects/302（移行準備完了）

組織のポリシーからフォルダを除外するには、次の手順に沿って、フォルダレベルのポリシーの適用オプションを Off に設定します。

1. Google Workspace か Cloud Identity の特権管理者として Google Cloud コンソールにログインします。

2. コンソールで [組織のポリシー] ページに移動します。

   [組織のポリシー] に移動

3. [選択] をクリックして、組織のポリシーから除外するフォルダを選択します。

   Google Cloud コンソールに、そのフォルダに対する組織のポリシーの制約のリストが 1 つ以上のページに表示されます。

4. ゾーン DNS を適用する組織のポリシーの制約を確認するには:

   1. [フィルタ] をクリックします。
   2. [名前] を選択します。
   3. フィルタ名を [新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] に設定します。

5. 組織のポリシーの制約名をクリックして、[ポリシーの詳細] ページを開きます。

6. [編集] をクリックします。

7. [編集] ページで、[カスタマイズ] を選択します。

8. [適用] で [オフ] を選択して、制約の適用を無効にします。これにより、フォルダ内のすべてのプロジェクトのデフォルトの内部 DNS タイプは、組織の作成日によって決まります。

9. [保存] をクリックします。

組織のポリシー制約のカスタマイズの詳細については、Resource Manager ドキュメントのブール型制約用のポリシーのカスタマイズをご覧ください。

プロジェクト オーナーの手順

グローバル DNS からゾーン DNS への移行中、プロジェクト オーナーは次のタスクを実行します。

• プロジェクトのデフォルトの内部 DNS タイプを特定する。
• プロジェクトがゾーン DNS に移行する準備ができているかどうかを判断する。
• ゾーン DNS を使用してプロジェクトを移行する。
• プロジェクト内のグローバル DNS の使用状況を追跡する。
• ゾーン DNS に移行する準備ができていないプロジェクトを変更する。
• ゾーン DNS へのプロジェクトの移行が完了したことを確認する。

プロジェクト オーナーは、次のオプションのタスクを行うこともできます。

• プロジェクトがグローバル DNS を使用するように戻す。
• ゾーン DNS 移行に関するバナーを非表示にする。

プロジェクトでグローバル DNS をデフォルトで使用しているかどうかを確認する

プロジェクトを調べて、グローバル DNS からゾーン DNS に移行する必要があるかどうかを確認します。移行する必要があるのは、プロジェクト内で作成された内部 DNS 名のデフォルトとしてグローバル DNS が構成されているプロジェクトのみです。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

プロジェクトを移行する準備ができているかどうかを判断する

プロジェクトをゾーン DNS に移行する必要がある場合は、Google Cloud コンソールの [VM インスタンス] ページに、ゾーン DNS の移行に関する通知バナーが表示されます。

プロジェクトの [VM インスタンス] ページを表示したときに、プロジェクトを移行する準備ができている場合（ゾーン DNS と互換性がある場合）、バナーでゾーン DNS を使用することが推奨されます。この推奨は、プロジェクト内の内部 DNS の使用状況に基づいていますが、過去 100 日間の使用に限定されています。

プロジェクトがゾーン DNS に移行する準備ができていない場合は、別のバナーが表示されます。

グローバル DNS の使用状況を表示するには、[View Global DNS Usage] ボタンをクリックします。すると Google Cloud コンソールの [ログ エクスプローラ] のページが表示されます。このページで、過去 30 日間の移行ブロッククエリのログを確認できます。バナーのリンクをクリックすると、logName フィルタを使用してグローバル DNS クエリと相対ログ フィールドを pull するよう、[ログ エクスプローラ] のページが構成されます。

バナーのボタンを使わずにこの情報を表示する手順は次のとおりです。

1. Google Cloud コンソールで、[ログ エクスプローラ] のページに移動します。

   [ログ エクスプローラ] に移動

2. プロジェクトを選択します。

3. リソースとログ名のフィルタを適用します。

   1. [リソース] をクリックします。
   2. [リソースの選択] ダイアログで [VM インスタンス] を選択し、[適用] をクリックします。
   3. [ログ名] をクリックします。

   4. [ログ名の選択] ダイアログで [gdnsusage] を選択し、[適用] をクリックします。

   resource.type="gce_instance"
   log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
   

プロジェクト内のグローバル DNS 使用状況を追跡する

ゾーン DNS に移行するプロジェクトの準備状況を追跡するために、次の 2 つの指標が作成されます。

• zonal_dns_ready: 指定された時間間隔で完了したクエリのうち、グローバル DNS ではなくゾーン DNS を使用して解決できるクエリの合計数。
• zonal_dns_risky: 指定された時間間隔で完了したクエリのうち、ゾーン DNS では解決できないクエリの合計数。これらのクエリについて、Compute Engine は現在のホスト名から相対内部 IP アドレスを特定できませんでした。この指標がゼロ以外の場合、プロジェクトは移行の準備ができていないということになります。

これらの指標で使用される期間は 100 日です。

これらの指標を表示するには、Google Cloud コンソールの Metrics Explorer を使用します。

1. Google Cloud コンソールで、[leaderboardMetrics Explorer] ページに移動します。

   Metrics Explorer に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

2. [指標を選択] フィールドがあるツールバー右側で、[コードエディタ]、[MQL] または [PromQL] をクリックします。

3. クエリの入力フィールドに「MQL クエリ」という名前がない場合は、クエリの入力フィールド右下の [言語] で [MQL] を選択します。

4. クエリの入力フィールドに、次のテキストをそのまま入力します。

   fetch compute.googleapis.com/Location
   | metric 'compute.googleapis.com/global_dns/request_count'
   | every 1d
   | within 7d
   

5. [クエリを実行] ボタンをクリックします。

   Google Cloud コンソールに、2 つの指標（zonal_dns_ready と zonal_dns_risky）と、期間中に実行された、各指標に該当するクエリの数のグラフが表示されます。

   

6. zonal_dns_risky 指標の値を確認します。

   • 値が 0 の場合、プロジェクトはゾーン DNS に移行できます。ゾーン DNS の準備ができているプロジェクトを移行するの説明に従って、プロジェクトを移行できます。
   • 上のスクリーンショットに示されているように、値がゼロ以外の数値（0.02k など）の場合、ゾーン DNS に移行した後に一部のクエリが機能しなくなる可能性があります。ですので、プロジェクトは移行の準備ができていません。移行の準備ができていないプロジェクトを変更するの手順に進みます。

ゾーン DNS の準備ができているプロジェクトを移行する

基本的に、次の移行プロセスを使用できます。

1. アプリケーションがゾーンのみの設定に対応しているかどうかを調べて、問題がある場合は解決します。
   • ハードコードされたグローバル DNS 名を使用するアプリケーションがある場合は、ゾーン DNS 名を使用するように更新します。
   • アプリケーションが VM 名を使用して別のゾーンの VM にアクセスする場合は、宛先ゾーン名がクエリに追加されていることを確認してください（例: DESTINATION_VM_NAME.DESTINATION_ZONE_NAME）。
   • 共有 VPC ネットワークを使用するサービス プロジェクトで VM の DNS 名を解決するには、VM のゾーン完全修飾ドメイン名（FQDN）を使用する必要があります。

2. Google Cloud コンソールの [VM インスタンス] ページにある、バナーの [Use Zonal DNS] ボタンをクリックします。これにより、ゾーン DNS を使用するようにプロジェクトのメタデータが変更されます。

   別の方法として、プロジェクトを手動で変更して、デフォルトでゾーン DNS を使用することもできます。詳しくは、ゾーン DNS を使用するようにプロジェクトと VM を手動で更新するおよび新しいプロジェクトがグローバル DNS をデフォルトで使用しないようにするをご覧ください。

ゾーン DNS を使用するようにプロジェクトと VM を手動で更新する

プロジェクトがゾーン DNS に移行する準備が整っていることを確認したら、メタデータを更新して、ゾーン DNS 名のみを使用するようにプロジェクトと VM を構成できます。プロジェクトまたは VM の vmDnsSetting メタデータ エントリを設定して、VM でゾーン DNS を有効にします。特定の VM に vmDnsSetting メタデータ エントリを設定すると、その VM のプロジェクト メタデータから継承された vmDnsSetting 設定がオーバーライドされます。

vmDnsSetting 変数は以下の設定をサポートしています。

• 推奨: プロジェクト メタデータで vmDnsSetting=ZonalOnly を設定します。これにより、検索パスを使用する場合、VM にはゾーン DNS 名（VM_NAME.ZONE.c.PROJECT_ID.internal）でのみアクセスできます。VM は引き続き、ゾーンとグローバルの両方の検索パスを保持しますが、内部 DNS 名に ZONE が含まれていないグローバル DNS 名は機能しなくなります。この設定が有効な場合、同じゾーンと同じプロジェクト内の VM のみがグローバル名を使用して相互にアクセスできます。vmDnsSetting が ZonalOnly に設定された VM に他の VM がアクセスする場合、ゾーン DNS 名を使用しているときのみアクセス可能で、グローバル DNS 名や検索パスを使用してその VM にアクセスすることはできません。これは、アプリケーションがサポートしている限り、より信頼性が高く望ましいオプションです。

  この vmDnsSetting=ZonalOnly 設定は、スタンドアロン プロジェクトと、2018 年 9 月 6 日以降に Compute Engine API を有効にした組織で作成されたプロジェクトの VM では、デフォルト設定です。

• vmDnsSetting=GlobalDefault を設定すると、VM はグローバルとゾーンの両方の DNS 名を登録しますが、ドメイン名と検索パスのエントリにはデフォルトでグローバル DNS 名のみを使用します。これは、スタンドアロン プロジェクトと、2018 年 9 月 6 日より前に Compute Engine API を有効にした組織で作成されたプロジェクトの VM のデフォルト設定です。

プロジェクト メタデータや VM メタデータの値の設定方法については、カスタム メタデータの設定をご覧ください。

VM に vmDnsSetting メタデータ エントリを構成したら、VM の DHCP リースを更新します。リースを更新するには、VM を再起動するか、リースが期限切れになるまで待つか、次のコマンドのいずれかを実行します。

• Linux VM: sudo dhclient -v -r
• Windows Server VM: ipconfig /renew

DHCP リースを更新したら、VM がゾーン DNS で有効になっていることを確認します。

移行の準備ができていないプロジェクトを変更する

移行の準備ができていないプロジェクトとは、過去 30 日間または 100 日間など、一定の期間内にリスクの高い DNS クエリが少なくとも 1 回行われたプロジェクトを意味します。リスクの高いクエリとは、ゾーン DNS 名（VM_NAME.ZONE.c.PROJECT_ID.internal）を使用してシームレスに解決できない、グローバル DNS 名（VM_NAME.c.PROJECT_ID.internal）を使用して VM を呼び出すクエリです。リスクの高いクエリには、次の属性があります。

• 別のプロジェクトの VM を呼び出す
• 別のゾーンの VM を呼び出す

リスクの高いクエリを含むプロジェクトで移行前にリスクの高い DNS ルックアップをすべて排除するには、通常、いくつかの追加作業が必要になります。

移行の準備ができていないプロジェクトについては、次の手順を行います。

1. 検索パスの改善を有効にして、複数ゾーンにまたがる DNS 名ルックアップを解決します。これにより、リソースに影響を与えることなく、プロジェクトの移行の準備ができる場合があります。
2. 検索パスの調整で複数ゾーンにまたがるクエリがすべて移行されない場合、ゾーン DNS 名を使用するようにクエリを手動で更新できます。

検索パスの改善機能について

デフォルトでは、ほとんどの Linux ディストリビューションが DHCP 情報を resolv.conf に格納しています。最小限のグローバル resolv.conf file は次のとおりです。

domain c.PROJECT_ID.internal
search c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

search 構成オプションは、DNS の解決の実行時に使用するホスト名をリストするために使用されます。DNS サーバーは、DNS レコードが一致するまで、検索パス内の各ホスト名を順に使用してクエリを解決しようとします。たとえば、VM が ping my-vm を呼び出すと、検索パスのドメインが元のクエリに追加され、たとえば、my-vm.c.PROJECT_ID.internal を使用して完全修飾ドメイン名（FQDN）を取得します。一致する場合、DNS リゾルバは内部 IP アドレスを回答として返します。一致しない場合、検索パスの次のドメインを使用して DNS 名を解決しようとします。

VM 検索パスにゾーンドメインを追加すると、一部のプロジェクトで移行の準備ができる場合があります。たとえば、VM が us-west4-c ゾーンにあるとします。この VM は、us-west4-b ゾーンにある myapp-vm という名前の別の VM を呼び出します。

• VM を myapp-vm として呼び出すと、Compute Engine は、myapp-vm.c.PROJECT_ID.internal のように、いずれかの検索パスを VM 名に追加する FQDN を使用して DNS 名の解決を試みます。
• ターゲット VM がゾーン DNS を使用する場合、ターゲット VM の FQDN は myapp-vm.us-west4-b.c.PROJECT_ID.internal として登録されます。そのため、DNS 名を解決できません。
• 検索リストに us-west4-b.c.PROJECT_ID.internal を追加すると、us-west4-b.c.PROJECT_ID.internal が VM 名に追加されたときに DNS 名 myapp-vm を解決できます。

Google は、VM と同じリージョン内のすべてのゾーンで VM のゾーン DNS 名を自動的に検索する、検索パスの改善機能を提供しています。結果として、resolv.conf ファイルや DHCP ポリシーを更新しなくても、複数ゾーンにまたがるクエリを解決できます。検索パスの改善により、同一リージョン内の複数ゾーンにまたがるクエリの最大 80% を解決できます。この機能は、リスクの高いクエリを含むプロジェクトの大半でゾーン DNS への移行の準備を整えるのに役立ちます。

検索パスの改善を有効にして、複数ゾーンにまたがる DNS 名ルックアップを解決する

検索パスの改善機能を有効にするには、次の手順で操作します。

1. 次のように project-info add-metadata コマンドを実行します。

   gcloud compute project-info add-metadata  \
       --metadata=enable-search-path-improvement=true
   

2. この設定をプロジェクトで数日間使用可能にした後、モニタリング指標を確認して、リスクの高い（複数ゾーンにまたがる）グローバル DNS クエリがまだあるかどうかを確認します。

   • プロジェクトの値が 0 であれば、プロジェクトは移行の準備ができています。
   • プロジェクトがゼロ以外の値を返す場合は、次のセクションで説明するように、すべてのグローバル DNS クエリ名がゾーン FQDN を使用するように変更します。

ゾーン DNS 名を使用するようにクエリを手動で更新する

検索パスの改善機能を使用して DNS 名検索パスにゾーンドメインを追加しても、複数ゾーンにまたがるクエリがすべて移行されない場合は、ログ エクスプローラを使用して、プロジェクト内のグローバル DNS の使用状況を確認できます。

ゾーン完全修飾ドメイン名（FQDN）を使用するように手動で変更する必要があるグローバル DNS クエリを特定するには、次の手順を行います。

1. プロジェクトを移行する準備ができているかどうかを判断するの手順に沿って、プロジェクトのグローバル DNS の使用状況を表示します。ログ エクスプローラを使用して、プロジェクト内の VM のグローバル DNS 使用状況にアクセスしてクエリを実行します。

2. [クエリ結果] ペインでは、各クエリに jsonPayload フィールドがあります。各 jsonPayload フィールドには次の情報が含まれています。

   • ソース VM 名、そのプロジェクト ID、ゾーン名。
   • 宛先 VM 名、そのプロジェクト ID、ゾーン名。

   • ゾーン DNS 名では解決できないグローバル DNS クエリの更新方法に関する情報を提供するデバッグ メッセージ。これらは移行をブロックするクエリとみなされ、デバッグと修正が必要になります。

     "To use Zonal DNS, update the Global DNS query sent from the source VM
     VM_NAME.c.PROJECT_ID.internal to the following zonal
     FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"
     

   • クエリ数。その日に送信元 VM が宛先 VM に送信する移行ブロッククエリの数を示します。

   次のスクリーンショットは、ログ エクスプローラ コンソール ページの jsonPayload フィールド情報を示しています。

   

3. jsonPayload の情報をもとに、どの FQDN を使用してグローバル DNS クエリを手動で更新しゾーン DNS を使用するようにするかを決定し、そしてプロジェクトの移行準備を整えます。FQDN を更新して互換性を解決する最も一般的なユースケースは次のとおりです。

   • メタデータ サーバーからの内部 DNS 名: ゾーン DNS への移行直後に、返された DNS 名がゾーン FQDN に変更されるため、対応は必要ありません。DNS 名がキャッシュに保存されている場合は、もう一度呼び出すだけでキャッシュ値を更新できます。
   • 別のリージョンの VM へのアクセスに使用される内部 DNS 名: 異なるリージョンの VM に内部 DNS 名を使用するアプリケーションがある場合は、DHCP ポリシーまたは構成ファイルを変更して、別のリージョンのゾーンを含めることができます。
   • ハードコードされたグローバル FQDN: VM にハードコードされたグローバル FQDN 名を使用するアプリケーションがある場合は、内部 DNS 名またはゾーン FQDN を使用するようにアプリケーション内の呼び出しを更新できます。この変更を行うには、Terraform でコードまたは構成を変更します。
   • 共有 VPC ネットワークを使用するサービス プロジェクトの VM: 共有 VPC ネットワークを使用するサービス プロジェクトの VM の DNS 名を解決するには、VM のゾーン FQDN を使用する必要があります。

ゾーン DNS を使用するようにグローバル DNS クエリを更新したら、次の手順を行います。

1. ログ エクスプローラ ページを使用して、グローバル DNS の使用状況を再度クエリします。ブロックしているグローバル DNS クエリをすべて修正すると、クエリ結果にデバッグログは表示されなくなります。
2. モニタリング指標を再度確認して、リスクの高い DNS クエリがすべて削除されているかどうかを確認します。

ゾーン DNS へのプロジェクトの移行が完了したことを確認する

1. プロジェクトでグローバル DNS をデフォルトで使用しているかどうかを確認するの手順を繰り返します。

2. プロジェクト メタデータが更新されたことをテストするには、次のコマンドを実行します。

   gcloud compute project-info describe --flatten="vmDnsSetting"
   

   このコマンドは ZONAL_ONLY を返すはずです。

3. VM の内部 DNS 名でゾーン DNS 名が使用されていることを確認します。

4. 組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly が適用されていることを確認するには、次の操作を行います。

   1. フォルダまたは組織の下に新しいプロジェクトを作成します。
   2. VM インスタンスを作成し開始します。
   3. VM がゾーン DNS 名を使用しているかどうかを確認します。

グローバル DNS を使用するように戻す

デフォルトの内部 DNS タイプをグローバル DNS に戻すと、ゾーン DNS への移行を元に戻すことができます。これは、組織、プロジェクト、VM、またはコンテナのレベルで行うことができます。

組織またはフォルダでグローバル DNS を使用するように戻す

グローバル DNS を使用するように組織またはフォルダを元に戻すには、次の手順を完了します。

1. 組織レベルまたはフォルダレベルで組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly を無効にします。このポリシーを変更する方法については、新しいプロジェクトにデフォルトでゾーン DNS を適用するをご覧ください。

   [新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] の適用を [オフ] に設定します。

2. 組織全体でグローバル DNS を使用するように戻す場合は、組織内のどのフォルダも組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly を適用していないことを確認します。

3. 次のセクションを使用して、プロジェクト、VM、コンテナにグローバル DNS が構成されていることを確認します。

プロジェクトでグローバル DNS を使用するように戻す

グローバル DNS を使用するようにプロジェクトを元に戻すには、次の手順を完了します。

1. プロジェクトのメタデータに vmDnsSetting=GlobalDefault を追加します。

   プロジェクト メタデータや VM メタデータの値の設定方法については、カスタム メタデータの設定をご覧ください。

2. プロジェクト内のどの VM でも、vmDnsSetting メタデータ値が ZonalOnly に設定されていないことを確認します。

3. 各 VM の DHCP リースを更新します。リースを更新するには、VM を再起動するか、リースが期限切れになるまで待つか、次のコマンドのいずれかを実行します。

   • Linux VM: sudo dhclient -v -r
   • Windows Server VM: ipconfig /renew

VM でグローバル DNS を使用するように戻す

特定の VM をグローバル DNS を使用するように戻すには、次の手順を完了します。

1. VM のメタデータに vmDnsSetting=GlobalDefault を追加します。

   VM メタデータ値の設定方法については、カスタム メタデータの設定をご覧ください。

2. DNS 構成を強制的に変更するには、次のいずれかのコマンドを使用して VM のネットワークを再起動します。

• Container-Optimized OS または Ubuntu の場合:

  sudo systemctl restart systemd-networkd
  

• CentOS、RedHat EL、Fedora CoreOS、Rocky Linux の場合:

  sudo systemctl restart network
  

  または

  sudo systemctl restart NetworkManager.service
  

• Debian の場合:

  sudo systemctl restart networking
  

• nmcli が含まれる Linux システムの場合:

  sudo nmcli networking off
  sudo nmcli networking on
  

• Windows の場合:

  ipconfig /renew
  

コンテナでグローバル DNS を使用するように戻す

アプリケーションまたはワークロードをコンテナ、Google Kubernetes Engine、または App Engine フレキシブル環境で実行する場合は、コンテナ設定内の DNS 構成が自動的には更新されず、コンテナの再起動が必要になることがあります。これらのコンテナアプリでゾーン DNS を無効にするには、次の手順を完了します。

1. コンテナと VM を保持するプロジェクトで、プロジェクト メタデータ設定 vmDnsSetting を GlobalDefault に設定します。

2. コンテナを再起動すると、DNS 設定が元の状態に戻ります。

グローバル DNS からゾーン DNS への移行プロセスのトラブルシューティングを行う

移行プロセスに問題が発生した場合は、トラブルシューティング ガイドをご覧ください。

Google Cloud コンソールでゾーン DNS 移行に関するバナーを非表示にする

Google Cloud コンソールの [VM インスタンス] ページに表示される、ゾーン DNS 移行通知バナーの [閉じる] ボタンをクリックします。これにより、プロジェクトにバナーが表示されるのを無期限に防ぐことができます。

閉じたバナーをもう一度表示するには、Cloud カスタマーケアにお問い合わせください。

次のステップ

• 組織、フォルダ、プロジェクト間の関係については、Google Cloud のリソース階層をご覧ください。
• Compute Engine の内部 DNS について詳しく学ぶ。