内部 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 またはレガシー ネットワークを使用している必要があります。同じプロジェクト内にある場合でも、内部 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. まで。

内部 DNS と Cloud DNS

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

自動的に作成された内部 DNS の PTR 名を上書きするカスタム PTR レコードの作成方法については、プライベート ゾーンでの PTR レコードの使用をご覧ください。

カスタムホスト名

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

内部 DNS 名のタイプ

Google Cloud には、内部 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 名を使用してインスタンスの内部 IP アドレスを参照できます。共有 VPC では、ゾーンまたはグローバル(プロジェクト全体)の内部 DNS 名のプロジェクト ID 部分が、サービス プロジェクトの ID です。

インスタンスの内部 DNS 名を特定する

以下の手順で、インスタンスに割り当てられている内部 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 変数は以下の設定をサポートしています。

  • 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 設定を使用するように内部 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 名のみを使用して期待どおりに動作するようになるまで、このプロセスを繰り返します。
  4. プロジェクト内のすべてのインスタンスが VmDnsSetting=ZonalOnly 設定を使用するようになるまで、このプロセスを各 Virtual Private Cloud ネットワークで繰り返します。VmDnsSetting=ZonalOnly をプロジェクト レベルのメタデータに設定すると、この設定がそのプロジェクトの中で作成されたインスタンスに自動的に適用されます。

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

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

DHCP リースを強制的に更新するには、次のいずれかのコマンドを使用します。

  • Container-optimized OS(Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • Debian や App Engine のフレキシブル環境のインスタンス: 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

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

次のステップ

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