Cloud DNS mendukung berbagai jenis zonapublik dan pribadi. Dokumen ini memberikan detail tentang berbagai jenis zona dan kapan Anda dapat menggunakan salah satu jenis zona tersebut.
Zona penerusan
Zona penerusan Cloud DNS memungkinkan Anda mengonfigurasi server nama target untuk zona pribadi tertentu. Menggunakan zona penerusan adalah salah satu cara untuk menerapkan penerusan DNS keluar dari jaringan VPC Anda.
Zona penerusan Cloud DNS adalah jenis khusus zona pribadi Cloud DNS. Daripada membuat data dalam zona, Anda 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 perutean
Cloud DNS mendukung tiga jenis target dan menawarkan metode perutean standar atau pribadi untuk konektivitas.
Target penerusan | Deskripsi | Dukungan pemilihan rute standar | Dukungan pemilihan rute pribadi | 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 selalu dirutekan melalui jaringan VPC resmi. | Alamat IP internal apa pun, seperti alamat pribadi RFC 1918, alamat IP pribadi non-RFC 1918, atau alamat IP eksternal yang digunakan kembali secara pribadi, kecuali alamat IP target penerusan yang dilarang —traffic selalu dirutekan melalui jaringan VPC resmi. | 35.199.192.0/19 |
Jenis 2 | Alamat IP 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 selalu dirutekan melalui jaringan VPC resmi. | Alamat IP internal apa pun, seperti alamat pribadi RFC 1918, alamat IP pribadi non-RFC 1918, atau alamat IP eksternal yang digunakan kembali secara pribadi, kecuali alamat IP target penerusan yang dilarang — traffic selalu dirutekan melalui jaringan VPC resmi. | 35.199.192.0/19 |
Jenis 3 | Alamat IP eksternal 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—traffic selalu dirutekan ke internet atau ke alamat IP eksternal resource Google Cloud. | Pemilihan rute pribadi tidak didukung—pastikan pemilihan rute 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:
Perutean standar: Merutekan traffic melalui jaringan VPC resmi atau melalui internet berdasarkan apakah target penerusan adalah alamat IP RFC 1918. Jika target penerusan adalah alamat IP RFC 1918, Cloud DNS akan mengklasifikasikan target tersebut sebagai target Jenis 1 atau Jenis 2, dan merutekan permintaan melalui jaringan VPC yang diotorisasi. Jika target bukan alamat IP RFC 1918, Cloud DNS akan mengklasifikasikan target sebagai Jenis 3, dan mengharapkan target dapat diakses internet.
Pemetaan pribadi: Selalu merutekan traffic melalui jaringan VPC yang diotorisasi, terlepas dari alamat IP target (RFC 1918 atau bukan). Oleh karena itu, 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 resmi 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 jalur pemilihan rute 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. Untuk membalas, target penerusan Jenis 2 menggunakan rute di jaringan lokal Anda.
Untuk panduan tambahan tentang persyaratan jaringan untuk target Jenis 1 dan Jenis 2, lihat persyaratan jaringan target penerusan.
Alamat IP target penerusan yang dilarang
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
Cloud DNS memungkinkan Anda mengonfigurasi daftar target penerusan untuk zona penerusan.
Saat Anda mengonfigurasi dua target penerusan atau lebih, Cloud DNS menggunakan algoritma internal untuk memilih target penerusan. Algoritme ini memberi peringkat pada setiap target penerusan.
Untuk memproses permintaan, Cloud DNS terlebih dahulu mencoba kueri DNS dengan menghubungi target penerusan dengan peringkat tertinggi. Jika server tersebut tidak merespons, Cloud DNS akan mengulangi permintaan ke target penerusan dengan peringkat tertinggi berikutnya. Jika tidak ada respons target penerusan, 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 mencakup respons NXDOMAIN.
- Makin rendah latensi (waktu bolak-balik) 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. Untuk menggunakan zona penerusan, Anda dapat memberikan otorisasi ke beberapa jaringan VPC dalam project yang sama atau di seluruh project, selama jaringan VPC tersebut berada dalam organisasi yang sama.
Sistem operasi tamu dari setiap VM di jaringan VPC menggunakan
169.254.169.254
server metadata VM sebagai server namanya.
Zona penerusan yang tumpang-tindih
Karena zona penerusan Cloud DNS adalah jenis zona pribadi yang dikelola Cloud DNS, Anda dapat membuat beberapa zona yang tumpang-tindih. VM yang dikonfigurasi seperti yang dijelaskan sebelumnya me-resolve data sesuai dengan urutan resolusi nama, menggunakan zona dengan akhiran terpanjang. Untuk mengetahui informasi selengkapnya, lihat Zona yang tumpang-tindih.
Zona penyimpanan ke cache dan penerusan
Cloud DNS meng-cache respons untuk kueri yang dikirim ke zona penerusan Cloud DNS. Cloud DNS mempertahankan cache respons dari target penerusan yang dapat dijangkau selama rentang waktu lebih singkat dari rentang waktu berikut:
- 60 detik
- Durasi time to live (TTL) kumpulan data
Jika semua target penerusan untuk zona penerusan tidak dapat dijangkau, Cloud DNS akan mempertahankan cache data yang sebelumnya diminta di zona tersebut selama durasi TTL setiap data.
Kapan harus menggunakan peering
Cloud DNS tidak dapat menggunakan perutean transitif untuk terhubung ke target penerusan. Untuk mengilustrasikan konfigurasi yang tidak valid, pertimbangkan skenario berikut:
Anda telah menggunakan Cloud VPN atau Cloud Interconnect untuk menghubungkan jaringan lokal ke jaringan VPC bernama
vpc-net-a
.Anda telah menggunakan Peering Jaringan VPC untuk menghubungkan jaringan VPC
vpc-net-a
kevpc-net-b
. Anda telah mengonfigurasivpc-net-a
untuk mengekspor rute kustom, danvpc-net-b
untuk mengimpornya.Anda telah membuat zona penerusan yang target penerusannya berada di jaringan lokal tempat
vpc-net-a
terhubung. Anda telah mengizinkanvpc-net-b
untuk menggunakan zona penerusan tersebut.
Me-resolve data di zona yang ditayangkan oleh target penerusan gagal dalam
skenario ini, meskipun ada konektivitas dari vpc-net-b
ke jaringan
on-premise 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 (seperti yang diharapkan) karena Cloud DNS tidak mendukung perutean transitif ke target penerusan. Untuk menggunakan zona penerusan, VM harus dikonfigurasi untuk menggunakan server metadata-nya.Buat kueri target penerusan langsung untuk 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 menargetkanvpc-net-a
. - Buat zona penerusan yang diotorisasi 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 membuat kueri
target penerusan di lokal.
Untuk mengetahui informasi tentang cara membuat zona penerusan, lihat Membuat zona penerusan.
Zona peering
Zona peering adalah zona pribadi Cloud DNS yang memungkinkan Anda mengirim permintaan DNS antara zona Cloud DNS di jaringan VPC yang berbeda. Misalnya, penyedia software as a service (SaaS) dapat memberi pelanggan akses ke data DNS terkelola mereka di Cloud DNS.
Untuk menyediakan peering DNS, Anda harus membuat zona peering pribadi 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 produsen DNS.
Zona peering hanya dapat dilihat oleh jaringan VPC yang dipilih selama konfigurasi zona. Jaringan VPC yang diberi otorisasi untuk menggunakan zona peering disebut jaringan konsumen DNS.
Setelah resource Google Cloud di jaringan konsumen DNS diberi otorisasi, resource tersebut dapat melakukan pencarian data di namespace zona peering seolah-olah berada di jaringan produsen DNS. Penelusuran untuk data dalam namespace zona peering mengikuti urutan resolusi nama jaringan produsen DNS.
Oleh karena itu, resource Google Cloud di jaringan konsumen DNS dapat mencari data di namespace zona dari sumber berikut yang tersedia di jaringan produsen DNS:
- Zona pribadi yang dikelola Cloud DNS yang diizinkan untuk digunakan oleh jaringan produser DNS.
- Zona penerusan terkelola Cloud DNS yang diizinkan untuk digunakan oleh jaringan produser DNS.
- Nama DNS internal Compute Engine di jaringan produsen DNS.
- Server nama alternatif, jika kebijakan server keluar telah dikonfigurasi di jaringan produsen DNS.
Dengan peering DNS, Anda dapat memiliki satu jaringan (jaringan konsumen DNS) yang meneruskan permintaan DNS ke jaringan lain (jaringan produsen DNS), yang kemudian melakukan pencarian 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 produsen DNS.
- 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 Jaringan VPC tidak otomatis membagikan informasi DNS. 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 tengah sebagai hop transitif) yang dapat dilibatkan. Misalnya,
Anda dapat membuat zona peering di
vpc-net-a
yang menargetkanvpc-net-b
, lalu membuat zona peering divpc-net-b
yang menargetkanvpc-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 Penerusan kueri dari VM di jaringan VPC konsumen ke jaringan VPC produsen tidak berfungsi.
Untuk petunjuk tentang cara membuat zona peering, lihat Membuat zona peering.
Zona pencarian balik yang dikelola
Zona pencarian balik terkelola adalah zona pribadi dengan atribut khusus yang menginstruksikan 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. Hal ini merupakan konsekuensi dari pencocokan akhiran terpanjang yang dijelaskan dalam Urutan resolusi nama.
Contoh zona mencakup:
10.in-addr.arpa.
168.192.in-addr.arpa.
16.172.in-addr.arpa.
,17.172.in-addr.arpa.
, ... hingga31.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 dalam daftar zona yang lebih spesifik sebelumnya.
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 Anda untuk test.example.domain
akan diabaikan.
Untuk mengganti data PTR DNS internal yang dibuat 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 di 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 mengganti data PTR DNS internal yang dibuat otomatis untuk VM dengan alamat IP dalam rentang alamat 10.5.0.0/16
.
Untuk petunjuk cara membuat zona pencarian terbalik yang terkelola, lihat Membuat zona pencarian terbalik yang terkelola.
Zona yang tumpang-tindih
Dua zona tumpang-tindih satu sama lain jika nama domain asal satu zona sama dengan atau merupakan subdomain asal zona lain. Misalnya:
- Zona untuk
gcp.example.com
dan zona lain untukgcp.example.com
tumpang-tindih karena nama domainnya identik. - Zona untuk
dev.gcp.example.com
dan zona untukgcp.example.com
tumpang-tindih karenadev.gcp.example.com
adalah subdomain darigcp.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 gagal membuat zona yang tumpang-tindih.
- Zona pribadi dapat tumpang-tindih dengan zona publik apa 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 zonagcp.example.com
. Kueri untukdatabase.gcp.example.com
menerima jawaban yang berbeda sesuai dengan catatan zona yang ditentukan di zona yang diotorisasi untuk setiap jaringan VPC.Dua zona pribadi yang telah diberi otorisasi untuk dapat diakses dari jaringan VPC yang sama tidak boleh memiliki asal yang sama, kecuali jika satu zona adalah subdomain dari zona lainnya. Server metadata menggunakan pencocokan akhiran terpanjang untuk menentukan asal yang akan dikueri untuk data di zona tertentu.
Contoh resolusi kueri
Google Cloud me-resolve zona Cloud DNS seperti yang dijelaskan dalam Urutan resolusi nama. Saat menentukan zona untuk dikueri untuk data tertentu, Cloud DNS mencoba menemukan zona yang cocok sebanyak mungkin dengan data yang diminta (pencocokan akhiran terpanjang).
Kecuali jika Anda telah menentukan server nama alternatif dalam kebijakan server
keluar, Google Cloud akan mencoba menemukan data di zona pribadi (atau
zona penerusan atau zona peering) yang diotorisasi untuk jaringan VPC
Anda sebelum mencari
data di zona publik.
Contoh berikut mengilustrasikan urutan yang digunakan server metadata saat
membuat kueri data DNS. Untuk setiap contoh ini, misalkan Anda telah membuat
dua zona pribadi, gcp.example.com
dan dev.gcp.example.com
, dan memberikan otorisasi
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 untuk me-resolve data untuk
myapp.example.com.
(perhatikan titik di akhir) karena tidak ada zona pribadi untukexample.com
yang telah diotorisasi untuk jaringan VPC. Gunakandig
dari VM Compute Engine untuk membuat kueri server nama default VM:dig myapp.example.com.
Untuk mengetahui detailnya, lihat Mengkueri nama DNS menggunakan server metadata.
Server metadata me-resolve data
myapp.gcp.example.com
menggunakan zona pribadi resmigcp.example.com
karenagcp.example.com
adalah akhiran umum terpanjang antara nama data yang diminta dan zona pribadi resmi yang tersedia.NXDOMAIN
ditampilkan jika tidak ada data untukmyapp.gcp.example.com
yang ditentukan di zona pribadigcp.example.com
, meskipun ada data untukmyapp.gcp.example.com
yang ditentukan di zona publik.Demikian pula, kueri untuk
myapp.dev.gcp.example.com
di-resolve sesuai dengan data di zona pribadi resmidev.gcp.example.com
.NXDOMAIN
ditampilkan jika tidak ada data untukmyapp.dev.gcp.example.com
di zonadev.gcp.example.com
, meskipun ada data untukmyapp.dev.gcp.example.com
di zona pribadi atau publik lain.Kueri untuk
myapp.prod.gcp.example.com
di-resolve sesuai dengan data di zona pribadigcp.example.com
karenagcp.example.com
adalah akhiran umum terpanjang antara data DNS yang diminta dan zona pribadi yang tersedia.
Contoh DNS split-horizon
Anda dapat menggunakan kombinasi zona publik dan pribadi dalam konfigurasi DNS horison terpisah. Zona pribadi memungkinkan Anda menentukan respons yang berbeda terhadap kueri untuk data yang sama saat kueri berasal dari VM dalam jaringan VPC yang diotorisasi. DNS split horizon berguna setiap kali Anda perlu memberikan data yang berbeda untuk kueri DNS yang sama, bergantung pada jaringan VPC yang berasal.
Perhatikan contoh split horizon berikut:
- Anda telah membuat zona publik,
gcp.example.com
, dan telah mengonfigurasi registrarnya untuk menggunakan server nama Cloud DNS. - Anda telah membuat zona pribadi,
gcp.example.com
, dan telah memberikan otorisasi pada jaringan VPC untuk mengakses zona ini.
Di zona pribadi, Anda telah membuat satu kumpulan data seperti yang ditunjukkan pada tabel berikut.
Rekam | Jenis | TTL (detik) | Data |
---|---|---|---|
myrecord1.gcp.example.com | A | 5 | 10.128.1.35 |
Di zona publik, Anda telah membuat dua 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 akan menampilkan10.128.1.35
. - Kueri untuk
myrecord1.gcp.example.com
dari internet akan menampilkan104.198.6.142
. - Kueri untuk
myrecord2.gcp.example.com
dari VM di jaringan VPC Anda menampilkan errorNXDOMAIN
karena tidak ada data untukmyrecord2.gcp.example.com
di zona pribadigcp.example.com
. - Kueri untuk
myrecord2.gcp.example.com
dari internet akan menampilkan104.198.7.145
.
Binding lintas project
Binding lintas project memungkinkan Anda mempertahankan kepemilikan namespace DNS project layanan secara terpisah dari kepemilikan namespace DNS seluruh jaringan VPC.
Penyiapan VPC Bersama standar memiliki project layanan yang memiliki kepemilikan atas aplikasi atau layanan virtual machine (VM), sedangkan project host memiliki kepemilikan atas jaringan VPC dan infrastruktur jaringan. Sering kali, namespace DNS dibuat dari namespace jaringan VPC untuk mencocokkan resource project layanan. Untuk penyiapan tersebut, akan lebih mudah untuk mendelegasikan administrasi namespace DNS setiap project layanan kepada administrator setiap project layanan (yang sering kali merupakan departemen atau bisnis yang berbeda). Binding lintas project memungkinkan Anda memisahkan kepemilikan namespace DNS project layanan dari kepemilikan namespace DNS seluruh jaringan VPC.
Gambar berikut menunjukkan penyiapan VPC Bersama standar dengan peering DNS.
Gambar berikut menunjukkan penyiapan menggunakan binding lintas project. Cloud DNS memungkinkan setiap project layanan membuat dan memiliki zona DNS-nya, tetapi tetap mengikatkannya ke jaringan bersama yang dimiliki project host. Hal ini memungkinkan otonomi yang lebih baik dan batas izin yang lebih akurat untuk administrasi zona DNS.
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 tetap berlaku di level project.
- Semua zona DNS terkait langsung dengan jaringan VPC Bersama.
- Resolusi DNS any-to-any sudah tersedia. Setiap VM di jaringan VPC Bersama dapat me-resolve zona terkait.
- Tidak ada batas hop transitif. Anda dapat mengelolanya dalam desain hub dan spoke.
Untuk petunjuk cara membuat zona dengan binding lintas project yang diaktifkan, lihat Membuat zona binding lintas project.
Zona Cloud DNS zonal
Cloud DNS Zonal memungkinkan Anda membuat zona DNS pribadi yang cakupannya hanya untuk zona Google Cloud. Zona Cloud DNS zonal 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 membuat layanan Anda terkena pemadaman global. Cloud DNS Zonal adalah layanan Cloud DNS pribadi baru yang ada dalam setiap zona Google Cloud. Domain kegagalan berada dalam zona Google Cloud tersebut. Zona pribadi Cloud DNS zona tidak terpengaruh saat pemadaman layanan global terjadi. Setiap pemadaman layanan zona Google Cloud hanya memengaruhi zona Google Cloud dan zona Cloud DNS tertentu dalam zona Google Cloud tersebut. Perhatikan bahwa resource apa pun yang dibuat di layanan zonal hanya dapat dilihat oleh zona Google Cloud tersebut.
Untuk mempelajari cara mengonfigurasi zona cakupan cluster Cloud DNS zonal, lihat Mengonfigurasi zona cakupan cluster GKE zonal.
Dukungan Cloud DNS zona
Tabel berikut mencantumkan resource dan fitur Cloud DNS yang didukung oleh layanan Cloud DNS zonal.
Resource atau fitur | Tersedia di Cloud DNS global | Tersedia di Cloud DNS zonal |
---|---|---|
Zona publik terkelola | ||
Zona pribadi terkelola (cakupan jaringan atau VPC) | ||
Zona pribadi terkelola (cakupan GKE) | ||
Zona penerusan1 | ||
Zona peering | ||
Zona pencarian balik yang dikelola | ||
Membuat perubahan atau mengelola data2 | ||
Zona Direktori Layanan | ||
Kebijakan | ||
Kebijakan respons (cakupan jaringan) | ||
Kebijakan respons (cakupan cluster GKE) | ||
Aturan kebijakan respons |
1Cloud DNS Zonal hanya mendukung zona penerusan yang dicakup dalam cluster GKE.
2Pengontrol GKE menimpa perubahan apa pun pada data saat dimulai ulang.
Penagihan untuk zona Cloud DNS zonal
Penagihan untuk zona Cloud DNS zonal dan kebijakan respons berfungsi dengan cara yang sama seperti kebijakan global.
Langkah selanjutnya
- Untuk menggunakan 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.