Istilah utama

Dokumen ini menyediakan terminologi utama yang berlaku untuk Cloud DNS. Tinjau istilah-istilah berikut agar lebih memahami cara kerja Cloud DNS dan konsep yang digunakan untuk membuatnya.

Cloud DNS API dibuat berdasarkan project, zona terkelola, set data, dan perubahan pada set data.

project
Project konsol Google Cloud adalah penampung untuk resource, domain untuk kontrol akses, dan tempat penagihan dikonfigurasi dan digabungkan. Untuk mengetahui detail selengkapnya, lihat Membuat dan mengelola project.
zona terkelola

Zona terkelola menyimpan data Domain Name System (DNS) untuk akhiran nama DNS yang sama (seperti example.com). Project dapat memiliki beberapa zona terkelola, tetapi masing-masing harus memiliki nama unik. Di Cloud DNS, zona terkelola adalah resource yang membuat model zona DNS.

Semua data dalam zona terkelola dihosting di server nama yang sama yang dioperasikan oleh Google. Server nama ini merespons kueri DNS terhadap zona terkelola Anda sesuai dengan cara Anda mengonfigurasi zona. Project dapat berisi beberapa zona terkelola. Biaya akan diakumulasikan untuk setiap zona selama setiap hari zona terkelola ada. Zona terkelola mendukung label yang dapat Anda gunakan untuk membantu mengatur penagihan.

zona publik

Zona publik dapat dilihat di internet. Cloud DNS memiliki server nama otoritatif publik yang merespons kueri tentang zona publik, terlepas dari asal kueri tersebut. Anda dapat membuat data DNS di zona publik untuk memublikasikan layanan di internet. Misalnya, Anda dapat membuat catatan berikut di zona publik example.com untuk situs publik www.example.com.

Nama DNS Jenis TTL (detik) Data
www.example.com A 300 198.51.100.0

Cloud DNS menetapkan kumpulan server nama saat zona publik dibuat. Agar data DNS di zona publik dapat di-resolve melalui internet, Anda harus memperbarui setelan server nama pendaftaran domain di registrar.

Untuk informasi selengkapnya tentang cara mendaftarkan dan menyiapkan domain, lihat Menyiapkan domain menggunakan Cloud DNS.

zona pribadi

Zona pribadi memungkinkan Anda mengelola nama domain kustom untuk instance virtual machine (VM), load balancer, dan resource Google Cloud lainnya tanpa mengekspos data DNS yang mendasarinya ke internet publik. Zona pribadi adalah penampung data DNS yang hanya dapat dikueri oleh satu atau beberapa jaringan Virtual Private Cloud (VPC) yang Anda izinkan.

Anda harus menentukan daftar jaringan VPC resmi yang dapat membuat kueri zona pribadi saat membuat atau memperbaruinya. Hanya jaringan resmi yang diizinkan untuk membuat kueri zona pribadi Anda; jika tidak menentukan jaringan resmi, Anda tidak dapat membuat kueri zona pribadi sama sekali.

Anda dapat menggunakan zona pribadi dengan VPC Bersama. Untuk informasi penting tentang penggunaan zona pribadi dengan VPC Bersama, lihat Pertimbangan VPC Bersama.

Zona pribadi tidak mendukung ekstensi keamanan DNS (DNSSEC) atau kumpulan data resource kustom berjenis NS. Permintaan untuk data DNS di zona pribadi harus dikirim melalui server metadata 169.254.169.254, yang merupakan server nama internal default untuk VM yang dibuat dari image yang disediakan Google.

Anda dapat mengirimkan kueri ke server nama ini dari VM apa pun yang menggunakan jaringan VPC resmi. Misalnya, Anda dapat membuat zona pribadi untuk dev.gcp.example.com guna menghosting data DNS internal untuk aplikasi eksperimental. Tabel berikut menunjukkan contoh data di zona tersebut. Klien database dapat terhubung ke server database db-01.dev.gcp.example.com menggunakan nama DNS internalnya, bukan alamat IP-nya. Klien database me-resolve nama DNS internal ini menggunakan resolver host di VM, yang mengirimkan kueri DNS ke server metadata 169.254.169.254. Server metadata bertindak sebagai resolver rekursif untuk membuat kueri zona pribadi Anda.

Nama DNS Jenis TTL (detik) Data
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10

Zona pribadi memungkinkan Anda membuat konfigurasi DNS split horizon. Hal ini karena Anda dapat membuat zona pribadi dengan kumpulan data yang berbeda, yang akan mengganti seluruh kumpulan data di zona publik. Kemudian, Anda dapat mengontrol jaringan VPC mana yang mengkueri data di zona pribadi. Misalnya, lihat zona yang tumpang-tindih.

Direktori Layanan

Direktori Layanan adalah registry layanan terkelola untuk Google Cloud yang memungkinkan Anda mendaftarkan dan menemukan layanan menggunakan HTTP atau gRPC (menggunakan Lookup API) selain menggunakan DNS tradisional. Anda dapat menggunakan Direktori Layanan untuk mendaftarkan layanan Google Cloud dan non-Google Cloud.

Cloud DNS memungkinkan Anda membuat zona yang didukung Direktori Layanan, yang merupakan jenis zona pribadi yang berisi informasi tentang layanan dan endpoint Anda. Anda tidak menambahkan set data ke zona; melainkan, set data disimpulkan secara otomatis berdasarkan konfigurasi namespace Direktori Layanan yang terkait dengan zona. Untuk informasi selengkapnya tentang Direktori Layanan, lihat ringkasan Direktori Layanan.

Saat membuat zona yang didukung Direktori Layanan, Anda tidak dapat menambahkan data ke zona secara langsung; data berasal dari registry layanan Direktori Layanan.

Cloud DNS dan pencarian balik untuk alamat non-RFC 1918

Setelah mengonfigurasi jaringan VPC untuk menggunakan alamat non-RFC 1918, Anda harus mengonfigurasi zona pribadi Cloud DNS sebagai zona pencarian balik terkelola. Konfigurasi ini memungkinkan Cloud DNS me-resolve alamat non-RFC 1918 secara lokal, bukan mengirimkannya melalui internet.

Saat membuat zona DNS pencarian terbalik terkelola, Anda tidak dapat menambahkan data ke zona secara langsung; data berasal dari data alamat IP Compute Engine.

Cloud DNS juga mendukung penerusan keluar ke alamat non-RFC 1918 dengan merutekan alamat tersebut secara pribadi dalam Google Cloud. Untuk mengaktifkan jenis penerusan keluar ini, Anda harus mengonfigurasi zona penerusan dengan argumen jalur penerusan tertentu. Untuk mengetahui detailnya, lihat Metode pemilihan rute dan target penerusan.

zona penerusan

Zona penerusan adalah jenis zona pribadi terkelola Cloud DNS yang meneruskan permintaan untuk zona tersebut ke alamat IP target penerusannya. Untuk mengetahui informasi selengkapnya, lihat Metode penerusan DNS.

Saat membuat zona penerusan, Anda tidak dapat menambahkan data ke zona penerusan secara langsung; data berasal dari satu atau beberapa server nama target atau resolver yang dikonfigurasi.

zona peering

Zona peering adalah jenis zona pribadi yang dikelola Cloud DNS yang mengikuti urutan resolusi nama jaringan VPC lain. Anda dapat menggunakannya untuk me-resolve nama yang ditentukan di jaringan VPC lain.

Saat membuat zona peering DNS, Anda tidak dapat menambahkan data ke zona secara langsung; data berasal dari jaringan VPC produsen sesuai dengan Urutan resolusi nama.

kebijakan respons

Kebijakan respons adalah konsep zona pribadi Cloud DNS yang berisi aturan, bukan data. Aturan ini dapat digunakan untuk mendapatkan efek yang mirip dengan konsep draf zona kebijakan respons (RPZ) DNS (IETF). Fitur kebijakan respons memungkinkan Anda memperkenalkan aturan yang disesuaikan di server DNS dalam jaringan yang dikonsultasikan oleh resolver DNS selama pencarian. Jika aturan dalam kebijakan respons memengaruhi kueri yang masuk, aturan tersebut akan diproses. Jika tidak, pencarian akan dilanjutkan seperti biasa. Untuk informasi selengkapnya, lihat Mengelola kebijakan dan aturan respons.

Kebijakan respons berbeda dengan RPZ, yang merupakan zona DNS normal dengan data yang diformat secara khusus yang menyebabkan resolver yang kompatibel melakukan hal-hal khusus. Kebijakan respons bukan zona DNS dan dikelola secara terpisah di API.

operasi zona

Setiap perubahan yang Anda buat pada zona terkelola di Cloud DNS akan dicatat dalam koleksi operasi, yang mencantumkan pembaruan zona terkelola (mengubah deskripsi atau status atau konfigurasi DNSSEC). Perubahan pada set data di dalam zona disimpan secara terpisah dalam set data resource, yang akan dijelaskan nanti dalam dokumen ini.

Nama Domain Internasional (IDN)

Nama Domain Internasional (IDN) adalah nama domain internet yang memungkinkan orang di seluruh dunia menggunakan aksara atau alfabet khusus bahasa, seperti Arab, China, Sirilik, Devanagari, Ibrani, atau karakter khusus berbasis alfabet Latin dalam nama domain. Konversi ini diimplementasikan dengan menggunakan Punycode, yang merupakan representasi karakter Unicode yang menggunakan ASCII. Misalnya, representasi IDN dari .ελ adalah .xn--qxam. Beberapa browser, program email, dan aplikasi mungkin mengenalinya dan merendernya sebagai .ελ atas nama Anda. Standar Internationalizing Domain Names in Applications (IDNA) hanya mengizinkan string Unicode yang cukup singkat untuk direpresentasikan sebagai label DNS yang valid. Untuk informasi tentang cara menggunakan IDN dengan Cloud DNS, lihat Membuat zona dengan nama domain yang diinternasionalisasi.

registrar

Registrar nama domain adalah organisasi yang mengelola reservasi nama domain internet. Registrar harus diakreditasi oleh registry domain level teratas generik (gTLD) atau registry domain level teratas kode negara (ccTLD).

DNS internal

Google Cloud membuat nama DNS internal untuk VM secara otomatis, meskipun Anda tidak menggunakan Cloud DNS. Untuk informasi selengkapnya tentang DNS internal, lihat dokumentasi DNS internal.

subzona yang didelegasikan

DNS memungkinkan pemilik zona mendelegasikan subdomain ke server nama yang berbeda menggunakan data NS (server nama). Resolver mengikuti data ini dan mengirim kueri untuk subdomain ke server nama target yang ditentukan dalam delegasi.

kumpulan data resource

Kumpulan data resource adalah kumpulan data DNS dengan label, class, dan jenis yang sama, tetapi dengan data yang berbeda. Kumpulan data resource menyimpan status data DNS saat ini yang membentuk zona terkelola. Anda dapat membaca set data resource, tetapi tidak mengubahnya secara langsung. Sebagai gantinya, Anda mengedit kumpulan data resource di zona terkelola dengan membuat permintaan Change di koleksi perubahan. Anda juga dapat mengedit kumpulan data resource menggunakan ResourceRecordSets API. Kumpulan data resource akan segera mencerminkan semua perubahan Anda. Namun, ada jeda antara saat perubahan dilakukan di API dan waktu perubahan tersebut diterapkan di server DNS otoritatif Anda. Untuk mengetahui informasi tentang cara mengelola data, lihat Menambahkan, mengubah, dan menghapus data.

perubahan kumpulan data resource

Untuk membuat perubahan pada set data resource, kirim permintaan Change atau ResourceRecordSets yang berisi penambahan atau penghapusan. Penambahan dan penghapusan dapat dilakukan secara massal atau dalam satu transaksi atomik, dan berlaku secara bersamaan di setiap server DNS otoritatif.

Misalnya, jika Anda memiliki data A yang terlihat seperti ini:

www  A  203.0.113.1 203.0.113.2

Kemudian, Anda menjalankan perintah yang terlihat seperti ini:

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

Data Anda akan terlihat seperti ini setelah perubahan massal:

www  A  203.0.113.1 203.0.113.3

ADD dan DEL terjadi secara bersamaan.

Format nomor seri SOA

Nomor seri data SOA yang dibuat di zona terkelola Cloud DNS meningkat secara monoton dengan setiap perubahan transaksional pada kumpulan data zona yang dibuat menggunakan perintah gcloud dns record-sets transaction. Namun, Anda bebas mengubah nomor seri catatan SOA secara manual menjadi angka arbitrer, termasuk tanggal berformat ISO 8601 seperti yang direkomendasikan dalam RFC 1912.

Misalnya, dalam data SOA berikut, Anda dapat mengubah nomor serial langsung dari konsol Google Cloud dengan memasukkan nilai yang diinginkan ke kolom ketiga yang dipisahkan spasi dari data:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com.
[serial number] 21600 3600 259200 300`
Kebijakan server DNS

Kebijakan server DNS memungkinkan Anda mengakses layanan resolusi nama yang disediakan oleh Google Cloud di jaringan VPC dengan penerusan masuk, atau menggantikan urutan resolusi nama VPC dengan kebijakan server keluar. Untuk mengetahui informasi selengkapnya, lihat Kebijakan server DNS.

domain, subdomain, dan delegasi

Sebagian besar subdomain hanya berupa data di zona terkelola untuk domain induk. Subdomain yang didelegasikan dengan membuat data NS (server nama) di zona domain induknya juga harus memiliki zonanya sendiri.

Buat zona publik terkelola untuk domain induk di Cloud DNS sebelum membuat zona publik untuk subdomain yang didelegasikan. Lakukan hal ini meskipun Anda menghosting domain induk di layanan DNS lain. Jika Anda memiliki beberapa zona subdomain, tetapi tidak membuat zona induk, mungkin akan sulit untuk membuat zona induk nanti jika Anda memutuskan untuk memindahkannya ke Cloud DNS. Untuk mengetahui informasi selengkapnya, lihat Batas server nama. DNSSEC

Domain Name System Security Extensions (DNSSEC) adalah serangkaian ekstensi Internet Engineering Task Force (IETF) ke DNS yang mengautentikasi respons terhadap pencarian nama domain. DNSSEC tidak memberikan perlindungan privasi untuk pencarian tersebut, tetapi mencegah penyerang memanipulasi atau mencemari respons terhadap permintaan DNS.

Koleksi DNSKEY

Kumpulan DNSKEY menyimpan status data DNSKEY saat ini yang digunakan untuk menandatangani zona terkelola yang mengaktifkan DNSSEC. Anda hanya dapat membaca koleksi ini; semua perubahan pada DNSKEY dilakukan oleh Cloud DNS. Kumpulan DNSKEY memiliki semua informasi yang diperlukan registrar domain untuk mengaktifkan DNSSEC.