内部 DNS


Google Cloud の Virtual Private Cloud ネットワークには、同じネットワーク内の仮想マシン(VM)インスタンスが内部 DNS 名を使用して互いにアクセスできるようにする内部 DNS サービスがあります。VM の内部 A レコードは、.internal の DNS ゾーンに作成されます。VM の PTR レコードは、対応するリバースゾーンに作成されます。インスタンスを管理している間、Google Cloud がこれらの DNS レコードを自動的に作成、更新、削除します。

たとえば、VM を削除すると、Google Cloud は .internal DNS 名に関連する A レコードと PTR レコードを自動的に削除します。次に、同じ名前の新しい VM を作成すると、Google Cloud は置換用の新しいレコードを作成します。

内部 DNS について

内部 DNS 名の仕様は次のとおりです。

  • VM の内部 DNS 名は、そのプライマリ内部 IP アドレスにのみ解決されます。内部 DNS 名を使用して VM の外部 IP アドレスに接続することはできません。

  • 内部 DNS 名は、セカンダリ エイリアス IP に解決するように構成できません。

  • 内部 DNS 名は、同じネットワーク内の VM からのみ解決できます。これらの VM は、ネットワークと同じプロジェクトにあっても、同じ共有 VPC ネットワークを使用するサービス プロジェクトにあってもかまいません。サービス プロジェクト内の VM の DNS 名を解決するには、VM の FQDN を使用する必要があります。内部 DNS を使用して別のネットワーク内の VM に接続することはできません。

内部 DNS 名のタイプ

Google Cloud には、内部 DNS 名が 2 種類あります。デフォルトの内部 DNS タイプは、Compute Engine API を有効にした時期に基づいて設定されます。

一般に、個々のゾーンへの DNS 登録で発生した障害を隔離することにより、より高い信頼性が保証されるため、ゾーン DNS の使用を強くおすすめします。

内部 DNS タイプ 完全修飾ドメイン名(FQDN) プロジェクトのデフォルト タイプ
ゾーン DNS VM_NAME.ZONE.c.PROJECT_ID.internal 2018 年 9 月 6 日以降に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。 VM 名は、それぞれのゾーンで一意でなければなりません。ただし、ゾーン DNS を使用すると、複数のゾーンにわたって VM 名を再利用できます。たとえば、各 VM が異なるゾーンにある限り、instance-1 という名前の VM を複数持つことができます。
グローバル(プロジェクト全体)DNS VM_NAME.c.PROJECT_ID.internal 2018 年 9 月 6 日より前に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。 VM 名は、プロジェクト全体で一意でなければなりません。グローバル DNS では、プロジェクト内で VM 名を再利用できません。

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

  • VM_NAME: VM の名前。ゾーン DNS の場合、この値はゾーン内で一意にする必要がありますが、ゾーン間では繰り返すことができます。グローバル DNS の場合、VM 名はプロジェクト全体で一意でなければなりません。
  • ZONE: インスタンスが配置されているゾーン。
  • PROJECT_ID: VM が属するプロジェクト。

プロジェクトまたはインスタンス レベルで使用される内部 DNS 名の種類を制御する方法については、プロジェクトまたはインスタンスの DNS 名の構成をご覧ください。

PTR レコードと内部 DNS

Google Cloud の内部 DNS サービスは、次のリバースゾーンにある VM の PTR レコードを自動的に作成します。

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa.17.172.in-addr.arpa.、...31.172.in-addr.arpa. まで。

Cloud DNS を使用したカスタム レコード

Cloud DNS 限定公開ゾーンを使用して、VM のカスタム DNS エントリを作成できます。PTR レコードを構成すると、指定したカスタム URL で VM のデフォルトの内部 DNS URL をオーバーライドできます。

自動的に作成された内部 DNS の PTR 名をオーバーライドするカスタム PTR レコードを作成するには、限定公開ゾーン内の RFC 1918 アドレス用の PTR レコードをご覧ください。

カスタムホスト名

VM を作成するときに、VM のカスタムホスト名を指定できます。この方法で割り当てられたカスタムホスト名は内部 DNS によって解決されません。カスタムホスト名を使用する場合、該当するゾーンに対応する DNS レコードを作成する必要があります(たとえば、Cloud DNS を使用します)。詳細については、カスタムホスト名を持つ VM インスタンスを作成するをご覧ください。

内部 DNS 名と共有 VPC

IP アドレスがホスト プロジェクトの共有 VPC ネットワークにある場合でも、内部 DNS 名を使用して VM の内部 IP アドレスを参照できます。共有 VPC では、ゾーンまたはグローバル(プロジェクト全体)の内部 DNS 名のプロジェクト ID 部分が、サービス プロジェクトの ID です。

VM の内部 DNS 名を確認する

VM インスタンスに割り当てられた内部 DNS 名を読み取るには、次の操作を行います。内部 DNS 名を取得するには、hostname メタデータ エントリをクエリします。

  1. VM に接続します
  2. hostname メタデータに対してクエリを実行します。

    Linux VM

    curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
      -H "Metadata-Flavor: Google"
    

    Windows VM

    Invoke-RestMethod `
      -Headers @{"Metadata-Flavor" = "Google"} `
      -Uri "http://metadata.google.internal/computeMetadata/v1/instance/hostname"
    

メタデータ サーバーでは、次のいずれかの形式で VM のホスト名が返され、VM によって使用される内部 DNS 名のタイプが示されます。

  • ゾーン DNS: VM_NAME.ZONE.c.PROJECT_ID.internal
  • グローバル DNS: VM_NAME.c.PROJECT_ID.internal

出力の中で:

  • VM_NAME: VM の名前
  • ZONE: VM を配置するゾーン
  • PROJECT_ID: VM が属するプロジェクト

内部 DNS で VM にアクセスする

次の例では、ping を使用して、ゾーン DNS を使用する VM に接続します。この方法は、インスタンスへの受信 ICMP トラフィックを許可するファイアウォール ルールを作成した場合に機能します。

$ ping VM_NAME.ZONE.c.PROJECT_ID.internal -c 1

PING VM_NAME.ZONE.c.PROJECT_ID.internal (10.240.0.17) 56(84) bytes of data.
64 bytes from VM_NAME.ZONE.c.PROJECT_ID.internal (10.240.0.17): icmp_seq=1 ttl=64 time=0.136 ms

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

  • VM_NAME: VM の名前
  • ZONE: VM を配置するゾーン
  • PROJECT_ID: VM が属するプロジェクト

内部 DNS と DHCP

Compute Engine の各 VM は、DHCP リースを 24 時間ごとに更新するように構成されています。ゾーン DNS に対して有効化されている VM では、DHCP リースが 1 時間ごとに期限切れとなります。ゾーン DNS を使用する VM では、DHCP 構成ファイル内にゾーンエントリとグローバル エントリの両方があります。

デフォルトでは、ほとんどの Linux ディストリビューションが DHCP 情報を resolv.conf に格納しています。手動で resolv.conf を編集しても、その VM で DHCP リースが期限切れとなるたびに、そのファイルはデフォルトの DHCP に戻されます。resolv.conf ファイルに静的な変更を加えるために、Linux ディストリビューションによっては、DHCP ポリシーの先頭または末尾にアイテムを追加できるようになっています。

DHCP ポリシーまたは構成ファイルの変更方法は、使用する Linux のディストリビューションによって異なります。たとえば、Red Hat Enterprise Linux と Debian では、/etc/dhcp/dhcpd.conf 構成ファイルを使用します。CentOS では、Network Manager コマンドライン ユーティリティ nmcli を使用します。

カスタムの DHCP と DNS のネットワーク設定を構成する方法については、オペレーティング システムのドキュメントをご覧ください。

resolv.conf ファイルの例

デフォルトでは、ほとんどの Linux ディストリビューションが DHCP 情報を resolv.conf に格納しています。systemd-resolved は DNS のリゾルバ サービスも提供します。このリゾルバを構成するには、/etc/systemd/resolved.conf.d/ にある /etc/systemd/resolved.conf ファイルと他の *.conf ファイルを編集します。DHCP 情報を resolved.conf に格納する Linux ディストリビューションでは、/etc/systemd/resolved.conf ファイルでゾーン DNS エントリとグローバル DNS エントリを確認できます。

これらのファイルには、次の制限があります。

  • 検索パスで処理できるのは 6 レコードのみであり、そのうち 3 レコードは Compute Engine によって提供されます。エントリを検索パスに追加した結果としてエントリの総数が 6 を超えるような場合、6 番目のエントリよりも後の検索ルールは OS により適用されません。これが原因で、Compute Engine の機能が停止する可能性があります。たとえば、インスタンス名で VM にアクセスすることができなくなります。
  • 手動で resolv.conf を編集しても、その VM で 24 時間の DHCP リースが期限切れとなるたびに、そのファイルはデフォルトの DHCP に戻されます。ゾーン DNS を使用している VM では、DHCP リースは 1 時間ごとに期限切れとなります。resolv.conf ファイルに静的な変更を加えるために、Linux ディストリビューションによっては、DHCP ポリシーの先頭または末尾にアイテムを追加できるようになっています。

ゾーン DNS 構成

ゾーン resolv.conf ファイルのサンプル:

# Local domain name. Computed from your project name.
domain ZONE.c.PROJECT_ID.internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

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

  • ZONE: VM インスタンスが配置されているゾーン
  • PROJECT_ID: VM が属するプロジェクト

ゾーン dhcp.lease ファイルのサンプル:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.9;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "ZONE.c.PROJECT_ID.internal.", "c.PROJECT_ID.internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "VM_NAME.ZONE.c.PROJECT_ID.internal";
  option domain-name "ZONE.c.PROJECT_ID.internal";
  renew 4 2017/11/16 02:15:52;
  rebind 4 2017/11/16 02:43:59;
  expire 4 2017/11/16 02:51:29;
}

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

  • VM_NAME: VM の名前
  • ZONE: VM インスタンスが配置されているゾーン
  • PROJECT_ID: VM が属するプロジェクト

グローバル DNS 構成

グローバル resolv.conf ファイルのサンプル:

# Local domain name. Computed from your project name.
domain c.PROJECT_ID.internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search c.PROJECT_ID.internal google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

PROJECT_ID は、VM が属するプロジェクトに置き換えます。

グローバル dhcp.lease ファイルのサンプル:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.8;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "c.PROJECT_ID.internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "VM_NAME.c.PROJECT_ID.internal";
  option domain-name "c.PROJECT_ID.internal";
  renew 4 2017/11/16 12:07:00;
  rebind 4 2017/11/16 22:44:53;
  expire 5 2017/11/17 01:44:53;
}

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

  • VM_NAME: VM の名前
  • PROJECT_ID: VM が属するプロジェクト

dhclient.conf ファイルの例

/etc/dhcp/dhclient.conf ファイルのサンプル:

# Configuration file for /sbin/dhclient.
#
...
append domain-search "mydomain.com";
prepend domain-name-servers 172.16.1.1;

この例では、mydomain.com は新しい検索ドメイン、172.16.1.1 は DNS サーバーの IP です。

ゾーン DNS 名

ゾーン DNS 名には、VM の名前、VM が配置されているゾーン、VM があるプロジェクトが含まれます。グローバル DNS 名には、VM が配置されているゾーンは含まれません。ロケーション内のゾーン DNS 名は他のロケーションとは無関係に機能します。そのため、開発するマルチリージョン アプリのフォールト トレラントを高めて可用性を向上できます。

既存のプロジェクトや組織では引き続きグローバル DNS 名を使用できますが、リージョンの分離とマルチリージョンの信頼性を高めるためにゾーン DNS 名に移行することをおすすめします。

プロジェクトまたは VM の DNS 名を構成する

VmDnsSetting 変数をプロジェクト メタデータと VM メタデータのいずれかで設定して、VM に対しゾーン DNS とグローバル DNS を有効にします。VmDnsSetting 変数を特定の VM のメタデータで設定すると、その変数が VM のプロジェクト メタデータから継承された VmDnsSetting 変数よりも優先されます。

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

  • 推奨: VmDnsSetting=ZonalOnly を設定すると、VM の参照はゾーン DNS 名でのみ可能になります。VM は引き続き、ゾーンとグローバルの両方の検索パスを保持しますが、グローバル DNS 名は機能しなくなります。この設定を持つ VM を他の VM が参照するときは、ゾーン DNS 名のみ使用可能であり、グローバルの DNS 名や検索パスを使用してその VM を参照することはできません。これは、アプリがサポートしている限り、より信頼性が高く望ましいオプションです。これは、スタンドアロン プロジェクトと、2018 年 9 月 6 日以降に Compute Engine API を有効にした組織で作成されたプロジェクトの VM では、デフォルト設定です。
  • VmDnsSetting=GlobalDefault を設定すると、VM はグローバルとゾーンの両方の DNS 名を登録し、デフォルトのドメイン名と検索パスのエントリにはグローバル名のみを使用します。これは、スタンドアロン プロジェクトと、2018 年 9 月 6 日より前に Compute Engine API を有効にした組織で作成されたプロジェクトの VM のデフォルト設定です。

なお、プロジェクトを別の組織に移行しても、プロジェクトのデフォルトの DNS 名は変更されません。

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

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

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

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

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

内部グローバル DNS に比べ、内部ゾーン DNS では DNS 登録の障害を個々のゾーンに隔離することで信頼性を高めます。可能な限り、ゾーン 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. 組織のポリシーを表示するフォルダまたは組織を選択します。使用可能な組織のポリシーの制約のリストが 1 つ以上のページに表示されます。

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

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

  6. ポリシーの詳細ページには、制約に関する情報と、制約が現在どのように適用されているかが表示されます。デフォルトでは、フォルダまたは組織に対する適用は定義されていません。ただし、親フォルダに適用が定義されている場合は、適用を持つ最も近い親フォルダから適用が継承されます。詳細については、階層評価についてをご覧ください。

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

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

  9. [適用] で、適用オプションを次のように選択します。

    • 制約を適用するには、[オン] を選択します。新しいプロジェクトの場合、デフォルトの内部 DNS タイプはゾーン DNS です。
    • 制約を無効にするには、[オフ] を選択します。デフォルトのプロジェクト DNS タイプは、組織の作成時刻によって決まります。
  10. [保存] をクリックします。

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

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

既存のプロジェクトをゾーン DNS 名に切り替える

グローバル DNS は、2018 年 9 月 6 日以降に Google Cloud にオンボーディングしたすべての新しい組織のデフォルトの内部 DNS タイプとして、ゾーン DNS に置き換えられました。既存のプロジェクトで、まだグローバル DNS が使用されている場合は、これらのプロジェクトを内部ゾーン DNS 名を使用するように切り替えることを強くおすすめします。ゾーン DNS により、複数リージョンの停止によるリスクを軽減できます。

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

  1. アプリがゾーンのみの設定に対応しているかどうかを調べて、問題がある場合は解決します。
    • アプリでハードコードされた内部グローバル DNS 名を使用している場合は、内部ゾーン DNS 名を使用するように修正します。
    • VM 名を使用して別のゾーンの VM にアクセスする場合は、宛先ゾーン名がクエリに追加されていることを確認します(例: <DESTINATION_VM_NAME>.<DESTINATION_ZONE_NAME>)。
    • 共有 VPC ネットワークを使用してサービス プロジェクトの VM の DNS 名を解決するには、VM のゾーン完全修飾ドメイン名を使用する必要があります。
  2. 内部ゾーン DNS を使用するようにプロジェクトを切り替えるには、プロジェクト レベルのメタデータVmDnsSetting=ZonalOnly を設定します。

プロジェクト メタデータが更新されたことをテストするために、gcloud compute project-info describe --flatten="commonInstanceMetadata[VmDnsSetting]" を実行できます。コマンドによって返される結果は ZonalOnlyです。

プロジェクトまたは VM のグローバル DNS に戻す

特定の VM のグローバル DNS に戻すには、VM のメタデータに VmDnsSetting=GlobalDefault を追加します。

プロジェクトのグローバル DNS に戻すには、プロジェクトのメタデータに VmDnsSetting=GlobalDefault を追加します。また、どの VM も VmDnsSetting メタデータ値で個別に構成されていないことを確認します。プロジェクト メタデータや VM メタデータの値の設定方法については、カスタム メタデータの設定をご覧ください。

DNS 構成の変更を強制的に適用するには、VM のネットワークを再起動します。

  • コンテナ用に最適化された OS / Ubuntu: sudo systemctl restart systemd-networkd
  • CentOS / RHEL / Fedora CoreOS / Rocky Linux: sudo systemctl restart network
  • Debian: sudo systemctl restart networking
  • Windows: ipconfig /renew

アプリをコンテナ、Google Kubernetes Engine、App Engine フレキシブル環境で実行する場合は、コンテナ設定内の DNS 構成が自動的には更新されず、コンテナの再起動が必要になることがあります。このようなコンテナアプリに対してゾーン DNS を無効にするには、VmDnsSetting=GlobalDefault をプロジェクトと VM に対して設定して、コンテナを再起動する必要があります。これで、DNS 設定は元の状態に戻ります。

次のステップ

  • Google Cloud VPC ネットワークの詳細については、VPC の概要をご覧ください。
  • VPC ネットワークの作成、変更の詳細については、VPC の使用をご覧ください。