Overview of using Zonal DNS

This document describes the benefits and recommended approach for migrating your workloads and organization from global DNS to zonal DNS.

Zonal DNS mitigates the risk of cross-regional outages and improves the overall reliability of your projects on Compute Engine.

Benefits of using zonal DNS names

Google Cloud offers two types of internal DNS names: zonal and global.

Zonal DNS

Zonal DNS names include the name of your Compute Engine instance, the zone where your instance is located, and the project that owns the instance. These names are resolved within a specific zone. As a result, my-vm.zone1.google.com is unique to zone1 and is represents a different instance than my-vm.zone2.google.com. This isolation provides a key benefit:

  • Improved availability: If one zone experiences an outage, it doesn't affect DNS resolution in other zones, leading to higher availability for your applications.

Zonal DNS is the default internal DNS resolution method for organizations that were created after September 6, 2018.

Global DNS

Global DNS names don't include the zone where the instance is located. This means each instance must have a unique DNS name across all zones within your project. This approach has a significant drawback:

  • Single point of failure: If the global DNS service experiences issues, it can impact all your instances, regardless of the zone they are located in. This can cause the following problems:
    • Unable to create new instances: You might be unable to create new instances in any region that is experiencing control plane failures.
    • Service disruptions: Critical Compute Engine services such as autoscaling or autohealing for managed instance groups (MIGs) might not function correctly.

Organizations onboarded to Google Cloud before September 6, 2018, are configured to use global DNS by default for any new projects. Google strongly recommends migrating these projects to zonal DNS to enhance reliability and prevent the service disruptions mentioned previously. Additionally, you should update the organizational policy to enforce the use of zonal DNS for all new projects created within the organization.

Recommended approach to migrate from global DNS to zonal DNS

Generally, the global DNS to zonal DNS migration process has two steps:

  1. Configure new projects to use zonal DNS by default.
  2. Migrate existing projects from using global DNS to zonal DNS by changing the internal dns metadata setting.

Some projects may not be compatible with zonal DNS. These projects require analysis and troubleshooting before migrating them to zonal DNS.

Migration limitations

The readiness assessment that Compute Engine provides relies on the past 30 days of internal DNS query history. However, other factors might affect your ability to successfully migrate to zonal DNS:

glibc Version

Migrating to zonal DNS adds a new domain to the search path. Compute instances that run a Linux or Unix OS and use glibc version 2.25 or earlier have a limit of 6 search domains. Exceeding this limit can cause issues.

  • Affected instances: This limitation applies to VMs using older Linux or Unix distributions.
  • Unaffected instances: Instances that the following operating systems are not affected:
    • Windows
    • Container-Optimized OS
    • Debian 10 or later
    • Fedora CoreOS (version 27 or later)
    • RHEL 8 or later
    • Ubuntu 18.04 or later
    • Custom images that use glibc version 2.26 or later

To check the glibc version used by your instance, do the following:

  1. Connect to your Linux VM.
  2. Run the ldd --version command.

If your instance is using glibc version 2.25 or earlier, check the search domains:

  1. Connect to your Linux VM.
  2. Run the command cat /etc/resolv.conf.

OS version

Some operating systems, such as, Windows Server 2003 and earlier, have a limit of 15 characters for compute instance names. Zonal DNS adds the zonal qualifier to the internal DNS fully qualified domain name (FQDN).

The naming limitation on Windows is a result of the NetBIOS naming convention used in earlier versions of the OS. Newer Windows versions have moved away from this restriction and allow longer instance names.

If you're working with legacy Windows systems, keep the naming limitation in mind when migrating to zonal DNS, because the longer zonal DNS names might exceed this name length limit.

Shared VPC Networks

To resolve DNS names of instances in service projects that use Shared VPC, you must use the zonal Fully Qualified Domain Name (FQDN), which includes the zone.

What's next