GKE 클러스터 범위 응답 정책의 규칙을 사용하여 일치시킵니다. Cloud DNS는 DNS 이름 속성이 최대한 많은 쿼리와 일치하는 규칙에 대해 적용 가능한 모든 GKE 클러스터 범위 응답 정책을 스캔합니다. Cloud DNS는 최장 서픽스 일치를 사용하여 클러스터 범위 응답 정책을 스캔합니다.
Cloud DNS가 일치하는 응답 정책 규칙을 찾고 규칙이 로컬 데이터를 제공하는 경우 Cloud DNS는 로컬 데이터를 응답으로 반환하고 이름 변환 프로세스를 완료합니다.
Cloud DNS가 일치하는 응답 정책 규칙을 찾고 규칙의 동작이 응답 정책을 우회하는 경우 Cloud DNS는 다음 단계로 진행합니다.
Cloud DNS가 일치하는 응답 정책을 찾지 못하거나 노드에 적용 가능한 클러스터 범위 응답 정책이 없으면 Cloud DNS는 다음 단계로 진행합니다.
클러스터 범위 비공개 영역에서 레코드를 일치시킵니다. Cloud DNS는 가능한 한 많은 쿼리와 일치하는 레코드에 대해 모든 클러스터 범위의 관리형 비공개 영역을 스캔합니다. Cloud DNS는 최장 서픽스 일치를 사용하여 클러스터 범위 비공개 영역에서 레코드를 찾습니다.
쿼리의 가장 구체적인 일치 항목이 클러스터 범위 비공개 영역의 영역 이름이면 Cloud DNS는 해당 영역의 레코드 데이터를 사용하여 요청을 확인합니다.
영역에 쿼리와 정확하게 일치하는 레코드가 있는 경우 Cloud DNS는 해당 레코드의 데이터를 반환합니다.
영역에 일치하는 레코드가 없으면 Cloud DNS는 NXDOMAIN을 반환합니다.
쿼리의 가장 구체적인 일치 항목이 클러스터 범위 전달 영역의 영역 이름인 경우 Cloud DNS는 이름 변환 프로세스를 완료하기 위해 쿼리를 전달 영역의 전달 대상 중 하나로 전달합니다. Cloud DNS는 다음 응답 중 하나를 반환합니다.
전달 대상에서 수신된 응답
전달 대상이 Cloud DNS에 응답하지 않는 경우 SERVFAIL 응답
쿼리가 클러스터 범위 비공개 영역과 일치하지 않으면 Cloud DNS는 VPC 네트워크 변환 순서로 이동합니다.
VPC 네트워크 변환 순서
VPC 네트워크 대체 네임서버를 사용하여 일치시킵니다. VPC 네트워크에 아웃바운드 서버 정책이 있는 경우Google Cloud 는 해당 정책에 정의된 대체 네임서버 하나로 쿼리를 전달하여 이름 변환 프로세스를 완료합니다.
아웃바운드 서버 정책에 대체 네임서버가 두 개 이상 있으면 Cloud DNS는 내부 알고리즘을 사용하여 대체 네임서버 순위를 지정합니다. 동등한 순위부터 대체 네임서버는 성공한 응답 비율(NXDOMAIN 응답 포함)과 최단 왕복 시간(응답 지연 시간이 가장 짧음)을 기준으로 순위를 높입니다.
Cloud DNS는 다음 프로세스를 사용하여 쿼리를 대체 네임서버로 전송하고 응답을 반환합니다.
아웃바운드 서버 정책에 두 개 이상의 대체 네임서버가 있는 경우, Cloud DNS는 먼저 순위가 가장 높은 대체 네임서버로 쿼리를 보낸 후, Cloud DNS가 우선순위가 가장 높은 대체 네임서버로부터 어떤 응답도 받지 않은 경우 다음 순위로 지정된 대체 네임서버로 쿼리를 보냅니다. Cloud DNS가 다음으로 순위가 지정된 대체 네임서버에서 응답을 받지 못하면 Cloud DNS는 대체 네임서버 목록이 소진될 때까지 순위 내림차순으로 대체 네임서버를 쿼리합니다.
Cloud DNS가 대체 네임서버에서 응답을 수신하면 Cloud DNS가 해당 응답을 반환합니다. 응답에는 NXDOMAIN 응답이 포함됩니다.
Cloud DNS가 아웃바운드 서버 정책의 모든 대체 네임서버로부터 응답을 받지 않으면 Cloud DNS는 SERVFAIL 응답을 합성합니다. 대체 네임서버 연결 문제를 해결하려면 대체 네임서버 네트워크 요구사항을 참조하세요.
VPC 네트워크에 아웃바운드 서버 정책이 없는 경우 Cloud DNS는 다음 단계로 진행합니다.
VPC 네트워크 범위 응답 정책의 규칙을 사용하여 일치시킵니다. Cloud DNS는 DNS 이름 속성이 최대한 많은 쿼리와 일치하는 규칙에 대해 적용 가능한 모든 VPC 네트워크 응답 정책을 스캔합니다. Cloud DNS는 최장 서픽스 일치를 사용하여 VPC 네트워크 범위 응답 정책을 스캔합니다.
Cloud DNS가 일치하는 응답 정책 규칙을 찾고 규칙이 로컬 데이터를 제공하는 경우 Cloud DNS는 로컬 데이터를 응답으로 반환하고 이름 변환 프로세스를 완료합니다.
Cloud DNS가 일치하는 응답 정책 규칙을 찾고 규칙의 동작이 응답 정책을 우회하는 경우 Cloud DNS는 다음 단계로 진행합니다.
Cloud DNS가 일치하는 응답 정책을 찾지 못하거나 VM 또는 노드에 적용 가능한 VPC 네트워크 범위 응답 정책이 없으면 Cloud DNS는 다음 단계로 진행합니다.
VPC 네트워크 범위 관리형 비공개 영역의 레코드를 일치시킵니다.
Cloud DNS는 가능한 한 많은 쿼리와 일치하는 레코드의 VPC 네트워크에 승인된 모든 관리형 비공개 영역을 스캔합니다. Cloud DNS는 최장 서픽스 일치를 사용하여 레코드를 찾습니다.
쿼리의 가장 구체적인 일치 항목이 VPC 네트워크 범위 비공개 영역의 영역 이름이면 Cloud DNS는 해당 영역의 레코드 데이터를 사용하여 요청을 확인합니다.
영역에 쿼리와 정확하게 일치하는 레코드가 있는 경우 Cloud DNS는 해당 레코드의 데이터를 반환합니다.
영역에 일치하는 레코드가 없으면 Cloud DNS는 NXDOMAIN을 반환합니다.
쿼리의 가장 구체적인 일치 항목이 VPC 네트워크 범위 전달 영역의 영역 이름인 경우, Cloud DNS는 이름 변환 프로세스를 완료하기 위해 쿼리를 전달 영역의 전달 대상 중 하나로 전달합니다. Cloud DNS는 다음 응답 중 하나를 반환합니다.
전달 대상에서 수신된 응답
전달 대상이 Cloud DNS에 응답하지 않는 경우 SERVFAIL 응답
쿼리의 가장 구체적인 일치 항목이 VPC 네트워크 범위 피어링 영역의 이름인 경우 Cloud DNS는 현재 이름 변환 프로세스를 중지하고 피어링 영역의 대상 VPC 네트워크 관점에서 새로운 이름 변환 프로세스를 시작합니다.
쿼리가 비공개 영역, 전달 영역 또는 피어링 영역과 일치하지 않으면 Cloud DNS는 다음 단계로 진행합니다.
Compute Engine 내부 영역에서 레코드를 일치시킵니다.
Cloud DNS는 최대한 많은 쿼리와 일치하는 레코드에 대해 적용 가능한 모든 Compute Engine 내부 DNS 영역을 스캔합니다. Cloud DNS는 최장 서픽스 일치를 사용하여 레코드를 찾습니다.
쿼리의 가장 구체적인 일치 항목이 Compute Engine 내부 DNS 이름이면 Cloud DNS는 VM 네트워크 인터페이스의 내부 IP 주소 또는 역방향 조회 포인터를 응답으로 반환하고 이름 변환 프로세스를 완료합니다.
공개 DNS 쿼리를 사용하여 레코드를 일치시킵니다.. Google Cloud 는 권한 개시 정보(SOA) 레코드에 따라 Cloud DNS 공개 영역를 포함한 공개적으로 사용 가능한 영역를 쿼리합니다. Cloud DNS는 다음 응답 중 하나를 반환합니다.
권한 네임서버에서 받은 응답
레코드가 없는 경우 NXDOMAIN 응답
예시
다음 범위의 리소스와 함께 VPC 네트워크 두 개(vpc-a 및 vpc-b)와 GKE 클러스터 cluster-a가 있다고 가정합니다.
vpc-a은 다음 비공개 영역을 쿼리하도록 승인됩니다. 각 항목의 후행 점을 확인합니다.
static.example.com.
10.internal.
peer.com.은 vpc-b의 VPC 이름 변환 순서를 쿼리할 수 있는 피어링 영역입니다.
vpc-a는 아웃바운드 서버나 응답 정책과 연결되지 않습니다.
cluster-a는 example.com이라는 비공개 영역을 쿼리하도록 승인됩니다.
cluster-a도 아웃바운드 서버나 응답 정책과 연결되지 않습니다.
cluster-a의 VM은 다음을 쿼리할 수 있습니다.
cluster-a에 승인된 비공개 영역(example.com)에서 응답하는 example.com 및 하위 요소(static.example.com 포함)
vpc-a에서 10.internal
피어링 영역을 사용하는 peer.com
cluster-a에 없는 VM은 다음을 쿼리할 수 있습니다.
vpc-a에 승인된 비공개 영역(static.example.com)에서 응답하는 static.example.com 및 하위 요소. example.com 쿼리는 인터넷 응답을 반환합니다.
vpc-a에서 10.internal
피어링 영역을 사용하는 peer.com
다음 단계
Cloud DNS를 사용할 때 발생할 수 있는 일반적인 문제에 대한 해결책을 찾으려면 문제 해결 참조하기
[[["이해하기 쉬움","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\u003eCloud DNS handles queries from Compute Engine VMs by following the VPC network resolution order, with each VM needing to use the metadata server IP address (169.254.169.254) as its name server.\u003c/p\u003e\n"],["\u003cp\u003eFor GKE nodes, Cloud DNS first attempts to match queries using cluster-scoped response policies and private zones before proceeding to the VPC network resolution order.\u003c/p\u003e\n"],["\u003cp\u003eThe VPC network resolution order involves matching queries against alternative name servers, VPC network-scoped response policies, managed private zones, Compute Engine internal zones, and finally, public DNS queries.\u003c/p\u003e\n"],["\u003cp\u003eLongest-suffix matching is utilized by Cloud DNS to scan cluster-scoped and VPC network-scoped resources for records or rules that match queries.\u003c/p\u003e\n"],["\u003cp\u003eOutbound server policies help reroute queries through alternative name servers, which are ranked based on response success rates and latency, for a faster resolution.\u003c/p\u003e\n"]]],[],null,["# Name resolution order\n\nCloud DNS uses the following procedure to answer queries from\nCompute Engine virtual machine (VM) instances and\nGoogle Kubernetes Engine (GKE) nodes.\n\nFor Compute Engine VMs other than GKE nodes,\nCloud DNS follows the [VPC network resolution\norder](#vpc_steps) to process queries it receives. Each VM must be configured to\nuse the metadata server IP address (`169.254.169.254`) as its name server.\n\nFor GKE nodes:\n\n1. Cloud DNS first attempts to match a query using [cluster-scoped\n response policies and private zones](#gke_steps).\n\n2. Cloud DNS continues by following the [VPC network\n resolution order](#vpc_steps).\n\nCluster-scoped response policies and private zones\n--------------------------------------------------\n\n1. **Match using rules in GKE cluster-scoped response\n policies**. Cloud DNS scans all applicable GKE\n cluster-scoped response policies for a rule where the DNS name attribute\n matches as much of the query as possible. Cloud DNS uses\n longest-suffix matching to scan cluster-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local\n data as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable cluster-scoped response policy for the node,\n then Cloud DNS continues to the next step.\n\n2. **Match records in cluster-scoped private zones**. Cloud DNS scans\n all cluster-scoped managed private zones for a record that matches as much of\n the query as possible. Cloud DNS uses longest-suffix matching to\n find records in cluster-scoped private zones.\n\n 1. If the most specific match for the query is the zone name of a\n cluster-scoped private zone, Cloud DNS uses that zone's record\n data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns that record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n cluster-scoped forwarding zone, then Cloud DNS forwards the\n query to one of the forwarding zone's forwarding targets to complete the\n name resolution process. Cloud DNS returns one of the following\n responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the query doesn't match any cluster-scoped private zone,\n Cloud DNS continues to the [VPC network\n resolution order](#vpc_steps).\n\nVPC network resolution order\n----------------------------\n\n1. **Match using VPC network alternative name server** . If the\n VPC network has an [outbound server\n policy](/dns/docs/server-policies-overview#dns-server-policy-out),\n Google Cloud forwards the query to one of the [alternative name\n servers](/dns/docs/server-policies-overview#altns-targets) defined in that\n policy to complete the name resolution process.\n\n If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS ranks the alternative name servers using an\n internal algorithm. Beginning with equal ranks, alternative name servers\n increase in rank based on higher rates of successful responses (including\n `NXDOMAIN` responses) *and* based on the shortest round-trip time (the lowest\n response latency).\n\n Cloud DNS sends queries to alternative name servers and returns\n responses using the following process.\n - If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS first sends the query to the highest-ranked\n alternative name server, then to the next-ranked alternative name\n server if Cloud DNS does *not* receive *any* response from the\n highest-ranked alternative name server. If Cloud DNS doesn't\n receive any response from the next-ranked alternative name server,\n Cloud DNS continues to query alternative name servers by\n descending rank until it exhausts the list of alternative name servers.\n\n - If Cloud DNS receives a response from an alternative name\n server, Cloud DNS returns that response. Responses include\n `NXDOMAIN` responses.\n\n - If Cloud DNS does *not* receive a response from *all*\n alternative name servers in the outbound server policy,\n Cloud DNS synthesizes a `SERVFAIL` response. To troubleshoot\n alternative name server connectivity, see [Alternative name server\n network requirements](/dns/docs/server-policies-overview#altns-net-req).\n\n If the VPC network does *not* have an outbound server policy,\n Cloud DNS continues to the next step.\n2. **Match using rules in VPC network-scoped response\n policies**. Cloud DNS scans all applicable VPC\n network response policies for a rule where the DNS name attribute matches\n as much of the query as possible. Cloud DNS uses longest-suffix\n matching to scan VPC network-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local data\n as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable VPC network-scoped response\n policy for the VM or node, then Cloud DNS continues to the next\n step.\n\n3. **Match records in VPC network-scoped managed private zones**.\n Cloud DNS scans all managed private zones authorized for the\n VPC network for a record that matches as much of the query as\n possible. Cloud DNS uses longest-suffix matching to find records.\n\n 1. If the most specific match for the query is the zone name of a\n VPC network-scoped private zone, Cloud DNS uses that\n zone's record data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns the record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n VPC network-scoped forwarding zone, then Cloud DNS\n forwards the query to one of the forwarding zone's forwarding targets to\n complete the name resolution process. Cloud DNS returns one of\n the following responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the most specific match for the query is the name of a VPC\n network-scoped peering zone, Cloud DNS stops the current name\n resolution process and begins a new name resolution process from the\n perspective of the peering zone's target VPC network.\n\n If the query doesn't match a private zone, forwarding zone, or peering zone,\n Cloud DNS continues to the next step.\n4. **Match records in Compute Engine internal zones** .\n Cloud DNS scans all applicable [Compute Engine\n internal DNS zones](/compute/docs/internal-dns) for a record that matches as\n much of the query as possible. Cloud DNS uses longest-suffix\n matching to find records.\n\n 1. If the most specific match for the query is a Compute Engine internal DNS name, Cloud DNS returns the internal IP address of the VM's network interface or its reverse lookup pointer as its response, completing the name resolution process.\n5. **Match record using public DNS query**. Google Cloud follows the\n start of authority (SOA) record to query publicly available zones, including\n Cloud DNS public zones. Cloud DNS returns one of the\n following responses.\n\n - The response received from an authoritative name server.\n - An `NXDOMAIN` response, if the record doesn't exist.\n\nExample\n-------\n\nSuppose that you have two VPC networks, `vpc-a` and `vpc-b`, and\na GKE cluster, `cluster-a`, along with the following scoped\nresources:\n\n1. `vpc-a` is authorized to query the following private zones. Note the trailing\n dot in each entry:\n\n - `static.example.com.`\n - `10.internal.`\n2. `peer.com.` is a peering zone that can query the VPC\n name resolution order of `vpc-b`.\n\n3. `vpc-a` is not associated with any outbound server or response policies.\n\n4. `cluster-a` is authorized to query a private zone called `example.com`.\n `cluster-a` is also not associated with any outbound server or response\n policies.\n\n5. A VM in `cluster-a` can query:\n\n - `example.com` and children (including `static.example.com`), answered by the private zone called `example.com`, authorized to `cluster-a`.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n6. A VM that is *not* in `cluster-a` can query:\n\n - `static.example.com` and children, answered by the private zone called `static.example.com` authorized to `vpc-a`. Queries for `example.com` return internet responses.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n\nWhat's next\n-----------\n\n- To find solutions for common issues that you might encounter when using Cloud DNS, see [Troubleshooting](/dns/docs/troubleshooting).\n- To get an overview of Cloud DNS, see [Cloud DNS overview](/dns/docs/overview).\n- To learn how to configure response policies, see [Manage response policies\n and rules](/dns/docs/zones/manage-response-policies)."]]
