When you create Compute Engine instances, internal DNS automatically createsa DNS name for the instance. This DNS name facilitates internalinstance-to-instance communication by resolving internal IP addresses.Virtual Private Cloud networks on Google Cloud use the internal DNS serviceto let compute instances in the same network access each other by usinginternal DNS names.

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

• DNS address records, orA records, are created for instancesin a DNS zone for.internal.
• PTR records for instances, used for reverse DNS lookup, are created incorrespondingreverse zones.

For example, when you delete an instance, Google Cloud automaticallyremoves the associated A and PTR records for its internal DNS name. If youthen create an instance with the same name, Google Cloud creates newrecords for the replacement.

Limitations

• Compute Engine creates internal DNS name A and PTR records only forthe primary internal IPv4 address of thenic0 network interface of aninstance. Consequently, the stack type of thenic0 network interface must beeither IPv4-only or dual-stack. Internal DNS doesn't support IPv6-only networkinterfaces.

• Compute Enginedoesn't create internal DNS records for thefollowing:

  • The primary internal IPv4 address of a network interface different fromnic0.
  • An external IPv4 address of any network interface.
  • An internal IPv4 address of analias IP range ofany network interface.
  • An internal or external IPv6 address range of any network interface.

• Resolving internal DNS names requires that the client VM and VM associatedwith the internal DNS record are both:

  • In the same VPC network.
  • In the same project (except for certain Shared VPC scenarios).

  For more information about Shared VPC scenarios, seeInternal DNSnames and Shared VPC.

Zonal and global internal DNS names

Google Cloud has two types of internal DNS names:

• Zonal DNS: instance names must be unique within each zone, but you canreuse instance names across zones. For example, you can have severalinstances namedinstance-1 as long as the instances are in different zones.
• Global DNS: instance names must be unique within each project. Withglobal DNS, you can't reuse instance names within the project.

Googlestrongly recommends using zonal DNS because it offershigher reliability by isolating failures in the DNS registration toindividual zones. In the event of an outage, global DNS has the followingissues:

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

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

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

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

DNS name resolution

Instances 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 instance's DNS server resolves internal DNS names.
• Windows: By default, the subnet's default gateway resolves internal DNSnames.

Google Cloud's internal DNS service automatically creates PTR records forinstances in the followingreverse zones:

• 10.in-addr.arpa.
• 168.192.in-addr.arpa.
• 16.172.in-addr.arpa.,17.172.in-addr.arpa., ... through31.172.in-addr.arpa.

Internal DNS names and Shared VPC

The client VM and the VM associated with the internal DNS record can belocated in separate projects, but they must use the same Shared VPCnetwork. For example, the client can be located in one service project, and theVM associated with the internal DNS record can be located in a different serviceproject or the host project.

Clients must issue fully qualified domain name (FQDN) queries for internal DNSrecords instead of relying on partial queries and DNS search domains. DNS searchdomains are different in each project for reasons such as the following:

• The domain name portion of each internal DNS A record contains the project IDof the project that contains the VM. For a VM in a service project whosenic0 network interface uses a Shared VPC network, the project of theVM is different from the project containing the network.

• Whether zonal or global (project wide) internal DNS names are used dependson the configuration of the project that contains the VM.

For more information about Shared VPC, see:

• Shared VPC overview
• Provision Shared VPC

Customizing internal DNS names

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

Private zones and custom records with Cloud DNS

You can use aCloud DNS private zoneto create custom DNS entries for your instances. You can configure PTRrecords that let you override the default internal DNS name for your instance with thecustom name that you provide.

To create custom PTR records that override theautomatically created internal DNS PTR names, seePTR records for RFC 1918 addresses in private zones.For information about creating PTR records for instances, seeCreate a PTR record for an instance.

You can specify a custom hostname for an instance when you create it. Customhostnames assigned in this way are not resolved by internal DNS. With customhostnames, you still need to create a corresponding DNS record in theappropriate zone (for example, using Cloud DNS).For more information, seecreate an instance with a custom hostname.

Internal DNS and DHCP

Compute Engine instances are configured to renewDHCP leases every 24 hours. For instances that are enabled for zonal DNS, theDHCP lease expires every hour. Instances usingzonal DNS have both zonal and globalentries in the DHCP configuration file.

By default, most Linux distributions store DHCP information inresolv.conf.Manually editingresolv.conf results in it being reverted to the defaultDHCP every time the DHCP lease expires on your instance. To makestatic modifications in theresolv.conf file, several Linux distributionsallow items to be prepended or appended to theDHCP policy.

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

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

Exampleresolv.conf file

By default, most Linux distributions store DHCP information inresolv.conf.Thesystemd-resolved service also provides resolver services for DNS.You can configure this service by editing the/etc/systemd/resolved.conf fileand other*.conf files in the/etc/systemd/resolved.conf.d/ directory. OnLinux distributions that store DHCP information inresolved.conf, you can viewzonal and global DNS entries in the/etc/systemd/resolved.conffile.

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

• Manually editingresolv.conf results in it being reverted to the defaultDHCP every time the 24-hour DHCP lease expires on your instance. On instancesusing zonal DNS, the DHCP lease expires every hour. To makestatic modifications in theresolv.conf file, several Linux distributionsallow items to be prepended or appended to theDHCP policy.

# Local domain name. Computed from your project name.domainZONE.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.searchZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.# Address of the DNS server to resolve project specific, and global domain names.nameserverMDS_IP_ADDRESS

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 instances will have this value set to infinite.  option dhcp-lease-time 3600;  option dhcp-message-type 5;  option domain-name-serversMDS_IP_ADDRESS;  option dhcp-server-identifierMDS_IP_ADDRESS;  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-serversMDS_IP_ADDRESS;  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;}

# 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.nameserverMDS_IP_ADDRESS

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 instances will have this value set to infinite.  option dhcp-lease-time 86400;  option dhcp-message-type 5;  option domain-name-serversMDS_IP_ADDRESS;  option dhcp-server-identifierMDS_IP_ADDRESS;  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-serversMDS_IP_ADDRESS;  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;}

Exampledhclient.conf file

Some operating systems, such as Debian 9, use thedhclient.conf file insteadof theresolv.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 and172.16.1.1 isthe IP of your DNS server.

What's next

• For information about Google Cloud VPC networks, see theVPC overview.
• For information about creating and modifying VPC networks, seeUsing VPC.
• Migrate your organization and projects touse zonal DNS instead of global DNS.