Ringkasan Cloud DNS

Halaman ini memberikan ringkasan fitur dan kapabilitas Cloud DNS. Cloud DNS adalah layanan Domain Name System (DNS) global berperforma tinggi dan tangguh yang memublikasikan nama domain Anda ke DNSglobal dengan cara yang hemat biaya. DNS

DNS adalah database terdistribusi hierarkis yang memungkinkan Anda menyimpan alamat IP dan data lainnya serta mencarinya berdasarkan nama. Dengan Cloud DNS, Anda dapat memublikasikan zona dan data Anda di DNS tanpa harus mengelola server dan software DNS Anda sendiri.

Cloud DNS menawarkan zona publik dan zona DNS terkelola pribadi. Zona publik dapat dilihat oleh internet publik, sedangkan zona pribadi hanya dapat dilihat dari satu atau beberapa jaringan Virtual Private Cloud (VPC) yang Anda tentukan. Untuk mengetahui informasi mendetail tentang zona, lihat Ringkasan zona DNS.

Cloud DNS mendukung izin Identity and Access Management (IAM) di level project dan level zona DNS individual. Untuk mengetahui informasi tentang cara menetapkan izin IAM resource individual, lihat Membuat zona dengan izin IAM tertentu.

Untuk mengetahui daftar terminologi DNS umum, lihat Ringkasan DNS umum.

Untuk mengetahui daftar terminologi utama yang menjadi dasar Cloud DNS, lihat Istilah-istilah penting.

Untuk mulai menggunakan Cloud DNS, lihat Panduan memulai.

Coba sendiri

Jika Anda baru pertama kali menggunakan Google Cloud, buat akun untuk mengevaluasi performa Cloud DNS dalam skenario dunia nyata. Pelanggan baru juga akan mendapatkan kredit gratis senilai $300 untuk menjalankan, menguji, dan men-deploy workload.

Coba Cloud DNS gratis

Pertimbangan VPC Bersama

Untuk menggunakan zona pribadi yang dikelola Cloud DNS, zona penerusan Cloud DNS, atau zona peering Cloud DNS dengan VPC Bersama, Anda harus membuat zona di project host, lalu menambahkan satu atau beberapa jaringan VPC Bersama ke daftar jaringan yang diotorisasi untuk zona tersebut. Atau, Anda dapat menyiapkan zona di project layanan menggunakan binding lintas project.

Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk zona pribadi Cloud DNS.

Metode penerusan DNS

Google Cloud menawarkan penerusan DNS masuk dan keluar untuk zona pribadi. Anda dapat mengonfigurasi penerusan DNS dengan membuat zona penerusan atau kebijakan server Cloud DNS. Kedua metode tersebut diringkas dalam tabel berikut.

Penerusan DNS Metode Cloud DNS
Masuk

Buat kebijakan server masuk untuk mengaktifkan klien atau server DNS lokal mengirim permintaan DNS ke Cloud DNS. Klien atau server DNS kemudian dapat me-resolve data sesuai dengan urutan resolusi nama jaringan VPC.

Klien lokal dapat me-resolve data di zona pribadi, zona penerusan, dan zona peering yang telah diberi otorisasi untuk jaringan VPC. Klien lokal menggunakan Cloud VPN atau Cloud Interconnect untuk terhubung ke jaringan VPC.

Keluar

Anda dapat mengonfigurasi VM di jaringan VPC untuk melakukan hal berikut:

  • Mengirim permintaan DNS ke server nama DNS pilihan Anda. Server nama dapat berada di jaringan VPC yang sama, di jaringan lokal, atau di internet.
  • Resolve data yang dihosting di server nama yang dikonfigurasi sebagai target penerusan zona penerusan yang diotorisasi untuk digunakan oleh jaringan VPC Anda. Untuk mengetahui informasi tentang cara Google Cloud merutekan traffic ke target penerusan, lihat Target penerusan dan metode perutean.
  • Buat kebijakan server keluar untuk jaringan VPC guna mengirim semua permintaan DNS ke server nama alternatif. Saat menggunakan server nama alternatif, VM di jaringan VPC Anda tidak dapat lagi me-resolve data di zona pribadi Cloud DNS, zona penerusan, zona peering, atau zona DNS internal Compute Engine. Untuk mengetahui detail tambahan, lihat Urutan resolusi nama.

Anda dapat mengonfigurasi penerusan DNS masuk dan keluar secara bersamaan untuk jaringan VPC. Penerusan dua arah memungkinkan VM di jaringan VPC Anda me-resolve data di jaringan lokal atau di jaringan yang dihosting oleh penyedia cloud lain. Jenis penerusan ini juga memungkinkan host di jaringan lokal dapat me-resolve data untuk resourceGoogle Cloud Anda.

Bidang kontrol Cloud DNS menggunakan urutan pemilihan target penerusan untuk memilih target penerusan. Kueri yang diteruskan keluar terkadang dapat menghasilkan error SERVFAIL jika target penerusan tidak dapat dijangkau atau jika target tidak merespons cukup cepat. Untuk mengetahui petunjuk pemecahan masalah, lihat Kueri yang diteruskan keluar menerima error SERVFAIL.

Untuk mengetahui informasi tentang cara menerapkan kebijakan server, lihat Membuat kebijakan server DNS. Untuk mempelajari cara membuat zona penerusan, lihat Membuat zona penerusan.

DNSSEC

Cloud DNS mendukung DNSSEC terkelola, yang melindungi domain Anda dari serangan spoofing dan cache poisoning. Saat Anda menggunakan resolver validasi seperti Google Public DNS, DNSSEC memberikan autentikasi yang kuat (tetapi bukan enkripsi) untuk pencarian domain. Untuk mengetahui informasi selengkapnya tentang DNSSEC, lihat Mengelola konfigurasi DNSSEC.

Deteksi ancaman tingkat lanjut (Pratinjau)

Pantau kueri DNS yang terikat ke internet untuk mendeteksi aktivitas berbahaya menggunakan DNS Armor (Pratinjau), yang didukung oleh Infoblox. Log kueri DNS yang terikat ke internet dianalisis oleh Infoblox untuk mendeteksi pola berbahaya dan tanda-tanda kompromi lainnya, sehingga memberikan visibilitas terhadap ancaman tanpa memengaruhi traffic produksi Anda. Untuk mengetahui informasi selengkapnya tentang deteksi ancaman DNS Armor, lihat Ringkasan deteksi ancaman tingkat lanjut.

DNS64

Anda dapat menghubungkan instance virtual machine (VM) Compute Engine khusus IPv6 ke tujuan IPv4 menggunakan DNS64 Cloud DNS. DNS64 menyediakan alamat IPv6 yang disintesis untuk setiap tujuan IPv4. Cloud DNS membuat alamat yang disintesis dengan menggabungkan Well-Known Prefix (WKP) 64:ff9b::/96 dengan 32 bit alamat IPv4 tujuan.

Siapkan DNS64 dan penafsiran alamat jaringan dengan Public NAT (NAT64) untuk memungkinkan instance VM khusus IPv6 Anda berkomunikasi dengan tujuan IPv4 di internet. Untuk mengonfigurasi NAT64, ikuti petunjuk di bagian Membuat gateway Cloud NAT.

Contoh berikut menunjukkan cara instance VM khusus IPv6 bernama vmipv6 me-resolve nama tujuan khusus IPv4.

  1. Instance VM vmipv6 memulai permintaan DNS untuk me-resolve nama tujuan ke alamat IPv6.

  2. Jika data AAAA (alamat IPv6) ada, Cloud DNS akan menampilkan alamat IPv6, dan instance VM vmipv6 akan menggunakannya untuk terhubung ke tujuan.

  3. Jika data AAAA tidak ada, tetapi Anda mengonfigurasi DNS64, Cloud DNS akan menelusuri data A (alamat IPv4). Jika Cloud DNS menemukan data A, Cloud DNS akan menyintesis data AAAA dengan menambahkan awalan 64:ff9b::/96 ke alamat IPv4.

DNS64 menerjemahkan alamat IPv4 ke alamat IPv6 yang disintesis.
DNS64 menerjemahkan alamat IPv4 ke alamat IPv6 yang disintesis (klik untuk memperbesar).

Misalnya, jika alamat IPv4 adalah 32.34.50.60, hasil alamat IPv6 yang disintesis adalah 64:ff9b::2022:323c, dengan 2022:323c adalah ekuivalen heksadesimal dari alamat IPv4. Awalan 64:ff9b::/96 ditentukan dalam RFC 6052. Cloud DNS menyintesis alamat IPv6 itu meski Anda menghosting data DNS secara lokal, asalkan Anda mengaktifkan penerusan DNS di Cloud DNS.

Anda dapat menggunakan DNS64 dalam skenario berikut:

  • Mematuhi mandat yang mewajibkan peralihan ke alamat IPv6 tanpa mengalokasikan alamat IPv4.
  • Beralih ke infrastruktur alamat khusus IPv6 secara bertahap sambil mempertahankan akses ke infrastruktur IPv4 yang ada.
  • Hindari gangguan pada layanan penting dengan memastikan akses berkelanjutan ke lingkungan dengan alamat IPv4 lama saat transisi Anda ke alamat IPv6.

Untuk mengonfigurasi DNS64 bagi jaringan VPC, ikuti petunjuk di bagian Mengonfigurasi DNS64.

Kontrol akses

Anda dapat mengelola pengguna yang diizinkan untuk membuat perubahan pada data DNS Anda di halaman IAM & Admin di konsolGoogle Cloud . Agar pengguna diberi otorisasi untuk melakukan perubahan, mereka harus memiliki peran DNS Administrator (roles/dns.admin) di bagian Izin pada konsol Google Cloud . Peran DNS Reader (roles/dns.reader) memberikan akses hanya baca ke data Cloud DNS.

Izin ini juga berlaku untuk akun layanan yang mungkin Anda gunakan untuk mengelola layanan DNS.

Untuk melihat izin yang ditetapkan pada peran ini, lihat Peran.

Kontrol akses untuk zona terkelola

Pengguna dengan peran Owner atau peran Editor project (roles/owner atau roles/editor) dapat mengelola atau melihat zona terkelola di project tertentu yang mereka kelola.

Pengguna dengan peran DNS Administrator atau DNS Reader dapat mengelola atau melihat zona terkelola di semua project yang dapat mereka akses.

Project Owner, Project Editor, DNS Administrator, dan DNS Reader dapat melihat daftar zona pribadi yang diterapkan ke jaringan VPC mana pun dalam project saat ini.

Akses izin per resource

Untuk mengonfigurasi kebijakan pada resource DNS seperti zona terkelola, Anda harus memiliki akses Owner ke project yang memiliki resource tersebut. Peran DNS Administrator tidak memiliki izin setIamPolicy. Sebagai project owner, Anda juga dapat membuat peran IAM kustom untuk kebutuhan spesifik. Untuk informasi mendetail, lihat Memahami peran kustom IAM.

Performa dan pengaturan waktu

Cloud DNS menggunakan anycast untuk melayani zona terkelola Anda dari beberapa lokasi di seluruh dunia untuk ketersediaan tinggi. Permintaan akan secara otomatis dirutekan ke lokasi terdekat, sehingga mengurangi latensi dan meningkatkan performa pencarian nama otoritatif untuk pengguna Anda.

Penerapan perubahan

Perubahan diterapkan dalam dua bagian. Pertama, perubahan yang Anda kirim melalui API atau alat command line harus didorong ke server DNS otoritatif Cloud DNS. Kedua, DNS resolver harus mengambil perubahan ini saat cache datanya berakhir.

Nilai time to live (TTL) yang Anda tetapkan untuk data Anda, yang ditentukan dalam detik, mengontrol cache DNS resolver. Misalnya, jika Anda menetapkan nilai TTL 86.400 (jumlah detik dalam 24 jam), DNS resolver akan diinstruksikan untuk meng-cache data selama 24 jam. Beberapa DNS resolver mengabaikan nilai TTL atau menggunakan nilai mereka sendiri, yang dapat menunda penerapan data secara penuh.

Jika Anda merencanakan perubahan pada layanan yang memerlukan jangka waktu singkat, Anda mungkin ingin mengubah TTL ke nilai yang lebih singkat sebelum melakukan perubahan—nilai TTL baru yang lebih singkat diterapkan setelah nilai TTL sebelumnya berakhir di cache resolver. Cara ini dapat membantu mempersingkat periode caching dan memastikan perubahan yang lebih cepat pada setelan data baru Anda. Setelah perubahan, Anda dapat mengubah nilai kembali ke nilai TTL sebelumnya untuk mengurangi beban pada DNS resolver.

Langkah berikutnya