このページは Cloud Translation API によって翻訳されました。

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

Linux Windows

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

始める前に

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

このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール

Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. デフォルトのリージョンとゾーンを設定します。
REST

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

必要なロール

ゾーン 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 に移行するには、次の権限が必要です。

組織のポリシーの制約を設定する: orgpolicy.*
フォルダをゾーン DNS に移行する準備ができているかどうかを判断する:
- resourcemanager.folders.get
- resourcemanager.folders.list
- resourcemanager.organizations.get
- resourcemanager.projects.get
- resourcemanager.projects.list
グローバル DNS 名と VM メタデータを確認する: compute.projects.get
VM にメタデータを設定する: compute.instances.setMetadata
プロジェクト全体のメタデータを設定する: compute.projects.setCommonInstanceMetadata
VM がサービスアカウントを使用する場合: iam.serviceAccounts.actAs

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

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 に移行します。通常はプロジェクトオーナーが行います。

この画像は、ゾーン DNS への移行手順のフローチャートです。

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

ゾーン DNS への移行に向けた、フォルダまたは組織の準備状況を確認します。
フォルダまたは組織がゾーン DNS に移行する準備ができている場合:
1. 組織管理者は、今後グローバル DNS が使用されないように、フォルダまたは組織に組織のポリシーを設定します。
2. プロジェクトオーナーは、ゾーン DNS を使用するようにプロジェクトを移行します。
フォルダまたは組織がゾーン 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 のバージョンを確認するには:

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

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

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

組織管理者の手順

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

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

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

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

コンソール

コンソールで [IAM と管理] > [ID と組織] ページに移動します。

[ID と組織] に移動
組織の登録日を確認します。
- 2018 年 9 月 6 日以降に作成された組織では、デフォルトでゾーン DNS が使用されます。この場合は特に操作は必要ありません。
- 2018 年 9 月 6 日より前に作成された組織では、デフォルトでグローバル DNS が使用されるため、ゾーン DNS に移行する必要があります。
組織でグローバル DNS をデフォルトで使用している場合は、組織のポリシーの制約により、新しく作成されるすべてのプロジェクトのデフォルト DNS タイプがゾーン DNS に設定されているかどうかを確認します。
1. Google Cloud コンソールで [IAM と管理] > [組織のポリシー] ページに移動します。
2. [フィルタ] フィールドに「constraints/compute.setNewProjectDefaultToZonalDNSOnly」と入力します。
3. 制約が構成されている場合は、[新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] の名前をクリックします。
4. [ポリシーの詳細] ページで [ステータス] を確認します。
  - ステータスが [適用済み] の場合、デフォルトの内部 DNS タイプは、組織内で作成されるすべての新しいプロジェクトでゾーン DNS です。
  - それ以外の場合、プロジェクトのデフォルトの DNS タイプは組織がいつ作成されたかによって決まります。
5. 組織に対して制約が構成されていない場合、プロジェクトのデフォルトの DNS タイプは組織がいつ作成されたかによって決まります（最初の手順を参照）。

gcloud

organizations describe コマンドと resource-manager org-policies list コマンドを使用して、組織のデフォルトの DNS タイプを指定します。

組織の creationTime メタデータ値を確認します。
```
gcloud organizations describe ORGANIZATION_ID
```
ORGANIZATION_ID は、組織 ID 番号または組織のドメイン名に置き換えます。
- 2018 年 9 月 6 日以降に作成された組織では、デフォルトでゾーン DNS が使用されます。この場合、組織はすでにゾーン DNS を使用しているため、これ以上の対応は必要ありません。
- 2018 年 9 月 6 日より前に作成された組織では、デフォルトでグローバル DNS が使用されるため、ゾーン DNS に移行する必要があります。
組織でグローバル DNS をデフォルトで使用している場合は、新しく作成されるすべてのプロジェクトのデフォルトの DNS タイプをゾーン DNS に設定するように組織のポリシーの制約が構成されているかどうかを判断します。
```
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"
```
出力で constraints/compute.setNewProjectDefaultToZonalDNSOnly を探します。
1. 制約が構成されていて、Status が Enforced の場合、デフォルトの内部 DNS タイプは、組織内で新たに作成されるすべてのプロジェクトでゾーン DNS です。
2. 制約が組織に対して構成されていない、または適用されていない場合、デフォルトの内部 DNS タイプは組織の作成日によって決まります（最初の手順を参照）。

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

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

BigQuery データセットを作成します。
組織のアセットメタデータを 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: メタデータのエクスポート先のテーブル。テーブルが存在しない場合は作成されます。
Google Cloud コンソールの [BigQuery] ページに移動します。
[ クエリを新規作成] を選択します。
クエリエディタのテキスト領域に次の GoogleSQL クエリを入力して、[ 実行] をクリックします。
```
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 を使用するように設定されています。
省略可: 個々のプロジェクトの vmDnsSetting の詳細を表示するには、次の GoogleSQL クエリを入力して、[ 実行] をクリックします。
```
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 と互換性がないので、追加の操作が必要になります。

次の手順を完了します。

フォルダ ID を取得します。フォルダ ID が不明な場合:
1. Google Cloud コンソールで、[マネージドリソース] ページに移動します。
2. フィルタ Name:FOLDER_NAME を適用してフォルダ ID を取得します。
エクスポートされた compute.Project assets データを使用して、BigQuery テーブルにクエリを実行します。

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

次の GoogleSQL クエリを入力して、[ 実行] をクリックします。
```
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 番号
プロジェクト ID のリストをコピーして、ファイルに保存します。
次の 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 のアクセス権が必要です。

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

Google Workspace か Cloud Identity の特権管理者として Google Cloud コンソールにログインします。
コンソールで [組織のポリシー] ページに移動します。

[組織のポリシー] に移動
組織のポリシーを表示するフォルダまたは組織を選択します。Google Cloud コンソールに、使用可能な組織のポリシー制約のリストが表示されます。このリストは複数のページにまたがっている場合があります。
ゾーン DNS を適用するポリシーを見つけるには、[フィルタ] をクリックして [名前] を選択し、フィルタ名を [新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] に設定します。
ポリシー名をクリックして、その詳細を確認します。

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

デフォルトでは、フォルダまたは組織に対する適用は定義されていません。ただし、親フォルダに適用が定義されている場合は、適用を持つ最も近い親フォルダからその適用が継承されます。詳細については、階層評価についてをご覧ください。
組織のポリシーをカスタマイズするには、[編集] をクリックします。
編集ページで [カスタマイズ] を選択します。
[適用] で [オン] を選択します。

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

組織のポリシーの変更を確認するには、フォルダまたは組織のもとで新しいプロジェクトを作成して、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 に設定します。

Google Workspace か Cloud Identity の特権管理者として Google Cloud コンソールにログインします。
コンソールで [組織のポリシー] ページに移動します。

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

Google Cloud コンソールに、そのフォルダに対する組織のポリシーの制約のリストが 1 つ以上のページに表示されます。
ゾーン DNS を適用する組織のポリシーの制約を確認するには:
1. [フィルタ] をクリックします。
2. [名前] を選択します。
3. フィルタ名を [新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] に設定します。
組織のポリシーの制約名をクリックして、[ポリシーの詳細] ページを開きます。
[編集] をクリックします。
[編集] ページで、[カスタマイズ] を選択します。
[適用] で [オフ] を選択して、制約の適用を無効にします。これにより、フォルダ内のすべてのプロジェクトのデフォルトの内部 DNS タイプは、組織の作成日によって決まります。
[保存] をクリックします。

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

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

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

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

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

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

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

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

コンソール

Google Cloud コンソールで [メタデータ] ページに移動します。
[メタデータ] に移動
[メタデータ] タブで、vmdnssetting の設定を表示します。この値は、プロジェクトでグローバル DNS をデフォルトで使用するかどうかを示します。
- GlobalDefault: プロジェクトでグローバル DNS が有効になっています。
- ZonalOnly: プロジェクトでゾーン DNS が有効になっています。このプロジェクトは移行する必要はありません。

gcloud

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

次の gcloud CLI コマンドを実行して、vmDnsSetting の値を確認します。
```
  gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
  
```
PROJECT_ID は、プロジェクトの名前に置き換えます。

返される値は、プロジェクトでグローバル DNS をデフォルトで使用するかどうかを示しています。
- GLOBAL_DEFAULT: プロジェクトでグローバル DNS が有効になっています。
- ZONAL_ONLY: プロジェクトでゾーン DNS が有効になっています。このプロジェクトは移行する必要はありません。

REST

projects.get メソッドを使用して、vmDnsSetting の値を確認します。この例では、fields クエリパラメータを使用して、表示するフィールドのみを含めます。

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

PROJECT_ID をプロジェクト ID で置き換えます。

vmDnsSetting の値は、プロジェクトでグローバル DNS をデフォルトで使用するかどうかを示します。

GLOBAL_DEFAULT: プロジェクトでグローバル DNS が有効になっています。
ZONAL_ONLY: プロジェクトでゾーン DNS が有効になっています。このプロジェクトは移行する必要はありません。

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

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

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

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

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

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

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

[ログエクスプローラ] に移動
プロジェクトを選択します。
リソースとログ名のフィルタを適用します。
1. [リソース] をクリックします。
2. [リソースの選択] ダイアログで [VM インスタンス] を選択し、[適用] をクリックします。
3. [ログ名] をクリックします。
4. [ログ名の選択] ダイアログで [gdnsusage] を選択し、[適用] をクリックします。
  
  注: ログエクスプローラはグローバル DNS 使用ログを 1 日に 1 回のみ更新します。グローバル DNS の使用状況に関する最新情報については、プロジェクト内のグローバル DNS の使用状況を追跡するの手順をご覧ください。

別の方法として、クエリフィールドに次のように入力することもできます。

   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 を使用します。

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

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
[指標を選択] フィールドがあるツールバー右側で、[コードエディタ]、[MQL] または [PromQL] をクリックします。
クエリの入力フィールドに「MQL クエリ」という名前がない場合は、クエリの入力フィールド右下の [言語] で [MQL] を選択します。
クエリの入力フィールドに、次のテキストをそのまま入力します。
```
fetch compute.googleapis.com/Location
| metric 'compute.googleapis.com/global_dns/request_count'
| every 1d
| within 7d
```
注: every 1d と within 7d の設定により、7 日間の各日の結果が生成されます。このタイミングは、目的の間隔と期間に応じて調整できます。
[クエリを実行] ボタンをクリックします。

注: [自動実行] の切り替えが有効になっている場合、[クエリを実行] ボタンは表示されません。代わりに、クエリが自動的に実行されます。
Google Cloud コンソールに、2 つの指標（zonal_dns_ready と zonal_dns_risky）と、期間中に実行された、各指標に該当するクエリの数のグラフが表示されます。
zonal_dns_risky 指標の値を確認します。
- 値が 0 の場合、プロジェクトはゾーン DNS に移行できます。ゾーン DNS の準備ができているプロジェクトを移行するの説明に従って、プロジェクトを移行できます。
- 上のスクリーンショットに示されているように、値がゼロ以外の数値（0.02k など）の場合、ゾーン DNS に移行した後に一部のクエリが機能しなくなる可能性があります。ですので、プロジェクトは移行の準備ができていません。移行の準備ができていないプロジェクトを変更するの手順に進みます。

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

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

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

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

検索パスの改善を有効にして、複数ゾーンにまたがる DNS 名ルックアップを解決します。これにより、リソースに影響を与えることなく、プロジェクトの移行の準備ができる場合があります。
検索パスの調整で複数ゾーンにまたがるクエリがすべて移行されない場合、ゾーン 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 名を解決しようとします。

注: resolv.conf ファイルの手動変更が維持されるのは、DHCP リースが更新されるまでの間です。更新は、グローバル DNS の場合はデフォルトで 24 時間、ゾーン DNS に移行した後は 1 時間ごとです。検索パスの変更を長期間テストするために、いくつかの Linux ディストリビューションでは、DHCP ポリシーの先頭または末尾に項目を追加できるようになっています。DHCP ポリシーまたは構成ファイルの変更方法は、使用する Linux のディストリビューションによって異なります。たとえば、Red Hat Enterprise Linux と Debian では、/etc/dhcp/dhcpd.conf 構成ファイルを使用します。CentOS では、Network Manager コマンドラインユーティリティ nmcli を使用します。カスタムの DHCP と 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 名ルックアップを解決する

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

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

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

この設定をプロジェクトで数日間使用可能にした後、モニタリング指標を確認して、リスクの高い（複数ゾーンにまたがる）グローバル DNS クエリがまだあるかどうかを確認します。
- プロジェクトの値が 0 であれば、プロジェクトは移行の準備ができています。
- プロジェクトがゼロ以外の値を返す場合は、次のセクションで説明するように、すべてのグローバル DNS クエリ名がゾーン FQDN を使用するように変更します。

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

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

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

プロジェクトを移行する準備ができているかどうかを判断するの手順に沿って、プロジェクトのグローバル DNS の使用状況を表示します。ログエクスプローラを使用して、プロジェクト内の VM のグローバル DNS 使用状況にアクセスしてクエリを実行します。
[クエリ結果] ペインでは、各クエリに 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 フィールド情報を示しています。
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 クエリを更新したら、次の手順を行います。

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

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

プロジェクトでグローバル DNS をデフォルトで使用しているかどうかを確認するの手順を繰り返します。
プロジェクトメタデータが更新されたことをテストするには、次のコマンドを実行します。
```
gcloud compute project-info describe --flatten="vmDnsSetting"
```
このコマンドは ZONAL_ONLY を返すはずです。
VM の内部 DNS 名でゾーン DNS 名が使用されていることを確認します。
組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly が適用されていることを確認するには、次の操作を行います。
1. フォルダまたは組織の下に新しいプロジェクトを作成します。
2. VM インスタンスを作成し開始します。
3. VM がゾーン DNS 名を使用しているかどうかを確認します。

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

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

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

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

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

[新しいプロジェクトの内部 DNS 設定をゾーン DNS のみに設定する] の適用を [オフ] に設定します。
組織全体でグローバル DNS を使用するように戻す場合は、組織内のどのフォルダも組織のポリシー constraints/compute.setNewProjectDefaultToZonalDNSOnly を適用していないことを確認します。
次のセクションを使用して、プロジェクト、VM、コンテナにグローバル DNS が構成されていることを確認します。

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

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

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

プロジェクトメタデータや VM メタデータの値の設定方法については、カスタムメタデータの設定をご覧ください。
プロジェクト内のどの VM でも、vmDnsSetting メタデータ値が ZonalOnly に設定されていないことを確認します。
各 VM の DHCP リースを更新します。リースを更新するには、VM を再起動するか、リースが期限切れになるまで待つか、次のコマンドのいずれかを実行します。
- Linux VM: sudo dhclient -v -r
- Windows Server VM: ipconfig /renew

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

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

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

VM メタデータ値の設定方法については、カスタムメタデータの設定をご覧ください。
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 を無効にするには、次の手順を完了します。

コンテナと VM を保持するプロジェクトで、プロジェクトメタデータ設定 vmDnsSetting を GlobalDefault に設定します。
コンテナを再起動すると、DNS 設定が元の状態に戻ります。

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

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

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

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

次のステップ

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

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

始める前に

コンソール

gcloud

REST

必要なロール

必要な権限

DNS 名について

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

移行プロセスの概要

制限事項

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

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

組織管理者の手順

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

コンソール

gcloud

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

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

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

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

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

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

コンソール

gcloud

REST

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

別の方法として、クエリ フィールドに次のように入力することもできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

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

別の方法として、クエリフィールドに次のように入力することもできます。