内部 DNS

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

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

内部 DNS について

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

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

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

  • 内部 DNS 名を他の VM から解決するには、その VM が同じプロジェクト内にあって同じ VPC または従来のネットワークを使用している必要があります。同じプロジェクト内にある場合でも、内部 DNS を使用して他のネットワーク内のインスタンスに接続することはできません。

PTR レコードと内部 DNS

GCP の内部 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.

内部 DNS と Cloud DNS

内部 DNS と Cloud DNS は異なるサービスです。 内部 DNS 名は GCP が自動的に作成するものです。VM にカスタム DNS 名を作成する必要がある場合、Cloud DNS 限定公開ゾーンを使用できます。

自動的に作成された内部 DNS の PTR レコードを上書きするカスタム PTR レコードを作成する必要がある場合は、Cloud DNS ドキュメントのプライベート ゾーンでの PTR レコードの使用をご覧ください。

カスタムホスト名

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

内部 DNS 名のタイプ

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

内部 DNS タイプ 完全修飾ドメイン名(FQDN) プロジェクトのデフォルト タイプ
ゾーン DNS [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal 2018 年 9 月 6 日以降に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。
グローバル(プロジェクト全体)DNS [INSTANCE_NAME].c.[PROJECT_ID].internal 2018 年 9 月 6 日より前に Compute Engine API を有効にしたすべての組織またはスタンドアロン プロジェクトのデフォルトです。

ここで:

  • [INSTANCE_NAME] はインスタンスの名前です。
  • [ZONE] はインスタンスが配置されているゾーンです。
  • [PROJECT_ID] はインスタンスが属するプロジェクトです。

プロジェクト レベルまたはインスタンス レベルで、どのタイプの内部 DNS 名を使用するかを制御できます。プロジェクトまたはインスタンスの DNS 名の構成をご覧ください。

内部 DNS 名と共有 VPC

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

VM の内部 DNS 名を特定する

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

  1. インスタンスに接続します。
  2. インスタンス メタデータからホスト名を表示します。

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

ホスト名の形式は、VM が使用する内部 DNS 名のタイプを示します。

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

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

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

$ ping [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal -c 1

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

ここで:

  • [INSTANCE_NAME] はインスタンスの名前です。
  • [ZONE] はインスタンスが配置されているゾーンです。
  • [PROJECT_ID] はインスタンスが属するプロジェクトです。

内部 DNS と resolv.conf

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

ゾーン 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 "[INSTANCE_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;
}

ここで:

  • [INSTANCE_NAME] はインスタンスの名前です。
  • [ZONE] はインスタンスが配置されているゾーンです。
  • [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 "[INSTANCE_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;
}

ここで:

  • [INSTANCE_NAME] はインスタンスの名前です。
  • [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 名には、インスタンスの名前、インスタンスが配置されているゾーン、インスタンスを所有するプロジェクトが含まれます。グローバル DNS 名には、インスタンスが配置されているゾーンは含まれません。あるロケーションでのゾーン DNS 名は他のロケーションとは無関係に機能するので、開発するマルチリージョン アプリケーションの耐障害性を高めて可用性を向上できます。

既存のプロジェクトや組織で引き続きグローバル DNS 名を使用できますが、ゾーン DNS 名に移行することをおすすめします。

プロジェクトまたはインスタンスの DNS 名の構成

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

  • VmDnsSetting=ZonalOnly を設定すると、インスタンスの参照はゾーン DNS 名でのみ可能になります。インスタンスは引き続き、ゾーンとグローバルの両方の検索パスを保持しますが、グローバル DNS 名は機能しなくなります。この設定を持つインスタンスを他のインスタンスが参照するときは、ゾーン DNS 名のみ使用可能であり、グローバルの DNS 名や検索パスを使用してそのインスタンスを参照することはできません。これは好ましいオプションですが、アプリケーションがこれをサポートしていることが条件です。これは、スタンドアロン プロジェクトと、2018 年 9 月 6 日以降に Compute Engine API を有効にした組織で作成されたプロジェクトのインスタンスのデフォルト設定です。プロジェクトが組織に移行されても、そのプロジェクトのデフォルトの DNS 名は変更されません。
  • VmDnsSetting=ZonalPreferred を設定すると、ゾーン DNS 検索パスが有効になりますが、グローバル DNS 名も引き続き保持されます。この設定を持つインスタンスどうしは、ゾーンとグローバルのどちらの DNS 名でも互いを参照でき、グローバル DNS 名のみが構成されたインスタンスも引き続き参照できます。
  • VmDnsSetting=GlobalOnly を設定すると、インスタンスはドメイン名と検索パスのエントリにグローバル名のみを使用します。この値を使用すると、インスタンスはプロジェクト レベルのゾーン DNS 設定から除外されます。つまり、そのインスタンスは再びグローバル DNS 名のみを使用するようになります。これは、スタンドアロン プロジェクトと、2018 年 9 月 6 日より前に Compute Engine API を有効にした組織で作成されたプロジェクトのインスタンスのデフォルト設定です。プロジェクトが組織に移行されても、そのプロジェクトのデフォルトの DNS 名は変更されません。

カスタム メタデータの設定で、プロジェクト メタデータまたはインスタンス メタデータの値を設定する方法を説明しています。

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

  • Linux インスタンス: sudo dhclient -v -r
  • Windows Server インスタンス: ipconfig /renew

既存のアプリケーションをゾーン DNS 名に移行する

既存のプロジェクトで引き続きグローバル DNS 名を使用することもできますが、ゾーン DNS 名を使用するように既存のインスタンスとアプリケーションを移行すると、ゾーン DNS システムの利点を活用できます。基本的に、次の移行プロセスを使用できます。

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

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

特定のインスタンスでゾーン DNS を無効にするには、VmDnsSetting=GlobalOnly をそのインスタンスのメタデータの中で設定します。プロジェクト全体でゾーン DNS を無効にするには、VmDnsSetting=GlobalOnly をプロジェクト メタデータの中で設定するとともに、どのインスタンスも個別に VmDnsSetting 値が設定されていないことを確認します。カスタム メタデータの設定で、プロジェクト メタデータまたはインスタンス メタデータの値を設定する方法を説明しています。

DHCP リースを強制的に、即座に更新する必要がある場合は、次のコマンドを使用します。

  • Container-Optimized OS(Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • Debian / Google App Engine Flex インスタンス: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 以上: sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Ubuntu 15.04 よりも前: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Windows: ipconfig /renew

オペレーティング システムによっては、DHCP リースが更新された後でも DNS 構成が完全には変更されないことがあります。そのような場合は、次の方法で VM インスタンスのネットワークを再起動して DNS 構成を強制的に変更してください。

  • Ubuntu: sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a
  • CentOS: sudo /etc/init.d/network restart
  • CoreOS: sudo systemctl restart systemd-networkd
  • Container-Optimized OS: sudo systemctl restart systemd-networkd

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

次のステップ

  • GCP VPC ネットワークの詳細について、VPC の概要を参照する。
  • VPC ネットワークの作成と変更の手順を、VPC の使用で確認する。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント