内部 DNS


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

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

内部 DNS について

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

  • VM インスタンスの内部 DNS 名は、そのプライマリ内部 IP アドレスにのみ解決されます。内部 DNS 名を使用してインスタンスの外部 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 インスタンス名を再利用できます。たとえば、インスタンスが別のゾーンにある限り、instance-1 という名前のインスタンスを複数持つことができます。
グローバル(プロジェクト全体)DNS VM_NAME.c.PROJECT_ID.internal 2018 年 9 月 6 日より前に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。 VM インスタンス名は、プロジェクト全体で一意でなければなりません。グローバル DNS では、プロジェクト内で VM インスタンス名を再利用できません。

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

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

プロジェクトまたはインスタンス レベルで使用される内部 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 を使用したカスタム レコード

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

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

カスタムホスト名

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

内部 DNS 名と共有 VPC

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

VM インスタンス用の内部 DNS 名の特定

次の手順を使用して、VM インストールに割り当てられている内部 DNS 名を読み取ります。内部 DNS 名の信頼できるソースは、メタデータ サーバーです。

  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: インスタンスが配置されているゾーン
  • PROJECT_ID: インスタンスが属するプロジェクト

内部 DNS による VM へのアクセス

メタデータ サーバーは、VM によって発行された DNS クエリのネームサーバー リゾルバでもあります。メタデータ サーバーは、内部 DNS 名と外部 DNS 名の両方に対する、すべての DNS クエリを解決します。外部 DNS クエリの場合、メタデータ サーバーはリクエストを Google の公開ネームサーバーに渡します。

次の例では、ping を実行してゾーン DNS を使用するインスタンスに接続します。この方法は、インスタンスへの受信 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: インスタンスが配置されているゾーン
  • PROJECT_ID: インスタンスが属するプロジェクト

内部 DNS と resolv.conf

デフォルトでは、ほとんどの Linux ディストリビューションが DHCP 情報を resolv.conf に格納しています。Compute Engine の各インスタンスは、DHCP リースを 24 時間ごとに更新するように構成されています。ゾーン DNS に対して有効化されているインスタンスでは、DHCP リースが 1 時間ごとに期限切れとなります。DHCP 更新によってこのファイルが上書きされるため、それまでに行われた変更が元に戻されます。ゾーン DNS を使用するインスタンスでは、resolv.conf ファイル内にゾーンエントリとグローバル エントリの両方があります。

DHCP 情報を systemd.resolved.conf に格納する Linux ディストリビューションでは、/etc/systemd/resolved.conf ファイルでゾーン DNS エントリとグローバル DNS エントリを確認できます。

Note: VPC networks have a default maximum transmission unit (MTU) of 1460 bytes. However, the network MTU can be set to the standard Ethernet MTU of 1500 bytes, up to 8896 bytes for jumbo frames, or as low as 1300. For more information about network MTUs, see the maximum transmission unit overview.

ゾーン 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: インスタンスが配置されているゾーン
  • PROJECT_ID: インスタンスが属するプロジェクト

ゾーン 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: イメージが属するプロジェクト

グローバル 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 は、インスタンスが属するプロジェクトで置き換えます。

グローバル 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: イメージが属するプロジェクト

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

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

Debian 9

/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 名に移行することをおすすめします。

プロジェクトやインスタンスの DNS 名の構成

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

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

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

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

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

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

  • Linux インスタンス: sudo dhclient -v -r
  • Windows Server インスタンス: 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 Console にログインします。

  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 名を使用して別のゾーンのインスタンスにアクセスする場合は、クエリに宛先のゾーン名(<DESTINATION_VM_NAME>.<DESTINATION_ZONE_NAME> など)が追加されていることを確認してください。
    • 共有 VPC ネットワークを使用してサービス プロジェクトの VM の DNS 名を解決するには、VM のゾーン完全修飾ドメイン名を使用する必要があります。
  2. 内部ゾーン DNS を使用するようにプロジェクトを切り替えるには、プロジェクト レベルのメタデータVmDnsSetting=ZonalOnly を設定します。

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

プロジェクトまたはインスタンス上のグローバル DNS への復帰

特定のインスタンス上のグローバル DNS に戻すには、インスタンスのメタデータに以下を追加します。VmDnsSetting=GlobalDefault

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

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 をプロジェクトとインスタンスに対して設定して、コンテナを再起動する必要があります。これで、DNS 設定は元の状態に戻ります。

次のステップ

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