Ringkasan kebijakan DNS

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

  • Kebijakan server menerapkan konfigurasi DNS pribadi ke jaringan Virtual Private Cloud (VPC) (penerusan DNS, logging).
  • Kebijakan respons akan mengganti respons DNS pribadi berdasarkan nama kueri.
  • Kebijakan pemilihan rute mengarahkan traffic berdasarkan kueri (misalnya, round robin, geolokasi).

Anda dapat menggunakan ketiga kebijakan secara bersamaan bergantung pada kebutuhan.

Kebijakan server

Gunakan kebijakan server untuk menyiapkan deployment hybrid untuk resolusi DNS. Anda dapat menyiapkan kebijakan server masuk tergantung pada arah resolusi DNS. Jika beban kerja Anda berencana menggunakan DNS resolver lokal, Anda dapat menyiapkan zona penerusan DNS menggunakan kebijakan server keluar. Di sisi lain, jika ingin workload lokal Anda me-resolve nama di Google Cloud, Anda dapat menyiapkan kebijakan server masuk.

Untuk mengetahui informasi mendetail tentang kebijakan server, lihat Ringkasan kebijakan server.

Untuk mengonfigurasi dan menerapkan kebijakan server DNS, lihat Menerapkan kebijakan server DNS.

Kebijakan respons

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

Kebijakan respons berbeda dengan RPZ, yang merupakan zona DNS normal dengan data berformat khusus yang menyebabkan resolver yang kompatibel melakukan hal-hal khusus. Kebijakan respons bukan merupakan zona DNS dan dikelola secara terpisah di API. Untuk membuat dan mengubah kebijakan respons di Cloud DNS, gunakan ResponsePolicies API. Kebijakan respons terpisah dari ManagedZones dan tidak dapat dikelola menggunakan ManagedZones API atau RRSet API.

Kebijakan perutean

Kebijakan perutean DNS memungkinkan Anda mengarahkan traffic berdasarkan kriteria tertentu. Cloud DNS juga mendukung health check dan failover otomatis yang disematkan ke setiap kebijakan perutean. Health check tersedia untuk Load Balancer Jaringan passthrough internal dan Load Balancer Aplikasi internal yang mengaktifkan akses global, dan Load Balancer Aplikasi internal lintas region.

Cloud DNS mendukung kebijakan perutean berikut:

  • Kebijakan perutean round robin berbobot
  • Kebijakan pemilihan rute geolokasi
  • Kebijakan pemilihan rute yang dibatasi wilayah
  • Kebijakan perutean failover

Hanya satu jenis kebijakan perutean yang dapat diterapkan ke data resource yang ditetapkan pada satu waktu. Anda tidak dapat menggabungkan kebijakan perutean kecuali saat mengonfigurasi kebijakan perutean failover, yang memungkinkan Anda menetapkan kebijakan perutean geolokasi sebagai cadangan.

Kebijakan pemilihan rute round robin berbobot

Dengan kebijakan perutean round robin (WRR) tertimbang, Anda dapat menentukan bobot yang berbeda per target DNS, dan Cloud DNS memastikan bahwa traffic Anda didistribusikan sesuai dengan bobot. Anda dapat menggunakan kebijakan ini untuk mendukung konfigurasi active-active atau active-passive manual. Anda juga dapat membagi traffic antara software versi produksi dan eksperimental.

Health check tersedia secara default jika targetnya adalah Load Balancer Jaringan passthrough internal. Hal ini akan mengaktifkan failover otomatis saat endpoint gagal melakukan health check. Jika terjadi failover, pemisahan traffic akan otomatis disesuaikan di antara endpoint lain yang responsif. Untuk mengetahui detail selengkapnya, lihat Health check.

Kebijakan perutean geolokasi

Kebijakan perutean geolokasi (GEO) memungkinkan Anda memetakan traffic yang berasal dari geografi sumber (region Google Cloud) ke target DNS tertentu. Gunakan kebijakan ini untuk mendistribusikan permintaan masuk ke berbagai instance layanan berdasarkan asal traffic. Anda dapat menggunakan fitur ini dengan internet, dengan traffic eksternal, atau dengan traffic yang berasal dari Google Cloud dan terikat untuk Load Balancer Jaringan passthrough internal. Cloud DNS menggunakan region tempat kueri masuk ke Google Cloud sebagai geografis sumber.

Health check tersedia secara default jika targetnya adalah Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, atau Load Balancer Aplikasi internal lintas region. Hal ini akan mengaktifkan failover otomatis saat endpoint gagal health check. Dalam kasus geolokasi, traffic akan gagal ke geolokasi berikutnya yang terdekat dengan traffic sumber.

Kebijakan pemilihan rute yang dibatasi wilayah

Health check mengaktifkan jenis kebijakan pemilihan rute pembatasan wilayah tempat Anda dapat membatasi traffic ke geolokasi tertentu meskipun semua endpoint dalam geolokasi tersebut tidak responsif. Dalam kebijakan geolokasi, saat kegagalan health check ditemukan untuk bucket geografis tertentu, traffic akan otomatis gagal ke geolokasi terdekat berikutnya. Saat pembatasan wilayah diaktifkan, failover otomatis tidak akan terjadi. Sebagai server otoritatif, Cloud DNS harus menampilkan nilai, dan dalam skenario ini, Cloud DNS menampilkan semua alamat IP tanpa diubah jika health check gagal.

Kebijakan perutean failover

Kebijakan perutean failover dapat digunakan untuk menyiapkan konfigurasi pencadangan aktif guna menyediakan ketersediaan tinggi untuk resource internal dalam VPC Anda. Anda dapat mengonfigurasi kebijakan perutean failover hanya untuk zona pribadi.

Dalam operasi normal, alamat IP yang disediakan dalam kumpulan active selalu ditampilkan. Jika semua alamat IP dalam set aktif gagal (status responsif berubah menjadi tidak responsif), Cloud DNS akan mulai menyalurkan alamat IP di set cadangan. Anda dapat mengonfigurasi kumpulan cadangan sebagai kebijakan geolokasi, dan kebijakan tersebut berperilaku sama seperti yang dijelaskan di bagian kebijakan geolokasi. Jika dikonfigurasi sebagai Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, atau Load Balancer Aplikasi internal lintas region, semua alamat IP virtual (VIP) cadangan juga akan diperiksa kesehatannya.

Dengan Cloud DNS, Anda dapat secara bertahap memotong traffic ke alamat VIP cadangan sehingga Anda dapat yakin bahwa alamat VIP cadangan berfungsi. Anda dapat mengonfigurasi persentase traffic yang dikirim ke cadangan sebagai pecahan dari 0 hingga 1. Nilai standarnya harus 0,1, meskipun Cloud DNS memungkinkan Anda mengirim 100% traffic ke alamat VIP cadangan, untuk memicu failover secara manual. Health check hanya dapat diterapkan ke load balancer internal. Oleh karena itu, semua alamat VIP yang dikonfigurasi harus berupa Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, atau Load Balancer Aplikasi internal lintas region.

Health check

Cloud DNS mendukung health check untuk Load Balancer Jaringan passthrough internal dan Load Balancer Aplikasi internal yang mengaktifkan akses global, dan Load Balancer Aplikasi internal lintas region.

Health check untuk load balancer pribadi hanya tersedia di zona yang dikelola secara pribadi. Health check tidak tersedia untuk zona pencarian balik, peering, dan terkelola.

Untuk mengetahui informasi mendetail tentang health check untuk load balancer, lihat Ringkasan health check.

Health check untuk Load Balancer Jaringan passthrough internal

Cloud DNS menentukan status respons Load Balancer Jaringan passthrough internal menggunakan konfigurasi health check bawaan load balancer. Cloud DNS menganggap Load Balancer Jaringan passthrough internal responsif dan memenuhi syarat untuk menerima traffic jika minimal 20% health check berhasil.

Untuk Load Balancer Jaringan passthrough internal, Cloud DNS mendapatkan sinyal kondisi langsung dari setiap backend instance dan algoritma nilai minimum diterapkan untuk menentukan apakah endpoint responsif atau tidak.

Satu alamat IP virtual Load Balancer Jaringan passthrough internal dapat memiliki beberapa layanan yang berjalan di belakangnya. Cloud DNS mencari sinyal respons dari protokol dan port yang ditentukan dalam konfigurasi health check untuk load balancer. Untuk mengetahui informasi mendetail tentang health check, lihat Ringkasan health check.

Untuk Load Balancer Aplikasi internal dan Load Balancer Aplikasi internal lintas region, Cloud DNS mempertimbangkan kondisi load balancer itu sendiri selama keputusan perutean. Saat menerima kueri, load balancer mendistribusikan traffic hanya ke layanan backend yang responsif. Untuk memastikan adanya backend yang responsif, Anda dapat mengelola siklus proses backend menggunakan layanan seperti grup instance terkelola (MIG). Cloud DNS tidak perlu mengetahui status respons setiap backend; load balancer menangani tugas ini.

Kebijakan round robin berbobot dan health check

Cloud DNS mendukung bobot dari 0 hingga 1000, termasuk keduanya. Saat health check disertakan, hal berikut akan terjadi:

  • Jika Anda mengonfigurasi beberapa target, semuanya dengan bobot 0, traffic akan didistribusikan secara merata di antara target.
  • Jika Anda mengonfigurasi target berbobot baru bukan nol, target tersebut akan menjadi target utama, dan semua traffic akan beralih ke target tersebut.
  • Seiring Anda menambahkan lebih banyak target dengan bobot bukan nol, Cloud DNS secara dinamis menghitung pembagian traffic di antara target-target (dengan setiap permintaan) dan mendistribusikan traffic dengan tepat. Misalnya, jika Anda telah mengonfigurasi tiga target dengan bobot 0, 25, dan 75, target dengan bobot 0 tidak akan mendapatkan traffic, target dengan bobot 25 mendapatkan seperempat traffic, dan target lainnya mendapatkan tiga perempat dari traffic masuk.
  • Jika health check dikaitkan dengan target berbobot yang bukan nol, tetapi tidak dengan target berbobot nol, target berbobot nol selalu dianggap responsif. Jika semua data bukan nol tidak responsif, Cloud DNS akan menampilkan data berbobot nol.
  • Jika health check dikaitkan dengan catatan berbobot bukan nol dan nol, serta jika semua kumpulan data gagal health check, Cloud DNS akan menampilkan target berbobot bukan nol dan sepenuhnya menghindari target berbobot nol.
  • Saat Cloud DNS memilih bucket bobot untuk ditampilkan ke pemohon (satu item kebijakan), hanya alamat IP dalam bucket bobot tersebut yang ditampilkan. Jika Anda hanya menentukan satu alamat IP dalam bucket weight, hanya alamat IP tersebut yang ada dalam respons. Jika ada lebih dari satu alamat IP di bucket bobot, Cloud DNS akan menampilkan semua alamat IP dalam urutan acak.

Kebijakan geolokasi dengan health check

Untuk kebijakan geolokasi dengan health check yang diaktifkan, hal berikut akan terjadi:

  • Jika geo bucket memiliki beberapa alamat IP yang dikonfigurasi, dan semua alamat IP memiliki health check, hanya alamat IP yang responsif yang ditampilkan.
  • Jika terdapat perpaduan health check dan tidak ada health check, dan semua alamat IP yang memiliki health check gagal, Cloud DNS akan menampilkan semua alamat IP yang tidak memiliki health check yang dikonfigurasi. Dalam skenario ini, failover otomatis ke geografi terdekat berikutnya tidak terjadi.
  • Kebijakan ini akan otomatis mengarahkan traffic ke geo bucket terdekat berikutnya saat:
    • Semua alamat IP di bucket geografis telah mengaktifkan health check.
    • Kebijakan telah menonaktifkan pagar.
    • Semua alamat IP gagal dalam health check. Hal ini memungkinkan Anda melakukan failover otomatis ke target geografis terdekat berikutnya.

Logging health check

Cloud DNS mendukung logging health check dan mencatat status health check setiap perubahan backend ke dalam log. Hal ini memungkinkan Anda melakukan hal berikut:

  • Memvalidasi apakah kebijakan perutean berperforma seperti yang diharapkan. Contoh:
    • Untuk kebijakan GEO, Anda dapat memvalidasi apakah kebijakan tersebut mendeteksi geografis yang tepat dan menampilkan set data RR yang tepat.
    • Untuk kebijakan WRR, Anda dapat memvalidasi apakah kebijakan menampilkan alamat IP dalam bobot yang benar.
  • Mengidentifikasi masalah infrastruktur dengan backend dan alamat IP tertentu yang mengalami kegagalan.
  • Pecahkan masalah alasan backend tertentu tidak pernah disertakan atau backend tertentu yang ditampilkan.

Untuk membuat, mengedit, atau menghapus kebijakan perutean DNS, lihat Mengelola kebijakan perutean dan health check DNS.

Jenis data yang didukung untuk kebijakan perutean DNS

Kebijakan perutean DNS tidak mendukung semua jenis data yang didukung oleh Cloud DNS. Kebijakan {i>routing<i} DNS mendukung jenis data berikut.

Jenis data Deskripsi
A Alamat IPv4
AAAA Alamat IPv6
CNAME Nama kanonis
MX Data pertukaran email
SRV Host/port (RFC 2782)
TXT Data teks