Ringkasan zona DNS

Cloud DNS mendukung berbagai jenis zona publik dan pribadi. Halaman ini memberikan detail tentang berbagai jenis zona dan kapan Anda dapat menggunakan salah satunya.

Zona penerusan

Zona penerusan Cloud DNS dapat Anda gunakan untuk mengonfigurasi server nama target untuk zona pribadi tertentu. Menggunakan zona penerusan adalah salah satu cara untuk mengimplementasikan penerusan DNS keluar dari jaringan VPC Anda.

Zona penerusan Cloud DNS adalah zona pribadi Cloud DNS jenis khusus. Alih-alih membuat kumpulan data dalam zona, Anda dapat menentukan kumpulan target penerusan. Setiap target penerusan adalah alamat IP server DNS, yang terletak di jaringan VPC Anda, atau di jaringan lokal yang terhubung ke jaringan VPC Anda oleh Cloud VPN atau Cloud Interconnect.

Target penerusan dan metode pemilihan rute

Cloud DNS mendukung tiga jenis target dan menawarkan metode perutean standar atau pribadi untuk konektivitas.

Target penerusan	Deskripsi	Dukungan perutean standar	Perutean pribadi mendukung	Sumber permintaan
Jenis 1	Alamat IP internal dari VM Google Cloud atau Load Balancer Jaringan passthrough internal di jaringan VPC yang sama yang diberi otorisasi untuk menggunakan zona penerusan.	Hanya alamat IP RFC 1918—traffic yang selalu dirutekan melalui jaringan VPC yang diotorisasi.	Semua alamat IP internal, seperti alamat pribadi RFC 1918, alamat IP pribadi non-RFC 1918, atau alamat IP eksternal yang digunakan ulang secara pribadi, kecuali untuk alamat IP target penerusan terlarang —traffic selalu diarahkan melalui jaringan VPC yang diizinkan.	`35.199.192.0/19`
Tipe 2	Alamat IP dari sistem lokal, yang terhubung ke jaringan VPC yang diberi otorisasi untuk mengkueri zona penerusan, menggunakan Cloud VPN atau Cloud Interconnect.	Hanya alamat IP RFC 1918—traffic yang selalu dirutekan melalui jaringan VPC yang diotorisasi.	Semua alamat IP internal, seperti alamat pribadi RFC 1918, alamat IP pribadi non-RFC 1918, atau alamat IP eksternal yang digunakan ulang secara pribadi, kecuali untuk alamat IP target penerusan terlarang — traffic selalu diarahkan melalui jaringan VPC yang diizinkan.	`35.199.192.0/19`
Jenis 3	Alamat IP eksternal dari server nama DNS yang dapat diakses oleh internet atau alamat IP eksternal resource Google Cloud; misalnya, alamat IP eksternal VM di jaringan VPC lain.	Hanya alamat IP eksternal yang dapat dirutekan ke internet, yaitu traffic yang selalu dirutekan ke internet atau ke alamat IP eksternal resource Google Cloud.	Perutean pribadi tidak didukung—pastikan perutean pribadi tidak dipilih.	Rentang sumber Google Public DNS

Anda dapat memilih salah satu dari dua metode pemilihan rute berikut saat menambahkan target penerusan ke zona penerusan:

Pemilihan rute standar: Merutekan traffic melalui jaringan VPC yang diizinkan atau melalui internet berdasarkan apakah target penerusannya adalah alamat IP RFC 1918. Jika target penerusan adalah alamat IP RFC 1918, Cloud DNS akan mengklasifikasikan target sebagai target Jenis 1 atau Jenis 2, dan merutekan permintaan melalui jaringan VPC yang diizinkan. Jika targetnya bukan alamat IP RFC 1918, Cloud DNS akan mengklasifikasikan target sebagai Jenis 3, dan mengharapkan target tersebut dapat diakses oleh internet.
Perutean pribadi: Selalu merutekan traffic melalui jaringan VPC yang diizinkan, apa pun alamat IP targetnya (RFC 1918 atau tidak). Akibatnya, hanya target Jenis 1 dan Jenis 2 yang didukung.

Untuk mengakses target penerusan Jenis 1 atau Jenis 2, Cloud DNS menggunakan rute di jaringan VPC yang diizinkan tempat klien DNS berada. Rute ini menentukan jalur aman ke target penerusan:

Untuk mengirim traffic ke target Jenis 1, Cloud DNS menggunakan rute subnet yang dibuat secara otomatis. Untuk membalas, target Jenis 1 menggunakan rute pengembalian khusus untuk respons Cloud DNS.
Untuk mengirim traffic ke target Jenis 2, Cloud DNS dapat menggunakan rute dinamis kustom atau rute statis kustom, kecuali untuk rute statis kustom dengan tag jaringan. Sebagai balasan, target penerusan Tipe 2 menggunakan rute di jaringan lokal Anda.

Guna mengetahui panduan tambahan tentang persyaratan jaringan untuk target Jenis 1 dan Jenis 2, lihat persyaratan jaringan target penerusan.

Alamat IP target penerusan terlarang

Anda tidak dapat menggunakan alamat IP berikut untuk target penerusan Cloud DNS:

169.254.0.0/16
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
240.0.0.0/4
::1/128
::/128
2001:db8::/32
fe80::/10
fec0::/10
ff00::/8

Urutan pemilihan target penerusan

Dengan Cloud DNS, Anda dapat mengonfigurasi daftar target penerusan untuk zona penerusan.

Saat Anda mengonfigurasi dua atau beberapa target penerusan, Cloud DNS akan menggunakan algoritma internal untuk memilih target penerusan. Algoritma ini memberi peringkat untuk setiap target penerusan.

Untuk memproses permintaan, Cloud DNS terlebih dahulu mencoba kueri DNS dengan menghubungi target penerusan dengan peringkat tertinggi. Jika server tidak merespons, Cloud DNS akan mengulangi permintaan ke target penerusan dengan peringkat tertinggi berikutnya. Jika tidak ada penerusan target yang dibalas, Cloud DNS akan menyintesis respons SERVFAIL.

Algoritma peringkat bersifat otomatis, dan faktor berikut meningkatkan peringkat target penerusan:

Makin tinggi jumlah respons DNS yang berhasil diproses oleh target penerusan. Respons DNS yang berhasil menyertakan respons NXDOMAIN.
Makin rendah latensi (waktu round-trip) untuk berkomunikasi dengan target penerusan.

Menggunakan zona penerusan

VM di jaringan VPC dapat menggunakan zona penerusan Cloud DNS dalam kasus berikut:

Jaringan VPC telah diberi otorisasi untuk menggunakan zona penerusan Cloud DNS. Anda dapat mengizinkan beberapa jaringan VPC dalam project yang sama untuk menggunakan zona penerusan.
Sistem operasi tamu pada setiap VM di jaringan VPC menggunakan server metadata VM 169.254.169.254 sebagai server namanya.

Zona penerusan yang tumpang-tindih

Karena zona penerusan Cloud DNS adalah jenis zona pribadi terkelola Cloud DNS, Anda dapat membuat beberapa zona yang tumpang tindih. VM yang dikonfigurasi seperti yang dijelaskan sebelumnya akan menyelesaikan kumpulan data sesuai dengan urutan resolusi nama, menggunakan zona dengan akhiran terpanjang. Untuk informasi selengkapnya, lihat Zona tumpang-tindih.

Zona cache dan penerusan

Cloud DNS menyimpan respons untuk kueri yang dikirim ke zona penerusan Cloud DNS. Cloud DNS menyimpan cache respons dari target penerusan yang dapat dijangkau selama lebih singkat dari rentang waktu berikut:

60 detik
Durasi time to live (TTL) kumpulan data

Ketika semua target penerusan untuk zona penerusan menjadi tidak dapat dijangkau, Cloud DNS akan menyimpan cache-nya dari data yang diminta sebelumnya di zona tersebut selama durasi setiap TTL data.

Kapan harus menggunakan peering

Cloud DNS tidak dapat menggunakan perutean transitif untuk terhubung ke target penerusan. Untuk menggambarkan konfigurasi yang tidak valid, pertimbangkan skenario berikut:

Anda telah menggunakan Cloud VPN atau Cloud Interconnect untuk menghubungkan jaringan lokal ke jaringan VPC yang bernama vpc-net-a.
Anda telah menggunakan Peering Jaringan VPC untuk menghubungkan jaringan VPC vpc-net-a ke vpc-net-b. Anda telah mengonfigurasi vpc-net-a untuk mengekspor rute kustom, dan vpc-net-b untuk mengimpornya.
Anda telah membuat zona penerusan yang target penerusannya berada di jaringan lokal yang terhubung dengan vpc-net-a. Anda telah mengizinkan vpc-net-b untuk menggunakan zona penerusan tersebut.

Penyelesaian kumpulan data di zona yang disalurkan oleh target penerusan akan gagal dalam skenario ini, meskipun ada konektivitas dari vpc-net-b ke jaringan lokal Anda. Untuk menunjukkan kegagalan ini, lakukan pengujian berikut dari VM di vpc-net-b:

Buat kueri 169.254.169.254 server metadata VM untuk data yang ditentukan di zona penerusan. Kueri ini gagal (diperkirakan) karena Cloud DNS tidak mendukung pemilihan rute transitif ke target penerusan. Untuk menggunakan zona penerusan, VM harus dikonfigurasi untuk menggunakan server metadatanya.
Mengkueri target penerusan secara langsung untuk kumpulan data yang sama. Meskipun Cloud DNS tidak menggunakan jalur ini, kueri ini menunjukkan bahwa konektivitas transitif berhasil.

Anda dapat menggunakan zona peering Cloud DNS untuk memperbaiki skenario yang tidak valid ini:

Buat zona peering Cloud DNS yang diotorisasi untuk vpc-net-b yang menargetkan vpc-net-a.
Buat zona penerusan yang diizinkan untuk vpc-net-a yang target penerusannya adalah server nama lokal.

Anda dapat melakukan langkah-langkah ini dalam urutan apa pun. Setelah menyelesaikan langkah-langkah ini, instance Compute Engine di vpc-net-a dan vpc-net-b dapat mengkueri target penerusan lokal.

Untuk mengetahui informasi tentang cara membuat zona penerusan, lihat Membuat zona penerusan.

Zona peering

Peering DNS memungkinkan Anda mengirim permintaan untuk data yang berasal dari namespace satu zona ke jaringan VPC lainnya. Misalnya, penyedia SaaS dapat memberi pelanggan SaaS akses ke data DNS yang dikelolanya.

Untuk menyediakan peering DNS, Anda harus membuat zona peering Cloud DNS dan mengonfigurasinya untuk melakukan pencarian DNS di jaringan VPC tempat data untuk namespace zona tersebut tersedia. Jaringan VPC tempat zona peering DNS melakukan pencarian disebut jaringan produser DNS.

Zona peering hanya terlihat oleh jaringan VPC yang dipilih selama konfigurasi zona. Jaringan VPC yang diotorisasi untuk menggunakan zona peering disebut jaringan konsumen DNS.

Setelah resource Google Cloud di jaringan konsumen DNS diotorisasi, resource tersebut dapat melakukan pencarian data di namespace zona peering seolah-olah berada di jaringan produsen DNS. Pencarian data di namespace zona peering mengikuti urutan resolusi nama jaringan produsen DNS.

Oleh karena itu, resource Google Cloud di jaringan konsumen DNS dapat mencari kumpulan data dalam namespace zona dari sumber berikut yang tersedia di jaringan produsen DNS:

Zona pribadi terkelola Cloud DNS yang diizinkan untuk digunakan oleh jaringan produser DNS.
Zona penerusan terkelola Cloud DNS diizinkan untuk digunakan oleh jaringan produsen DNS.
Nama DNS internal Compute Engine di jaringan produsen DNS.
Server nama alternatif, jika kebijakan server keluar telah dikonfigurasi di jaringan produsen DNS.

Batasan peering DNS dan poin penting

Perhatikan hal-hal berikut saat mengonfigurasi peering DNS:

Peering DNS adalah hubungan satu arah. Hal ini memungkinkan resource Google Cloud di jaringan konsumen DNS untuk mencari data di namespace zona peering seolah-olah resource Google Cloud berada di jaringan DNS prod.
Jaringan produsen dan konsumen DNS harus berupa jaringan VPC.
Meskipun jaringan produsen dan konsumen DNS biasanya merupakan bagian dari organisasi yang sama, peering DNS lintas organisasi juga didukung.
Peering DNS dan Peering Jaringan VPC adalah layanan yang berbeda. Peering DNS dapat digunakan dengan Peering Jaringan VPC, tetapi Peering Jaringan VPC tidak diperlukan untuk peering DNS.
Peering DNS transitif didukung, tetapi hanya melalui satu hop transitif. Dengan kata lain, tidak lebih dari tiga jaringan VPC (dengan jaringan di tengahnya merupakan hop transitif) yang dapat dilibatkan. Misalnya, Anda dapat membuat zona peering di vpc-net-a yang menargetkan vpc-net-b, lalu membuat zona peering di vpc-net-b yang menargetkan vpc-net-c.
Jika Anda menggunakan peering DNS untuk menargetkan zona penerusan, jaringan VPC target dengan zona penerusan harus berisi VM, lampiran VLAN, atau tunnel Cloud VPN yang berada di region yang sama dengan VM sumber yang menggunakan zona peering DNS. Untuk mengetahui detail tentang batasan ini, lihat Meneruskan kueri dari VM di jaringan VPC konsumen ke jaringan VPC produsen yang tidak berfungsi.

Untuk mengetahui petunjuk cara membuat zona peering, lihat Membuat zona peering.

Zona pencarian balik terkelola

Zona pencarian balik terkelola adalah zona pribadi dengan atribut khusus yang memerintahkan Cloud DNS untuk melakukan pencarian PTR terhadap data DNS Compute Engine.

Data PTR untuk alamat RFC 1918 di zona pribadi

Untuk melakukan pencarian balik dengan data PTR kustom untuk alamat RFC 1918, Anda harus membuat zona pribadi Cloud DNS yang setidaknya sama spesifiknya dengan salah satu contoh zona berikut. Ini adalah konsekuensi dari pencocokan akhiran terpanjang yang dijelaskan dalam Urutan penyelesaian nama.

Contoh zona meliputi:

10.in-addr.arpa.
168.192.in-addr.arpa.
16.172.in-addr.arpa., 17.172.in-addr.arpa., ... hingga 31.172.in-addr.arpa.

Jika Anda membuat zona pribadi Cloud DNS untuk alamat RFC 1918, data PTR kustom yang Anda buat untuk VM di zona tersebut akan diganti oleh data PTR yang dibuat secara otomatis oleh DNS internal. Hal ini karena data PTR DNS internal dibuat di daftar sebelumnya tentang zona yang lebih spesifik.

Misalnya, Anda membuat zona pribadi terkelola untuk in-addr.arpa. dengan data PTR berikut untuk VM yang alamat IP-nya adalah 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

Kueri PTR untuk 1.1.1.10.in-addr.arpa. dijawab oleh zona DNS internal 10.in-addr.arpa. yang lebih spesifik. Data PTR di zona pribadi Cloud DNS untuk test.example.domain akan diabaikan.

Untuk mengganti data PTR DNS internal yang dibuat secara otomatis untuk VM, pastikan Anda membuat data PTR kustom di zona pribadi yang setidaknya sama spesifiknya dengan salah satu zona yang ditampilkan di bagian ini. Misalnya, jika Anda membuat data PTR berikut dalam zona pribadi untuk 10.in-addr.arpa., data Anda akan menggantikan data yang dibuat secara otomatis: 1.1.1.10.in-addr.arpa. -> test.example.domain.

Jika hanya perlu mengganti sebagian blok jaringan, Anda dapat membuat zona pribadi Cloud DNS terbalik yang lebih spesifik. Misalnya, zona pribadi untuk 5.10.in-addr.arpa. dapat digunakan untuk menyimpan data PTR yang menggantikan data PTR DNS internal apa pun yang otomatis dibuat untuk VM dengan alamat IP di rentang alamat 10.5.0.0/16.

Untuk petunjuk cara membuat zona pencarian terbalik yang terkelola, lihat Membuat zona pencarian terbalik yang dikelola.

Zona tumpang-tindih

Dua zona tumpang-tindih satu sama lain jika nama domain asal satu zona sama dengan atau merupakan subdomain dari asal zona lainnya. Misalnya:

Satu zona untuk gcp.example.com dan zona lain untuk gcp.example.com tumpang-tindih karena nama domainnya identik.
Zona untuk dev.gcp.example.com dan zona untuk gcp.example.com tumpang-tindih karena dev.gcp.example.com adalah subdomain dari gcp.example.com.

Aturan untuk zona yang tumpang-tindih

Cloud DNS menerapkan aturan berikut untuk zona yang tumpang-tindih:

Zona publik yang tumpang-tindih tidak diizinkan di server nama Cloud DNS yang sama. Saat Anda membuat zona yang tumpang-tindih, Cloud DNS akan mencoba menempatkannya di server nama yang berbeda. Jika tidak memungkinkan, Cloud DNS akan gagal membuat zona yang tumpang-tindih.
Zona pribadi dapat tumpang tindih dengan zona publik mana pun.
Zona pribadi yang dicakup untuk jaringan VPC yang berbeda dapat saling tumpang-tindih. Misalnya, dua jaringan VPC masing-masing dapat memiliki VM database bernama database.gcp.example.com di zona gcp.example.com. Kueri untuk database.gcp.example.com menerima jawaban yang berbeda sesuai dengan data zona yang ditentukan di zona yang diizinkan untuk setiap jaringan VPC.
Dua zona pribadi yang telah diizinkan untuk dapat diakses dari jaringan VPC yang sama tidak dapat memiliki origin yang sama kecuali jika satu zona merupakan subdomain dari zona lainnya. Server metadata menggunakan pencocokan akhiran terpanjang guna menentukan tempat asal yang akan dikueri untuk kumpulan data di zona tertentu.

Contoh penyelesaian kueri

Google Cloud me-resolve zona Cloud DNS seperti yang dijelaskan dalam Urutan resolusi nama. Saat menentukan zona yang akan dibuat kueri untuk data tertentu, Cloud DNS mencoba menemukan zona yang cocok dengan sebanyak mungkin data yang diminta (pencocokan akhiran terpanjang).

Kecuali jika Anda telah menentukan server nama alternatif dalam kebijakan server keluar, Google Cloud terlebih dahulu akan mencoba menemukan data di zona pribadi (atau zona penerusan atau zona peering) yang diizinkan untuk jaringan VPC Anda sebelum mencari data di zona publik.

Contoh berikut mengilustrasikan urutan yang digunakan server metadata saat membuat kueri data DNS. Untuk masing-masing contoh ini, misalkan Anda telah membuat dua zona pribadi, gcp.example.com dan dev.gcp.example.com, serta mengizinkan akses ke zona tersebut dari jaringan VPC yang sama. Google Cloud menangani kueri DNS dari VM di jaringan VPC dengan cara berikut:

Server metadata menggunakan server nama publik guna me-resolve data untuk myapp.example.com. (perhatikan titik akhir) karena tidak ada zona pribadi untuk example.com yang telah diotorisasi untuk jaringan VPC. Gunakan dig dari VM Compute Engine untuk membuat kueri server nama default VM:
```
dig myapp.example.com.
```
Untuk mengetahui detailnya, baca Membuat kueri untuk nama DNS menggunakan server metadata.
Server metadata me-resolve data myapp.gcp.example.com menggunakan zona pribadi yang diotorisasi gcp.example.com karena gcp.example.com adalah akhiran umum terpanjang antara nama kumpulan data yang diminta dan zona pribadi yang diizinkan yang tersedia. NXDOMAIN ditampilkan jika tidak ada data untuk myapp.gcp.example.com yang ditentukan di zona pribadi gcp.example.com, meskipun ada data untuk myapp.gcp.example.com yang ditentukan di zona publik.
Demikian pula, kueri untuk myapp.dev.gcp.example.com diselesaikan sesuai dengan catatan dalam dev.gcp.example.com zona pribadi yang diizinkan. NXDOMAIN ditampilkan jika tidak ada data untuk myapp.dev.gcp.example.com di zona dev.gcp.example.com, meskipun ada data untuk myapp.dev.gcp.example.com di zona pribadi atau publik lainnya.
Kueri untuk myapp.prod.gcp.example.com di-resolve sesuai dengan data di zona pribadi gcp.example.com karena gcp.example.com adalah akhiran umum terpanjang antara data DNS yang diminta dan zona pribadi yang tersedia.

Contoh DNS Horizon terpisah

Anda dapat menggunakan kombinasi zona publik dan pribadi di konfigurasi DNS horizontal terpisah. Zona pribadi memungkinkan Anda menentukan respons yang berbeda terhadap kueri untuk data yang sama saat kueri tersebut berasal dari VM dalam jaringan VPC yang diberi otorisasi. DNS Horizon terpisah berguna setiap kali Anda perlu menyediakan data yang berbeda untuk kueri DNS yang sama, bergantung pada jaringan VPC asal.

Perhatikan contoh Horizon terpisah berikut:

Anda telah membuat zona publik, gcp.example.com, dan telah mengonfigurasi registrar-nya untuk menggunakan server nama Cloud DNS.
Anda telah membuat zona pribadi, gcp.example.com, dan telah mengizinkan jaringan VPC Anda untuk mengakses zona ini.

Di zona pribadi, Anda telah membuat satu data seperti yang ditunjukkan dalam tabel berikut.

Rekam	Jenis	TTL (detik)	Data
myrecord1.gcp.example.com	A	5	10.128.1.35

Di zona publik, Anda telah membuat dua kumpulan data.

Rekam	Jenis	TTL (detik)	Data
myrecord1.gcp.example.com	A	5	104.198.6.142
myrecord2.gcp.example.com	A	50	104.198.7.145

Kueri berikut diselesaikan seperti yang dijelaskan:

Kueri untuk myrecord1.gcp.example.com dari VM di jaringan VPC Anda menampilkan 10.128.1.35.
Kueri untuk myrecord1.gcp.example.com dari internet akan menampilkan 104.198.6.142.
Kueri untuk myrecord2.gcp.example.com dari VM di jaringan VPC Anda menampilkan error NXDOMAIN karena tidak ada data untuk myrecord2.gcp.example.com dalam zona pribadi gcp.example.com.
Kueri untuk myrecord2.gcp.example.com dari internet akan menampilkan 104.198.7.145.

Binding lintas-project

Dengan binding lintas project, Anda dapat mempertahankan kepemilikan namespace DNS project layanan untuk tidak bergantung pada kepemilikan namespace DNS seluruh jaringan VPC.

Penyiapan VPC Bersama standar memiliki project layanan yang mengambil alih kepemilikan aplikasi atau layanan virtual machine (VM), sedangkan project host mengambil alih kepemilikan jaringan VPC dan infrastruktur jaringan. Sering kali, namespace DNS dibuat dari namespace jaringan VPC agar cocok dengan resource project layanan. Untuk penyiapan seperti itu, akan lebih mudah untuk mendelegasikan administrasi namespace DNS setiap project layanan kepada administrator setiap project layanan (yang biasanya merupakan departemen atau bisnis yang berbeda). Dengan binding lintas project, Anda dapat memisahkan kepemilikan namespace DNS project layanan dari kepemilikan namespace DNS seluruh jaringan VPC.

Gambar berikut menunjukkan penyiapan VPC Bersama yang umum dengan peering DNS.

Penyiapan VPC Bersama dengan peering DNS. — Penyiapan VPC Bersama dengan peering DNS (klik untuk memperbesar)

Gambar berikut menunjukkan penyiapan menggunakan binding lintas project. Cloud DNS memungkinkan setiap project layanan membuat dan memiliki zona DNS-nya sendiri, tetapi tetap terikat ke jaringan bersama yang dimiliki project host. Hal ini memungkinkan otonomi yang lebih baik dan batas izin yang lebih tepat untuk administrasi zona DNS.

Penyiapan dengan binding lintas project. — Penyiapan dengan binding lintas project (klik untuk memperbesar)

Binding lintas-project menyediakan hal berikut:

Administrator dan pengguna project layanan dapat membuat dan mengelola zona DNS mereka sendiri.
Anda tidak perlu membuat jaringan VPC placeholder.
Administrator project host tidak perlu mengelola project layanan.
Peran IAM masih berlaku di level project.
Semua zona DNS dikaitkan langsung dengan jaringan VPC Bersama.
Resolusi DNS apa pun sudah tersedia. Setiap VM dalam jaringan VPC Bersama dapat me-resolve zona terkait.
Tidak ada batas hop transitif. Anda dapat mengelolanya dalam desain hub dan spoke.

Untuk mengetahui petunjuk cara membuat zona dengan binding lintas project yang diaktifkan, lihat Membuat zona binding lintas project.

Zona Cloud DNS zona

Cloud DNS zona dapat digunakan untuk membuat zona DNS pribadi yang hanya dicakup dalam zona Google Cloud. Zona DNS Cloud zona dibuat untuk GKE saat Anda memilih cakupan cluster.

Layanan Cloud DNS default bersifat global dan nama DNS dapat dilihat secara global dalam jaringan VPC Anda. Konfigurasi ini akan mengekspos layanan Anda pada pemadaman layanan global. Zonal Cloud DNS adalah layanan Cloud DNS pribadi baru yang ada dalam setiap zona Google Cloud. Domain kegagalan ada di dalam zona Google Cloud tersebut. Zona pribadi Cloud DNS zona tidak terpengaruh saat terjadi pemadaman global. Setiap gangguan zona Google Cloud hanya memengaruhi zona Google Cloud dan zona Cloud DNS tertentu dalam zona Google Cloud tersebut. Perhatikan bahwa setiap resource yang dibuat di layanan zona hanya terlihat oleh zona Google Cloud tersebut.

Untuk mempelajari cara mengonfigurasi zona cakupan cluster Cloud DNS zona, lihat Mengonfigurasi zona cakupan cluster GKE zona.

Dukungan Cloud DNS zona

Tabel berikut berisi daftar resource dan fitur Cloud DNS yang didukung oleh layanan Cloud DNS zona.

Resource atau fitur	Tersedia di Cloud DNS global	Tersedia di Cloud DNS zona
Zona publik terkelola
Zona pribadi terkelola (cakupan jaringan atau VPC)
Zona pribadi terkelola (cakupan GKE)
Zona penerusan¹
Zona peering
Zona pencarian balik terkelola
Membuat perubahan atau mengelola data²
Zona Direktori Layanan
Kebijakan
Kebijakan respons (cakupan jaringan)
Kebijakan respons (cakupan cluster GKE)
Aturan kebijakan respons

¹Cloud DNS Zona hanya mendukung zona penerusan yang dicakupkan ke cluster GKE.

²Pengontrol GKE menimpa perubahan apa pun pada data saat pengontrol dimulai ulang.

Penagihan untuk zona Cloud DNS zona

Penagihan untuk zona Cloud DNS zona dan kebijakan respons berfungsi dengan cara yang sama seperti kebijakan respons global.

Langkah selanjutnya

Untuk menangani zona terkelola, lihat Membuat, mengubah, dan menghapus zona.
Untuk menemukan solusi atas masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS, lihat Pemecahan masalah.
Untuk mendapatkan ringkasan Cloud DNS, lihat ringkasan Cloud DNS.