이 문서에서는 워크로드와 조직을 전역 DNS에서 영역 DNS로 마이그레이션할 때의 이점과 권장 접근 방식을 설명합니다.
영역 DNS는 리전 간 서비스 중단의 위험을 완화하고 Compute Engine에서 프로젝트의 전반적인 신뢰성을 개선합니다.
영역 DNS 이름 사용 시 이점
Google Cloud 에서는 영역 및 전역 등 두 가지 유형의 내부 DNS 이름을 제공합니다.
영역 DNS
영역 DNS 이름에는 Compute Engine 인스턴스의 이름, 사용자의 인스턴스가 있는 영역, 인스턴스를 소유하는 프로젝트가 포함됩니다.
이러한 이름은 특정 영역 내에서 확인됩니다. 따라서 my-vm.zone1.google.com은 zone1에 고유하며 my-vm.zone2.google.com과는 다른 인스턴스를 나타냅니다. 이러한 격리는 다음과 같은 주요 이점을 제공합니다.
가용성 향상: 한 영역에서 서비스가 중단되더라도 다른 영역의 DNS 변환은 영향을 받지 않으므로 애플리케이션 가용성이 높아집니다.
영역 DNS는 2018년 9월 6일 이후에 생성된 조직의 기본 내부 DNS 변환 방법입니다.
전역 DNS
전역 DNS 이름에는 인스턴스가 위치한 영역이 포함되지 않습니다. 즉, 각 인스턴스는 프로젝트 내 모든 영역에서 고유한 DNS 이름을 가져야 합니다. 이 접근 방식에는 다음과 같은 큰 단점이 있습니다.
단일 장애점: 전역 DNS 서비스에 문제가 발생하면 인스턴스가 있는 영역에 관계없이 모든 인스턴스에 영향을 미칠 수 있습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다.
새 인스턴스를 만들 수 없음: 컨트롤 플레인 오류가 발생하는 리전에는 새 인스턴스를 만들 수 없습니다.
서비스 중단: 관리형 인스턴스 그룹(MIG)의 자동 확장 또는 자동 복구와 같은 중요한 Compute Engine 서비스가 올바르게 작동하지 않을 수 있습니다.
2018년 9월 6일 전에 Google Cloud 에 온보딩된 조직은 새 프로젝트에 기본적으로 전역 DNS를 사용하도록 구성됩니다. 안정성을 높이고 앞서 언급한 서비스 중단을 방지하려면 이러한 프로젝트를 영역 DNS로 이전하는 것이 좋습니다. 또한 조직 내에서 생성된 모든 새 프로젝트에 영역 DNS 사용을 적용하도록 조직 정책을 업데이트해야 합니다.
전역 DNS에서 영역 DNS로 마이그레이션하는 권장 방식
일반적으로 전역 DNS에서 영역 DNS로 마이그레이션하는 프로세스는 두 단계로 구성됩니다.
기본적으로 새 프로젝트에서 영역 DNS를 사용하도록 구성합니다.
내부 DNS 메타데이터 설정을 변경하여 기존 프로젝트가 전역 DNS 대신 영역 DNS를 사용하도록 마이그레이션합니다.
일부 프로젝트는 영역 DNS와 호환되지 않을 수 있습니다. 이러한 프로젝트는 영역 DNS로 마이그레이션하기 전에 분석 및 문제 해결이 필요합니다.
마이그레이션 제한사항
Compute Engine에서 제공하는 준비 상태 평가는 지난 30일간의 내부 DNS 쿼리 기록을 기반으로 합니다. 하지만 영역 DNS로의 원활한 이전에는 다른 요소도 영향을 미칠 수 있습니다.
glibc 버전
영역 DNS로 이전하면 검색 경로에 새 도메인이 추가됩니다. Linux 또는 Unix OS를 실행하고 glibc 버전 2.25 이하를 사용하는 Compute 인스턴스의 검색 도메인 한도는 6개입니다. 이 한도를 초과하면 문제가 발생할 수 있습니다.
영향을 받는 인스턴스: 이 제한은 예전 Linux 또는 Unix 배포를 사용하는 VM에 적용됩니다.
영향을 받지 않는 인스턴스: 다음 운영체제를 사용하는 인스턴스는 영향을 받지 않습니다.
Windows
Container-Optimized OS
Debian 10 이상
Fedora CoreOS(버전 27 이상)
RHEL 8 이상
Ubuntu 18.04 이상
glibc 버전 2.26 이상을 사용하는 커스텀 이미지
인스턴스에서 사용하는 glibc 버전을 확인하려면 다음을 수행합니다.
Linux VM에 연결합니다.
ldd --version 명령어를 실행합니다.
인스턴스에서 glibc 버전 2.25 이하를 사용하는 경우 검색 도메인을 확인합니다.
Linux VM에 연결합니다.
cat /etc/resolv.conf 명령어를 실행합니다.
OS 버전
Windows Server 2003 이하와 같은 일부 운영체제에서는 컴퓨팅 인스턴스 이름이 15자(영문 기준)로 제한됩니다. 영역 DNS는 내부 DNS 정규화된 도메인 이름(FQDN)에 영역 한정자를 추가합니다.
Windows의 이름 지정 제한은 이전 버전의 OS에서 사용된 NetBIOS 이름 지정 규칙의 결과입니다. 최신 Windows 버전에서는 이 제한사항이 사라졌으며 더 긴 인스턴스 이름을 허용합니다.
기존 Windows 시스템을 사용하는 경우 영역 DNS로 마이그레이션할 때 이름 지정 제한사항에 유의하세요. 영역 DNS 이름이 길어 이 이름 길이 한도를 초과할 수 있기 때문입니다.
공유 VPC 네트워크
공유 VPC를 사용하는 서비스 프로젝트에서 인스턴스의 DNS 이름을 확인하려면 영역이 포함된 영역별 정규화된 도메인 이름(FQDN)을 사용해야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\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)."]]
