内部 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 インスタンス名は、ゾーン内では一意である必要がありますが、ゾーン間では繰り返し使用できます。たとえば、インスタンスが異なるゾーンにある限り、instance-1 という名前のインスタンスを複数持つことができます。
グローバル(プロジェクト全体)DNS VM_NAME.c.PROJECT_ID.internal 2018 年 9 月 6 日より前に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。 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 によるカスタム レコード

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

自動的に作成された内部 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 ファイル内にゾーンエントリとグローバル エントリの両方があります。

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

注: VPC ネットワークのデフォルトの最大伝送単位(MTU)1460 バイトです。ただし、ネットワーク MTU は 1500 バイトに設定できます。ネットワーク MTU の背景については、最大伝送単位をご覧ください。

ゾーン 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=ZonalPreferred を設定すると、ゾーン DNS 検索パスが有効になりますが、グローバル DNS 名も引き続き保持されます。この設定を持つインスタンスどうしは、ゾーンとグローバルのどちらの DNS 名でも互いを参照でき、グローバル DNS 名のみが構成されたインスタンスも引き続き参照できます。このオプションは、ゾーン DNS 名を試して、テストするための中間ステップとして使用できます。
  • 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 名を使用するように既存のインスタンスとアプリを移行することを強くおすすめします。ゾーン DNS 名により、リージョン間のサービス停止のリスクを軽減できます。

一般的には、次の移行プロセスを使用できます。

  1. アプリがゾーンのみの設定に対応しているかどうかを調べて、問題がある場合は解決します。
    • アプリからインスタンスを参照するときに、インスタンス名またはグローバル完全修飾ドメイン名を使用している場合: インスタンス名とグローバル インスタンス名は、必ずしもゾーンのみの環境で解決されるわけではありません。これらの名前については、ゾーン完全修飾ドメイン名を使用するように更新することをおすすめします。
    • アプリで特定のグローバル完全修飾ドメイン名形式を前提としている場合: 特定のドメイン名形式を前提とする必要があるということは、一般に、アプリ設計に根本的な問題があることを意味します。アプリがドメイン名の形式とは無関係に機能するように設計することをおすすめします。
    • ドメイン名の変更を想定していないアプリ: ドメイン名の変更を想定していないアプリもあります。その場合、新しい名前を取得するために完全な再起動が必要になることがあります。可能であれば、インスタンスのドメイン名の変更を識別して処理するようにアプリを更新してください。
  2. アプリがゾーンドメイン名のみを使用して正しく動作するようになったら、その VPC ネットワーク上のグローバル名を無効にできます。VmDnsSetting=ZonalOnly 設定を使用するように内部 Virtual Private Cloud ネットワークのインスタンスを構成します。この設定では、ゾーン DNS 名のみが使用されます。
    1. インスタンスの 1 つで VmDnsSetting=ZonalOnly を有効にするために、この値をカスタム メタデータの中で設定します
    2. そのインスタンスの DHCP リースを更新します。これで、このインスタンスではゾーン DNS 名が使用されるようになります。
      • Linux インスタンス: sudo dhclient -v -r
      • Windows Server インスタンス: ipconfig /renew
    3. そのインスタンスでアプリをテストして、想定どおりに機能することを確認します。
    4. VmDnsSetting=ZonalOnly を有効にしてから DHCP リースを更新するプロセスを、VPC ネットワーク内の残りのインスタンスでも行います。すべてのインスタンスがゾーン DNS 名のみを使用して期待どおりに動作するようになるまで、このプロセスを繰り返します。
  3. プロジェクト内のすべてのインスタンスが VmDnsSetting=ZonalOnly 設定を使用するようになるまで、このプロセスを各 Virtual Private Cloud ネットワークで繰り返します。VmDnsSetting=ZonalOnly をプロジェクト レベルのメタデータに設定すると、この設定がそのプロジェクトの中で作成されたインスタンスに自動的に適用されます。

プロジェクトまたはインスタンスでゾーン DNS を無効にする

特定のインスタンスでゾーン DNS を無効にするには、VmDnsSetting=GlobalOnly をそのインスタンスのメタデータで設定します。プロジェクト全体でゾーン DNS を無効にするには、VmDnsSetting=GlobalOnly をプロジェクト メタデータで設定するとともに、どのインスタンスにおいても個別に 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=GlobalOnly をプロジェクトとインスタンスに対して設定して、コンテナを再起動する必要があります。これで、DNS 設定は元の状態に戻ります。

次のステップ

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