Overview of internal DNS

When you create Compute Engine virtual machine (VM) instances, internal DNS automatically creates a DNS name for the VM. This DNS name facilitates internal VM-to-VM communication by resolving internal IP addresses. Virtual Private Cloud networks on Google Cloud use the internal DNS service to let VMs in the same network access each other by using internal DNS names.

Google Cloud automatically creates, updates, and removes the following DNS records types as you manage your VMs:

  • DNS address records, or A records, are created for VMs in a DNS zone for .internal.
  • PTR records for VMs, used for reverse DNS lookup, are created in corresponding reverse zones.

For example, when you delete a VM, Google Cloud automatically removes the associated A and PTR records for its internal DNS name. If you then create a VM with the same name, Google Cloud creates a new record for the replacement.

Limitations

Internal DNS names have the following specifications:

  • The internal DNS name of a VM only resolves to its primary internal IP address. Internal DNS names cannot be used to connect to the external IP addresses of a VM.

  • Internal DNS names cannot be configured to resolve to secondary alias IPs.

  • Internal DNS names can only be resolved from VMs that are in the same network. These VMs can be in the same project as the network, or can be in service projects using the same Shared VPC network. To resolve DNS names of VMs in service projects, you must use the FQDNs of the VMs. You cannot use internal DNS to contact VMs that are in a different network.

Zonal and global internal DNS names

Google Cloud has two types of internal DNS names:

  • Zonal DNS: VM names must be unique within each zone, but you can reuse VM names across zones. For example, you can have several VMs named instance-1 as long as the VMs are in different zones.
  • Global DNS: VM names must be unique within each project. With global DNS, you can't reuse VM names within the project.

Google strongly recommends using zonal DNS because it offers higher reliability by isolating failures in the DNS registration to individual zones. In the event of an outage, global DNS has the following issues:

  • The VM name must be unique across the entire project. As a result, you can't create new VMs in any region experiencing control plane failures where you have or previously had project resources. Google Cloud can't verify the existing resource DNS names in the unavailable region.
  • Certain features of Compute Engine are not available, such as autoscaling of managed instance groups (MIGs). As a result, your applications that use autoscaling to gracefully handle workload increases aren't able to scale up.

The default internal DNS type is set when you enable the Compute Engine API.

  • The default internal DNS type is zonal DNS.
  • If your organization or standalone project enabled the Compute Engine API before September 6, 2018, then the default internal DNS type is set to global DNS.

The fully qualified domain names for internal DNS names are described in the following table.

Internal DNS type Fully qualified domain name (FQDN)
Zonal DNS VM_NAME.ZONE.c.PROJECT_ID.internal
Global (project wide) DNS VM_NAME.c.PROJECT_ID.internal

Replace the following:

  • VM_NAME: the name of the VM. For zonal DNS, this value must be unique within the zone but can be repeated across zones. For global DNS, the VM name must be unique across the project.
  • ZONE: the zone where your instance is located.
  • PROJECT_ID: the project to which the VM belongs.

For information about how to control which type of internal DNS name is used at the project or instance level, see configure DNS names for your project or instances.

DNS name resolution

VMs receive internal DNS resolution information as part of their DHCP leases. The method of DNS resolution depends on the operating system platform:

  • Linux: By default, the VM's DNS server (169.254.169.254:53) resolves internal DNS names.
  • Windows: By default, the subnet's default gateway resolves internal DNS names.

Reverse zones for PTR records

Google Cloud's internal DNS service automatically creates PTR records for VMs in the following reverse zones:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... through 31.172.in-addr.arpa.

Internal DNS names and Shared VPC

You can use an internal DNS name to refer to a VM's internal IP address even when that IP address is located in a Shared VPC network in a host project. With Shared VPC, the project ID portion of either the zonal or a global (project wide) internal DNS name is the ID of the service project.

Customizing internal DNS names

Some organizations or applications might require custom internal DNS names instead of the default internal DNS names created by Google Cloud.

Private zones and custom records with Cloud DNS

You can use a Cloud DNS private zone to create custom DNS entries for your VMs. You can configure PTR records that let you override the default internal DNS URL for your VM with the custom URL that you provide.

To create custom PTR records that override the automatically created internal DNS PTR names, see PTR records for RFC 1918 addresses in private zones. For information about creating PTR records for VMs, see Create a PTR record for a VM instance.

Custom hostnames

You can specify a custom hostname for a VM when you create it. Custom hostnames assigned in this way are not resolved by internal DNS. With custom hostnames, you still need to create a corresponding DNS record in the appropriate zone (for example, using Cloud DNS). For more information, see create a VM instance with a custom hostname.

Internal DNS and DHCP

Compute Engine VMs are configured to renew DHCP leases every 24 hours. For VMs that are enabled for zonal DNS, the DHCP lease expires every hour. VMs using zonal DNS have both zonal and global entries in the DHCP configuration file.

By default, most Linux distributions store DHCP information in resolv.conf. Manually editing resolv.conf results in it being reverted to the default DHCP every time the DHCP lease expires on your VM. To make static modifications in the resolv.conf file, several Linux distributions allow items to be prepended or appended to the DHCP policy.

How you modify the DHCP policy or configuration file depends on what distribution of Linux you use. For example, Red Hat Enterprise Linux and Debian use the /etc/dhcp/dhcpd.conf configuration file. On CentOS, you use the Network Manager command line utility, nmcli.

Refer to your operating system documentation for information about how to configure custom DHCP and DNS network settings. For example, for Red Hat Enterprise Linux for SAP with HA and Update Services 8.6, use the following link: Manually configuring the /etc/resolv.conf file

Example resolv.conf file

By default, most Linux distributions store DHCP information in resolv.conf. The systemd-resolved service also provides resolver services for DNS. You can configure this service by editing the /etc/systemd/resolved.conf file and other *.conf files in the /etc/systemd/resolved.conf.d/ directory. On Linux distributions that store DHCP information in resolved.conf, you can view zonal and global DNS entries in the /etc/systemd/resolved.conf file.

These files have the following restrictions:

  • The search path can handle only 6 records, and 3 of those records are provided by Compute Engine. If you add entries to the search path such that the total number of entries is greater than 6, search rules after the 6th entry are not applied by your OS. This can cause Compute Engine features to stop working, such as accessing VMs by using their instance names.

  • Manually editing resolv.conf results in it being reverted to the default DHCP every time the 24-hour DHCP lease expires on your VM. On VMs using zonal DNS, the DHCP lease expires every hour. To make static modifications in the resolv.conf file, several Linux distributions allow items to be prepended or appended to the DHCP policy.

Zonal DNS config

Sample zonal resolv.conf file:

# 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

Replace the following:

  • ZONE: the zone where your VM is located
  • PROJECT_ID: the project to which the VM belongs

Sample zonal dhcp.lease file:

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;
}

Replace the following:

  • VM_NAME: the name of the VM
  • ZONE: the zone where your VM is located
  • PROJECT_ID: the project to which the VM belongs

Global DNS config

Sample global resolv.conf file:

# 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

Replace PROJECT_ID with the project to which the VM belongs.

Sample global dhcp.lease file:

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;
}

Replace the following:

  • VM_NAME: the name of the VM
  • PROJECT_ID: the project to which the VM belongs

Example dhclient.conf file

Some operating systems, such as Debian 9, use the dhclient.conf file instead of the resolv.conf file.

Sample /etc/dhcp/dhclient.conf file:

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

In this example, mydomain.com is the new search domain and 172.16.1.1 is the IP of your DNS server.

What's next