Cloud DNS では、次の手順で Compute Engine 仮想マシン（VM）インスタンスと Google Kubernetes Engine（GKE）ノードからのクエリに応答します。
GKE ノード以外の Compute Engine VM の場合、Cloud DNS は VPC ネットワークの解決順序に従って、受信したクエリを処理します。各 VM は、メタデータ サーバーの IP アドレス（169.254.169.254）をネームサーバーとして使用するように構成する必要があります。
GKE クラスタ スコープのレスポンス ポリシーのルールを使用して照合します。Cloud DNS は該当するすべての GKE クラスタ スコープのレスポンス ポリシーをスキャンし、DNS 名属性ができるだけ多くのクエリと一致するルールを検索します。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 から次のいずれかのレスポンスが返されます。
転送先から受信したレスポンス。
SERVFAIL レスポンス（転送先が Cloud DNS に応答しない場合）。
クエリがクラスタ スコープ限定公開ゾーンと一致しない場合、Cloud DNS は VPC ネットワーク解決順序に進みます。
アウトバウンド サーバー ポリシーに複数の代替ネームサーバーが存在する場合、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 は該当するすべての VPC ネットワーク レスポンス ポリシーをスキャンして、DNS 名属性ができるだけ多くのクエリと一致するルールを検索します。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 から次のいずれかのレスポンスが返されます。
転送先から受信したレスポンス。
SERVFAIL レスポンス（転送先が Cloud DNS に応答しない場合）。
クエリの最も詳細な一致がネットワーク スコープのピアリング ゾーンの名前である場合、Cloud DNS は現在の名前解決プロセスを中止し、ピアリング ゾーンのターゲット VPC ネットワークの観点から新しい名前解決プロセスを開始します。
クエリが限定公開ゾーン、転送ゾーン、ピアリング ゾーンと一致しない場合、Cloud DNS は次のステップに進みます。
Compute Engine 内部ゾーンのレコードを照合します。Cloud DNS は、該当するすべての Compute Engine の内部 DNS ゾーンをスキャンし、できるだけ多くのクエリと一致するレコードを検索します。Cloud DNS は、最長サフィックス マッチングを使用してレコードを検索します。
クエリの最も詳細な一致が Compute Engine の内部 DNS 名の場合、Cloud DNS は VM のネットワーク インターフェースの内部 IP アドレスまたはその逆引き参照ポインタをレスポンスとして返し、名前解決プロセスを完了します。
一般公開 DNS クエリを使用したレコードを照合する: Google Cloud は Start of Authority（SOA）レコードに従い、Cloud DNS 一般公開ゾーンを含む一般に利用可能なゾーンをクエリします。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)."]]