Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Praktik terbaik untuk Amazon Route 53 DNS
Ikuti praktik terbaik berikut untuk mendapatkan hasil terbaik saat menggunakan layanan DNS Amazon Route 53.
- Gunakan fungsi bidang data untuk failover DNS dan pemulihan aplikasi
-
Pesawat data untuk Route 53, termasuk pemeriksaan kesehatan, dan kontrol routing Amazon Application Recovery Controller (ARC) didistribusikan secara global, dan dirancang untuk ketersediaan dan fungsionalitas 100%, bahkan selama peristiwa parah. Mereka berintegrasi satu sama lain dan tidak bergantung pada fungsionalitas bidang kontrol. Sementara bidang kontrol untuk layanan ini, termasuk konsol mereka, umumnya sangat andal, mereka dirancang dengan cara yang lebih terpusat dan memprioritaskan daya tahan dan konsistensi daripada ketersediaan tinggi. Untuk skenario seperti failover selama pemulihan bencana, sebaiknya gunakan fitur seperti pemeriksaan kesehatan Route 53 dan kontrol routing ARC yang bergantung pada fungsionalitas bidang data untuk memperbarui DNS. Untuk informasi selengkapnya, lihat Konsep bidang kontrol dan data dan Blog: Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53
. - Memilih nilai TTL untuk catatan DNS
-
DNS TTL adalah nilai numerik (dalam detik) yang digunakan resolver DNS untuk memutuskan berapa lama catatan dapat di-cache tanpa membuat kueri lain ke Route 53. Semua catatan DNS harus memiliki TTL yang ditentukan untuk mereka. Rentang yang disarankan untuk nilai TTL adalah 60 hingga 172.800 detik.
Pilihan TTL adalah pertukaran antara latensi dan keandalan, dan daya tanggap terhadap perubahan. Dengan TTL yang lebih pendek pada catatan, resolver DNS melihat pembaruan pada catatan lebih cepat karena mereka harus menanyakan lebih sering. Ini meningkatkan volume kueri (dan biaya). Saat Anda memperpanjang TTL, resolver DNS menjawab kueri dari cache lebih sering, yang biasanya lebih cepat, lebih murah, dan dalam beberapa situasi, lebih dapat diandalkan, karena menghindari kueri di internet. Tidak ada nilai yang benar, tetapi ada baiknya untuk memikirkan apakah daya tanggap atau keandalan lebih penting bagi Anda.
Hal-hal yang perlu dipertimbangkan ketika Anda menetapkan nilai TTL meliputi:
-
Tetapkan TTL catatan DNS untuk jangka waktu yang Anda mampu menunggu perubahan berlaku. Hal ini terutama berlaku pada delegasi (set catatan NS), atau catatan lain yang jarang berubah, misalnya catatan MX. Untuk catatan ini, TTL yang lebih panjang direkomendasikan. Nilai antara satu jam (3600 detik) dan satu hari (86.400 detik) adalah pilihan umum.
-
Untuk catatan yang perlu diubah sebagai bagian dari mekanisme failover cepat (terutama catatan yang diperiksa kesehatan), TTL yang lebih rendah sesuai. Mengatur TTL 60 atau 120 detik adalah pilihan umum untuk skenario ini.
-
Bila Anda ingin membuat perubahan pada entri DNS penting, sebaiknya Anda mempersingkat TTL untuk sementara waktu. Kemudian Anda dapat membuat perubahan, mengamati, dan mengembalikan dengan cepat jika perlu. Setelah perubahan diselesaikan dan berfungsi seperti yang diharapkan, Anda dapat meningkatkan TTL.
Untuk mengetahui informasi selengkapnya, lihat TTL (detik).
-
- Catatan CNAME
-
Catatan DNS CNAME adalah cara untuk mengarahkan satu nama domain ke yang lain. Jika resolver DNS menyelesaikan domain-1.example.com dan menemukan CNAME menunjuk kedomain-2.example.com, resolver DNS harus melanjutkan untuk menyelesaikan sebelum dapat merespons. domain-2.example.com Catatan ini berguna dalam banyak situasi, misalnya, untuk memastikan konsistensi ketika situs web memiliki lebih dari satu nama domain.
Namun, resolver DNS harus membuat lebih banyak kueri untuk menjawab CNames, yang meningkatkan latensi dan biaya. Jika memungkinkan, alternatif yang lebih cepat dan lebih murah adalah menggunakan catatan alias Route 53. Catatan alias memungkinkan Route 53 merespons dengan jawaban langsung untuk AWS sumber daya (misalnya, penyeimbang beban) dan untuk domain lain dalam zona yang dihosting yang sama.
Untuk informasi selengkapnya, lihat Merutekan lalu lintas internet ke Anda AWS sumber daya.
- Perutean DNS lanjutan
Saat menggunakan geolokasi, geoproximitas, atau perutean berbasis latensi, selalu tetapkan default, kecuali jika Anda ingin beberapa klien tidak menerima tanggapan jawaban.
Untuk meminimalkan latensi aplikasi, gunakan routing berbasis latensi. Jenis data routing ini dapat sering berubah.
Untuk memberikan stabilitas routing dan prediktabilitas, gunakan geolokasi atau geoproximitas routing.
Lihat informasi selengkapnya di Perutean geolokasi, Perutean geoproksimitas, dan Latency-based perutean.
- Propagasi perubahan DNS
-
Saat Anda membuat atau memperbarui rekaman atau zona yang dihosting dengan menggunakan konsol atau API Route 53, perlu beberapa waktu agar perubahan tersebut tercermin di internet. Ini disebut propag asi perubahan. Sementara propagasi biasanya memakan waktu kurang dari satu menit secara global, kadang-kadang ada penundaan, misalnya, karena masalah sinkronisasi ke satu lokasi, atau dalam kasus yang jarang terjadi, masalah dalam bidang kontrol pusat. Jika Anda membuat alur kerja penyediaan otomatis, dan penting untuk menunggu propagasi perubahan selesai sebelum melanjutkan langkah alur kerja berikutnya, gunakan GetChange API untuk memverifikasi bahwa perubahan DNS Anda telah berlaku (
Status =INSYNC). - Delegasi DNS
-
Ketika Anda mendelegasikan beberapa tingkat subdomain di DNS, penting untuk selalu mendelegasikan dari zona induk. Misalnya, jika Anda mendelegasikanwww.dept.example.com, Anda harus melakukannya dari dept.example.com zona, bukan dari example.com zona. Delegasi dari kakek-nen ek ke zona anak mungkin tidak berfungsi sama sekali atau hanya bekerja secara tidak konsisten. Untuk informasi selengkapnya, lihat Merutekan lalu lintas untuk subdomain.
- Ukuran respons DNS
Hindari membuat tanggapan tunggal yang besar. Jika respons lebih besar dari 512 byte, banyak resolver DNS harus mencoba lagi melalui TCP alih-alih UDP, yang dapat mengurangi keandalan dan menyebabkan respons yang lebih lambat. Sebaiknya gunakan perutean jawaban multivalue, yang memilih delapan alamat IP acak yang sehat untuk menjaga respons dalam batas 512 byte.
Untuk informasi selengkapnya, lihat Perutean jawaban multinilai dan Server Uji Ukuran Balasan DNS
.
