[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-26。"],[[["\u003cp\u003eZonal DNS is recommended over global DNS because it enhances reliability by isolating DNS resolution to specific zones, mitigating the risk of cross-regional outages.\u003c/p\u003e\n"],["\u003cp\u003eGlobal DNS poses a single point of failure, as issues can impact all instances across zones, potentially disrupting services like autoscaling and new instance creation.\u003c/p\u003e\n"],["\u003cp\u003eOrganizations created before September 6, 2018, typically use global DNS by default and should migrate to zonal DNS for improved reliability and to avoid potential disruptions.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to zonal DNS involves configuring new projects to use zonal DNS by default and changing the internal DNS metadata setting for existing projects.\u003c/p\u003e\n"],["\u003cp\u003eCompatibility issues may arise during migration for instances using older Linux or Unix distributions with \u003ccode\u003eglibc\u003c/code\u003e version 2.25 or earlier, or with legacy systems like Windows Server 2003 that have character limits for instance names.\u003c/p\u003e\n"]]],[],null,["# Overview of using Zonal DNS\n\nLinux Windows\n\n*** ** * ** ***\n\nThis document describes the benefits and recommended approach for migrating\nyour workloads and organization from global DNS to zonal DNS.\n\nZonal DNS mitigates the risk of cross-regional outages and improves\nthe overall reliability of your projects on Compute Engine.\n\nBenefits of using zonal DNS names\n---------------------------------\n\nGoogle Cloud offers two types of internal DNS names: zonal and global.\n\nZonal DNS\n\n: Zonal DNS names include the name of your Compute Engine instance, the\n zone where your instance is located, and the project that owns the instance.\n These names are resolved within a specific zone. As a result,\n `my-vm.zone1.google.com` is unique to `zone1` and is represents a different\n instance than `my-vm.zone2.google.com`. This isolation provides a key benefit:\n\n - **Improved availability**: If one zone experiences an outage, it doesn't affect DNS resolution in other zones, leading to higher availability for your applications.\n\n Zonal DNS is the default internal DNS resolution method for organizations\n that were created after September 6, 2018.\n\nGlobal DNS\n\n: Global DNS names don't include the zone where the instance is located. This\n means each instance must have a unique DNS name across *all* zones within your\n project. This approach has a significant drawback:\n\n - **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:\n - **Unable to create new instances**: You might be unable to create new instances in any region that is experiencing control plane failures.\n - **Service disruptions**: Critical Compute Engine services such as autoscaling or autohealing for managed instance groups (MIGs) might not function correctly.\n\nOrganizations onboarded to Google Cloud before September 6, 2018, are configured\nto use global DNS by default for any new projects. Google strongly recommends\nmigrating these projects to zonal DNS to enhance reliability and prevent the\nservice disruptions mentioned previously. Additionally, you should update the\norganizational policy to\n[enforce the use of zonal DNS](/compute/docs/networking/use-zonal-dns#enforce_dns_by_policy)\nfor all new projects created within the organization.\n| **Note:** Zonal DNS is the default internal DNS system for Google Cloud. Zonal DNS is offered at no charge, and it is not a part of Cloud DNS.\n\nRecommended approach to migrate from global DNS to zonal DNS\n------------------------------------------------------------\n\nGenerally, the global DNS to zonal DNS migration process has two steps:\n\n1. Configure new projects to use zonal DNS by default.\n2. Migrate existing projects from using global DNS to zonal DNS by changing the internal dns metadata setting.\n\nSome projects may not be compatible with zonal DNS. These projects require\nanalysis and troubleshooting before migrating them to zonal DNS.\n| **Caution:** Enabling zonal DNS names across your\n| entire project applies zonal DNS settings to VMs in the following\n| services:\n|\n| - [App Engine flexible environment](/appengine/docs/flexible), [Google Kubernetes Engine](/kubernetes-engine/docs), and [Containers running on Compute Engine](/compute/docs/containers)\n| - [Cloud SQL](/sql/docs), [Cloud Run functions](/functions/docs), and [Batch](/batch/docs/get-started)\n| - [Dataproc](/dataproc/docs) and [Dataflow](/dataflow/docs)\n\nMigration limitations\n---------------------\n\nThe readiness assessment that Compute Engine provides relies on the past\n30 days of internal DNS query history. However, other factors might affect your\nability to successfully migrate to zonal DNS:\n\n**glibc Version**\n\nMigrating to zonal DNS adds a new domain to the search path. Compute\ninstances that run a Linux or Unix OS and use `glibc` version 2.25 or\nearlier have a limit of 6 search domains. Exceeding this limit can cause\nissues.\n\n- Affected instances: This limitation applies to VMs using older Linux or Unix distributions.\n- Unaffected instances: Instances that the following operating systems are not affected:\n - Windows\n - Container-Optimized OS\n - Debian 10 or later\n - Fedora CoreOS (version 27 or later)\n - RHEL 8 or later\n - Ubuntu 18.04 or later\n - Custom images that use `glibc` version 2.26 or later\n\nTo check the glibc version used by your instance, do the following:\n\n1. Connect to your Linux VM.\n2. Run the `ldd --version` command.\n\nIf your instance is using `glibc` version 2.25 or earlier, check the search\ndomains:\n\n1. Connect to your Linux VM.\n2. Run the command `cat /etc/resolv.conf`.\n\n**OS version**\n\nSome operating systems, such as, Windows Server 2003 and earlier, have a limit\nof 15 characters for compute instance names. Zonal DNS adds the zonal\nqualifier to the internal DNS fully qualified domain name (FQDN).\n\nThe naming limitation on Windows is a result of the NetBIOS naming convention\nused in earlier versions of the OS. Newer Windows versions have moved away from\nthis restriction and allow longer instance names.\n\nIf you're working with legacy Windows systems, keep the naming limitation in\nmind when migrating to zonal DNS, because the longer zonal DNS names might\nexceed this name length limit.\n\n**Shared VPC Networks**\n\nTo resolve DNS names of instances in service projects that use\nShared VPC, you must use the zonal Fully Qualified Domain Name (FQDN),\nwhich includes the zone.\n\nWhat's next\n-----------\n\n- Review the [Google Cloud resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy#resource-hierarchy-detail) for information about the relationship between organizations, folders, and projects.\n- Learn more about [internal DNS for Compute Engine](/compute/docs/internal-dns)."]]
