Ringkasan zona DNS

Cloud DNS mendukung berbagai jenis zona publik dan pribadi. Dokumen ini berisi 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 khusus. 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. Alih-alih membuat data dalam zona, Anda akan menentukan serangkaian target penerusan. Tiap target penerusan adalah nama domain yang sepenuhnya memenuhi syarat (FQDN) atau alamat IP server DNS, yang berada di jaringan VPC Anda, atau di jaringan lokal yang terhubung ke jaringan VPC Anda melalui Cloud VPN atau Cloud Interconnect.

Target penerusan dan metode pemilihan rute

Cloud DNS mendukung empat jenis target dan menawarkan metode pemilihan rute standar atau pribadi untuk konektivitas.

Target penerusan	Deskripsi	Dukungan pemilihan rute standar	Dukungan pemilihan rute pribadi	Sumber permintaan
Jenis 1	Alamat IP internal dari Google Cloud VM atau Load Balancer Jaringan passthrough internal di jaringan VPC yang sama yang diizinkan untuk menggunakan zona penerusan.	Hanya alamat IP RFC 1918—traffic akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi.	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 untuk alamat IP target penerusan yang dilarang —traffic akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi.	`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 akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi.	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 untuk alamat IP target penerusan yang dilarang — traffic akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi.	`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 akan 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
Jenis 4	Nama domain yang sepenuhnya memenuhi syarat dari server nama target yang dapat di-resolve ke alamat IPv4 dan IPv6 melalui urutan resolusi jaringan VPC.	Bergantung pada jaringan target penerusan yang di-resolve, traffic akan dirutekan dengan salah satu dari dua cara: Alamat IP RFC 1918—traffic akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi. Alamat IP eksternal yang dapat dirutekan melalui internet—traffic akan selalu dirutekan ke internet atau ke alamat IP eksternal Google Cloud resource.	Bergantung pada jaringan target penerusan yang di-resolve, traffic akan dirutekan melalui 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 untuk alamat IP target penerusan yang dilarang—traffic akan selalu dirutekan melalui jaringan VPC yang diberi otorisasi. Jika server nama DNS di-resolve ke alamat IP eksternal yang dapat diakses oleh internet atau alamat IP eksternal, pemilihan rute pribadi tidak didukung.	35.199.192.0/19 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 diberi otorisasi atau melalui internet berdasarkan apakah target penerusan adalah alamat IP RFC 1918 atau bukan. 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 diberi otorisasi. Jika target bukan alamat IP RFC 1918, Cloud DNS akan mengklasifikasikan target sebagai Jenis 3, dan mengharapkan target dapat diakses melalui internet.
Pemilihan rute pribadi: Selalu merutekan traffic melalui jaringan VPC yang diberi otorisasi, terlepas dari alamat IP target (RFC 1918 atau bukan). Oleh sebab itu, hanya target Jenis 1 dan Jenis 2 yang didukung.

Jika Anda menggunakan FQDN untuk target penerusan, metode pemilihan rute Anda harus sesuai dengan jenis jaringan Anda. Jika server nama domain Anda me-resolve ke alamat IP publik, Anda harus menggunakan pemilihan rute standar.

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

Untuk mengirim traffic ke target Jenis 1, Cloud DNS akan menggunakan rute subnet yang dibuat secara otomatis. Untuk membalas, target Jenis 1 akan 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 akan menggunakan rute di jaringan lokal Anda.

Untuk mengetahui panduan tambahan tentang persyaratan jaringan untuk target Jenis 1 dan Jenis 2, baca persyaratan jaringan target penerusan.

Untuk mengakses target penerusan Jenis 4, Cloud DNS akan terlebih dahulu me-resolve nama domain, lalu menggunakan metode pemilihan rute jaringan sumber. Misalnya, jika subdomain.example.com me-resolve ke alamat IP sistem lokal yang terhubung ke jaringan VPC yang diberi otorisasi untuk mengkueri zona penerusan melalui Cloud VPN, alamat tersebut akan menggunakan aturan pemilihan rute yang sama dengan target penerusan Jenis 2.

Saat menggunakan FQDN sebagai target penerusan, Anda hanya dapat menggunakan satu FQDN. Target penerusan dapat me-resolve hingga 50 alamat IP.

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 dapat Anda gunakan utnuk mengonfigurasi daftar target penerusan untuk zona penerusan.

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

Saat Anda menggunakan FQDN sebagai target penerusan, Cloud DNS akan me-resolve nama domain menjadi hingga 50 alamat IP, lalu menerapkan algoritma yang sama ke alamat IP tersebut.

Untuk memproses permintaan, Cloud DNS pertama-tama akan 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 target penerusan yang merespons, 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 round-trip) untuk berkomunikasi dengan target penerusan.

Menggunakan zona penerusan

VM dalam 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 kepada beberapa jaringan VPC dalam project yang sama atau di berbagai project, selama jaringan VPC berada dalam organisasi yang sama.
Sistem operasi tamu tiap VM di jaringan VPC menggunakan server metadata VM 169.254.169.254 sebagai server namanya.

Jika Anda menggunakan FQDN sebagai server nama target, tinjau item berikut:

Anda hanya dapat memiliki satu target penerusan.
Resolusi target FQDN melalui zona penerusan lain tidak didukung.
Anda tidak dapat menggunakan FQDN sebagai server nama alternatif dalam kebijakan server.
Target FQDN dapat me-resolve ke hingga 50 alamat IP terkait. Alamat yang di-resolve lebih dari 50 akan dipotong.

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 me-resolve data sesuai dengan urutan resolusi nama, menggunakan zona dengan akhiran terpanjang. Untuk mengetahui informasi selengkapnya, baca bagian Zona yang tumpang-tindih.

Zona caching 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 jangka waktu yang lebih singkat di antara jangka waktu berikut:

60 detik
Durasi time to live (TTL) 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 tiap data.

Kapan harus menggunakan peering

Cloud DNS tidak dapat menggunakan pemilihan rute 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 bernama vpc-net-a.
Anda telah menggunakan Peering Jaringan VPC untuk menghubungkan jaringan VPC vpc-net-a dengan 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 memberi otorisasi pada vpc-net-b untuk menggunakan zona penerusan tersebut.

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

Buat kueri server metadata VM 169.254.169.254 untuk mendapatkan data yang ditentukan di zona penerusan. Kueri ini gagal (seperti yang diperkirakan) karena Cloud DNS tidak mendukung pemilihan rute transitif ke target penerusan. Untuk menggunakan zona penerusan, VM harus dikonfigurasi untuk menggunakan server metadatanya.
Buat kueri target penerusan secara 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 tidak valid ini:

Buat zona peering Cloud DNS yang diberi otorisasi untuk vpc-net-b yang menarget vpc-net-a.
Buat zona penerusan yang diberi otorisasi 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, baca bagian Membuat zona penerusan.

Zona peering

Zona peering adalah zona pribadi Cloud DNS yang dapat Anda gunakan untuk 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. Pencarian data di namespace zona peering mengikuti urutan resolusi nama jaringan produsen DNS.

Oleh sebab 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 terkelola Cloud DNS yang diberi otorisasi untuk digunakan oleh jaringan produsen DNS.
Zona penerusan terkelola Cloud DNS yang diberi otorisasi 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.

Dengan peering DNS, Anda dapat membuat satu jaringan (jaringan konsumen DNS) meneruskan permintaan DNS ke jaringan lain (jaringan produsen DNS), yang kemudian akan melakukan pencarian DNS.

Batasan dan poin penting peering DNS

Perhatikan hal-hal berikut saat mengonfigurasi peering DNS:

Peering DNS adalah hubungan satu arah. Hal ini memungkinkan resource Google Cloud di jaringan konsumen DNS 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 secara 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, maksimal ada tiga jaringan VPC (dengan jaringan di tengah sebagai hop transitif) yang dapat disertakan. Misalnya, Anda dapat membuat zona peering di vpc-net-a yang menarget vpc-net-b, dan kemudian membuat zona peering di vpc-net-b yang menarget vpc-net-c.
Jika Anda menggunakan peering DNS untuk menarget zona penerusan saat perutean dinamis global dinonaktifkan di jaringan VPC produsen, 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, baca bagian Penerusan kueri dari VM di jaringan VPC konsumen ke jaringan VPC produsen tidak berfungsi.

Untuk mengetahui petunjuk tentang cara membuat zona peering, baca bagian 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 minimal 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., ... sampai dengan 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 oleh DNS internal secara otomatis. Hal ini terjadi 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

Dalam contoh ini, data PTR di zona pribadi Cloud DNS Anda untuk in-addr.arpa. diabaikan. Semua kueri PTR untuk 1.1.1.10.in-addr.arpa. akan dijawab oleh zona DNS internal 10.in-addr.arpa. yang lebih spesifik.

Untuk mengganti data PTR DNS internal yang dibuat otomatis untuk VM, pastikan Anda membuat data PTR kustom di zona pribadi yang minimal 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 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 yang dibuat otomatis untuk VM dengan alamat IP dalam rentang alamat 10.5.0.0/16.

Untuk mengetahui petunjuk tentang cara membuat zona pencarian balik terkelola, baca bagian Membuat zona pencarian balik terkelola.

Zona yang tumpang tindih

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

Zona untuk gcp.example.com dan zona lain untuk gcp.example.com akan tumpang tindih karena nama domainnya identik.
Zona untuk dev.gcp.example.com dan zona untuk gcp.example.com akan 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 tumpang tindih dengan satu sama lain. Misalnya, dua jaringan VPC dapat masing-masing memiliki VM database bernama database.gcp.example.com di zona gcp.example.com. Kueri untuk database.gcp.example.com akan menerima jawaban yang berbeda-beda sesuai dengan data zona yang ditentukan di zona yang diberi otorisasi untuk tiap jaringan VPC.
Dua zona pribadi yang telah diberi otorisasi agar dapat diakses dari jaringan VPC yang sama tidak dapat memiliki domain asal yang identik kecuali jika salah satu zona adalah subdomain dari zona lainnya. Server metadata menggunakan pencocokan akhiran terpanjang untuk menentukan domain asal yang akan dikueri untuk mendapatkan data dalam zona tertentu.

Contoh resolusi kueri

Google Cloud akan me-resolve zona Cloud DNS seperti yang dijelaskan dalam Urutan resolusi nama. Saat menentukan zona yang akan dikueri untuk data tertentu, Cloud DNS akan 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 akan terlebih dahulu mencoba menemukan data dalam zona pribadi (atau zona penerusan atau zona peering) yang diberi otorisasi untuk jaringan VPC Anda sebelum mencari data dalam zona publik. Contoh berikut mengilustrasikan urutan yang digunakan server metadata saat mengkueri data DNS. Untuk tiap contoh ini, misalkan Anda telah membuat dua zona pribadi, gcp.example.com dan dev.gcp.example.com, serta memberikan otorisasi akses ke zona tersebut dari jaringan VPC yang sama. Google Cloud akan 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 untuk example.com yang telah diberi otorisasi untuk jaringan VPC. Gunakan dig dari VM Compute Engine untuk mengkueri server nama default VM:
```
dig myapp.example.com.
```
Untuk mengetahui detailnya, baca bagian Membuat kueri untuk nama DNS menggunakan server metadata.
Server metadata me-resolve data myapp.gcp.example.com menggunakan zona pribadi yang diberi otorisasi gcp.example.com karena gcp.example.com adalah akhiran umum terpanjang antara nama data yang diminta dan zona pribadi yang diberi otorisasi yang tersedia. NXDOMAIN akan 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 akan di-resolve sesuai dengan data di zona pribadi yang diberi otorisasi dev.gcp.example.com. NXDOMAIN akan 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 lain.
Kueri untuk myapp.prod.gcp.example.com akan 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 split horizon

Anda dapat menggunakan kombinasi zona publik dan pribadi dalam konfigurasi DNS split horizon. Zona pribadi dapat Anda gunakan untuk menentukan respons yang berbeda terhadap kueri untuk data yang sama saat kueri berasal dari VM dalam jaringan VPC yang diberi otorisasi. DNS split horizon berguna tiap kali Anda perlu memberikan data yang berbeda untuk kueri DNS yang sama, bergantung pada jaringan VPC asal.

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 memberi otorisasi pada jaringan VPC Anda untuk mengakses zona ini.

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

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

Di zona publik, Anda telah membuat dua data.

Kumpulan data	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 akan di-resolve seperti yang dijelaskan:

Kueri untuk myrecord1.gcp.example.com dari VM di jaringan VPC Anda akan 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 akan menampilkan error NXDOMAIN karena tidak ada data untuk myrecord2.gcp.example.com di zona pribadi gcp.example.com.
Kueri untuk myrecord2.gcp.example.com dari internet akan menampilkan 104.198.7.145.

Binding lintas project

Binding lintas project dapat Anda gunakan untuk mempertahankan kepemilikan namespace DNS project layanan secara terpisah dari kepemilikan namespace DNS seluruh jaringan VPC.

Penyiapan VPC Bersama yang umum memiliki project layanan yang mengambil kepemilikan aplikasi atau layanan virtual machine (VM), sedangkan project host mengambil kepemilikan jaringan VPC dan infrastruktur jaringan. Biasanya, namespace DNS dibuat dari namespace jaringan VPC untuk mencocokkan resource project layanan. Untuk penyiapan seperti itu, akan lebih mudah untuk mendelegasikan administrasi namespace DNS tiap project layanan kepada administrator tiap project layanan (yang sering kali 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 umum dengan peering DNS.

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

Gambar berikut menunjukkan penyiapan menggunakan binding lintas project. Cloud DNS memungkinkan tiap project layanan membuat dan memiliki zona DNS-nya sendiri, tetapi tetap terikat ke jaringan bersama yang dimiliki project host. Dengan demikian, akan ada otonomi yang lebih baik dan batas izin yang lebih akurat untuk administrasi zona DNS.

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

Binding lintas project menyediakan hal-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. Tiap VM di jaringan VPC Bersama dapat me-resolve zona terkait.
Tidak ada batas hop transitif. Anda dapat mengelolanya dalam desain hub dan spoke.

Untuk mengetahui petunjuk tentang cara membuat zona dengan binding lintas project yang diaktifkan, baca bagian Membuat zona binding lintas project.

Zona Cloud DNS zonal

Cloud DNS zonal memungkinkan Anda membuat zona DNS pribadi yang dicakup ke sebuah zona Google Cloud saja. 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 mengekspos layanan Anda ke pemadaman layanan global. Cloud DNS Zonal adalah layanan Cloud DNS pribadi baru yang ada dalam tiap zona Google Cloud . Domain gagal terdapat dalam zona Google Cloud tersebut. Zona pribadi Cloud DNS zonal tidak terpengaruh saat terjadi pemadaman layanan global. Tiap Google Cloud pemadaman layanan zonal hanya akan memengaruhi zona Google Cloud tertentu dan zona Cloud DNS dalam zona Google Cloud tersebut. Perhatikan bahwa tiap resource yang dibuat di layanan zonal hanya dapat dilihat oleh zona Google Cloud tersebut.

Untuk mempelajari cara mengonfigurasi zona cakupan cluster Cloud DNS zona, baca bagian Mengonfigurasi zona cakupan cluster GKE zonal.

Dukungan Cloud DNS zonal

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 penerusan¹
Zona peering
Zona pencarian balik yang dikelola
Membuat perubahan atau mengelola data²
Zona Direktori Layanan
Kebijakan
Kebijakan respons (cakupan jaringan)
Kebijakan respons (cakupan cluster GKE)
Aturan kebijakan respons

¹Cloud DNS zonal hanya mendukung zona penerusan yang tercakup dalam cluster GKE.

²Pengontrol GKE akan menimpa tiap perubahan pada data saat dimulai ulang.

Penagihan untuk zona Cloud DNS zonal

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

Langkah berikutnya

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.