Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Cloud DNS menggunakan prosedur berikut untuk menjawab kueri dari instance virtual machine (VM) Compute Engine dan node Google Kubernetes Engine (GKE).
Untuk VM Compute Engine selain node GKE,
Cloud DNS mengikuti urutan resolusi jaringan VPC untuk memproses kueri yang diterimanya. Setiap VM harus dikonfigurasi untuk
menggunakan alamat IP server metadata (169.254.169.254) sebagai server namanya.
Kebijakan respons cakupan cluster dan zona pribadi
Mencocokkan menggunakan aturan dalam kebijakan respons cakupan cluster GKE. Cloud DNS memindai semua kebijakan respons cakupan cluster GKE yang berlaku untuk aturan dengan atribut nama DNS yang cocok dengan kueri sebanyak mungkin. Cloud DNS menggunakan pencocokan akhiran terpanjang untuk memindai kebijakan respons cakupan cluster.
Jika Cloud DNS menemukan aturan kebijakan respons yang cocok dan
aturan tersebut menayangkan data lokal, Cloud DNS akan menampilkan data lokal sebagai responsnya, sehingga menyelesaikan proses resolusi nama.
Jika Cloud DNS menemukan aturan kebijakan respons yang cocok dan perilaku aturan mengabaikan kebijakan respons, Cloud DNS akan melanjutkan ke langkah berikutnya.
Jika Cloud DNS gagal menemukan kebijakan respons yang cocok atau jika tidak ada kebijakan respons cakupan cluster yang berlaku untuk node, Cloud DNS akan melanjutkan ke langkah berikutnya.
Mencocokkan data di zona pribadi cakupan cluster. Cloud DNS memindai
semua zona pribadi terkelola cakupan cluster untuk menemukan data yang cocok dengan kueri sebanyak mungkin. Cloud DNS menggunakan pencocokan akhiran terpanjang untuk menemukan data di zona pribadi cakupan cluster.
Jika kecocokan paling spesifik untuk kueri adalah nama zona dari zona pribadi cakupan cluster, Cloud DNS akan menggunakan data catatan zona tersebut untuk me-resolve permintaan.
Jika zona berisi data yang sama persis dengan kueri, Cloud DNS akan menampilkan data data tersebut.
Jika zona tidak berisi data yang cocok, Cloud DNS akan menampilkan
NXDOMAIN.
Jika kecocokan paling spesifik untuk kueri adalah nama zona dari zona penerusan cakupan cluster, Cloud DNS akan meneruskan kueri ke salah satu target penerusan zona penerusan untuk menyelesaikan proses resolusi nama. Cloud DNS menampilkan salah satu respons berikut.
Respons yang diterima dari target penerusan.
Respons SERVFAIL, jika target penerusan tidak merespons Cloud DNS.
Jika kueri tidak cocok dengan zona pribadi cakupan cluster,
Cloud DNS akan melanjutkan ke urutan resolusi jaringan
VPC.
Urutan resolusi jaringan VPC
Mencocokkan menggunakan server nama alternatif jaringan VPC. Jika jaringan VPC memiliki kebijakan server keluar,Google Cloud akan meneruskan kueri ke salah satu server nama alternatif yang ditentukan dalam kebijakan tersebut untuk menyelesaikan proses resolusi nama.
Jika ada dua server nama alternatif atau lebih dalam kebijakan server
keluar, Cloud DNS akan memberi peringkat server nama alternatif menggunakan
algoritma internal. Dimulai dengan peringkat yang sama, server nama alternatif
akan meningkatkan peringkat berdasarkan rasio respons yang berhasil yang lebih tinggi (termasuk
respons NXDOMAIN) dan berdasarkan waktu bolak-balik terpendek (latensi respons
terendah).
Cloud DNS mengirim kueri ke server nama alternatif dan menampilkan
respons menggunakan proses berikut.
Jika ada dua server nama alternatif atau lebih dalam kebijakan server
keluar, Cloud DNS akan mengirim kueri terlebih dahulu ke server nama alternatif
dengan peringkat tertinggi, lalu ke server nama alternatif
dengan peringkat berikutnya jika Cloud DNS tidak menerima respons dari
server nama alternatif dengan peringkat tertinggi. Jika Cloud DNS tidak menerima respons apa pun dari server nama alternatif dengan peringkat berikutnya, Cloud DNS akan terus mengkueri server nama alternatif berdasarkan peringkat menurun hingga daftar server nama alternatif habis.
Jika Cloud DNS menerima respons dari server nama alternatif, Cloud DNS akan menampilkan respons tersebut. Respons mencakup
respons NXDOMAIN.
Jika Cloud DNS tidak menerima respons dari semua server nama alternatif dalam kebijakan server keluar, Cloud DNS akan menyintesis respons SERVFAIL. Untuk memecahkan masalah
konektivitas server nama alternatif, lihat Persyaratan jaringan server nama
alternatif.
Jika jaringan VPC tidak memiliki kebijakan server keluar,
Cloud DNS akan melanjutkan ke langkah berikutnya.
Mencocokkan menggunakan aturan dalam kebijakan respons cakupan jaringan VPC. Cloud DNS memindai semua kebijakan respons jaringan VPC yang berlaku untuk aturan dengan atribut nama DNS yang cocok dengan kueri sebanyak mungkin. Cloud DNS menggunakan pencocokan akhiran terpanjang untuk memindai kebijakan respons cakupan jaringan VPC.
Jika Cloud DNS menemukan aturan kebijakan respons yang cocok dan aturan tersebut menayangkan data lokal, Cloud DNS akan menampilkan data lokal sebagai responsnya, sehingga menyelesaikan proses resolusi nama.
Jika Cloud DNS menemukan aturan kebijakan respons yang cocok dan perilaku aturan mengabaikan kebijakan respons, Cloud DNS akan melanjutkan ke langkah berikutnya.
Jika Cloud DNS gagal menemukan kebijakan respons yang cocok atau jika tidak ada kebijakan respons cakupan jaringan VPC yang berlaku untuk VM atau node, Cloud DNS akan melanjutkan ke langkah berikutnya.
Mencocokkan data di zona pribadi terkelola cakupan jaringan VPC.
Cloud DNS memindai semua zona pribadi terkelola yang diotorisasi untuk jaringan VPC guna menemukan data yang cocok dengan kueri sebanyak mungkin. Cloud DNS menggunakan pencocokan akhiran terpanjang untuk menemukan data.
Jika kecocokan paling spesifik untuk kueri adalah nama zona dari zona pribadi cakupan jaringan VPC, Cloud DNS akan menggunakan data data zona tersebut untuk me-resolve permintaan.
Jika zona berisi data yang sama persis dengan kueri, Cloud DNS akan menampilkan data data tersebut.
Jika zona tidak berisi data yang cocok, Cloud DNS akan menampilkan
NXDOMAIN.
Jika kecocokan paling spesifik untuk kueri adalah nama zona dari zona penerusan cakupan jaringan VPC, Cloud DNS akan meneruskan kueri ke salah satu target penerusan zona penerusan untuk menyelesaikan proses resolusi nama. Cloud DNS menampilkan salah satu respons berikut.
Respons yang diterima dari target penerusan.
Respons SERVFAIL, jika target penerusan tidak merespons Cloud DNS.
Jika kecocokan paling spesifik untuk kueri adalah nama zona peering cakupan jaringan VPC, Cloud DNS akan menghentikan proses resolusi nama saat ini dan memulai proses resolusi nama baru dari perspektif jaringan VPC target zona peering.
Jika kueri tidak cocok dengan zona pribadi, zona penerusan, atau zona peering,
Cloud DNS akan melanjutkan ke langkah berikutnya.
Mencocokkan data di zona internal Compute Engine.
Cloud DNS memindai semua zona DNS internal Compute Engine yang berlaku untuk menemukan data yang cocok dengan kueri sebanyak mungkin. Cloud DNS menggunakan pencocokan akhiran
terpanjang untuk menemukan data.
Jika kecocokan paling spesifik untuk kueri adalah nama DNS internal Compute Engine, Cloud DNS akan menampilkan alamat IP internal antarmuka jaringan VM atau pointer pencarian baliknya sebagai responsnya, sehingga menyelesaikan proses resolusi nama.
Mencocokkan data menggunakan kueri DNS publik. Google Cloud mengikuti
data awal otoritas (SOA) untuk membuat kueri zona yang tersedia secara publik, termasuk
zona publik Cloud DNS. Cloud DNS menampilkan salah satu
respons berikut.
Respons yang diterima dari server nama otoritatif.
Respons NXDOMAIN, jika kumpulan data tidak ada.
Contoh
Misalnya, Anda memiliki dua jaringan VPC, vpc-a dan vpc-b, serta
cluster GKE, cluster-a, beserta resource cakupan
berikut:
vpc-a diberi otorisasi untuk membuat kueri zona pribadi berikut. Perhatikan titik
akhir di setiap entri:
static.example.com.
10.internal.
peer.com. adalah zona peering yang dapat mengkueri urutan resolusi nama VPC
vpc-b.
vpc-a tidak dikaitkan dengan server keluar atau kebijakan respons apa pun.
cluster-a diberi otorisasi untuk membuat kueri zona pribadi yang disebut example.com.
cluster-a juga tidak terkait dengan server keluar atau kebijakan respons.
VM di cluster-a dapat membuat kueri:
example.com dan turunan (termasuk static.example.com),
dijawab oleh zona pribadi yang disebut example.com, yang diberi otorisasi untuk
cluster-a.
10.internal di vpc-a.
peer.com dengan menggunakan zona peering.
VM yang tidak ada di cluster-a dapat membuat kueri:
static.example.com dan turunan, dijawab oleh zona pribadi yang disebut
static.example.com yang diberi otorisasi ke vpc-a. Kueri untuk example.com
menampilkan respons internet.
10.internal di vpc-a.
peer.com dengan menggunakan zona peering.
Langkah berikutnya
Untuk menemukan solusi atas masalah umum yang mungkin Anda alami saat menggunakan
Cloud DNS, lihat Pemecahan masalah.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-11 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)."]]
