Praktik terbaik untuk Amazon Route 53 DNS

Ikuti praktik terbaik ini 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 perutean Pengontrol Pemulihan Aplikasi Amazon Route 53 didistribusikan secara global, dan dirancang untuk ketersediaan dan fungsionalitas 100%, bahkan selama kejadian parah. Mereka berintegrasi satu sama lain dan tidak bergantung pada fungsionalitas bidang kontrol. Sementara pesawat 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, kami menyarankan Anda menggunakan fitur seperti pemeriksaan kesehatan Route 53 dan kontrol perutean Route 53 ARC yang mengandalkan fungsionalitas pesawat 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 oleh DNS resolver untuk memutuskan berapa lama record 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 trade-off antara latensi dan keandalan, dan responsif terhadap perubahan. Dengan TTL yang lebih pendek pada catatan, penyelesai DNS melihat pembaruan ke rekaman lebih cepat karena mereka harus lebih sering melakukan kueri. Ini meningkatkan volume kueri (dan biaya). Saat Anda memperpanjang TTL, penyelesai DNS menjawab pertanyaan 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 diterapkan. 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-an) 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.

• Ketika Anda ingin membuat perubahan pada entri DNS penting, kami sarankan Anda untuk sementara mempersingkat TTL. Kemudian Anda dapat melakukan 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 penyelesai DNS menyelesaikan domain-1.example.com dan menemukan CNAME menunjuk ke, penyelesai DNS harus melanjutkan untuk menyelesaikan sebelum dapat merespons. domain-2.example.com domain-2.example.com Catatan ini berguna dalam banyak situasi, misalnya, untuk memastikan konsistensi ketika situs web memiliki lebih dari satu nama domain.

Namun, penyelesai DNS harus membuat lebih banyak pertanyaan untuk menjawab CNames, yang meningkatkan latensi dan biaya. Jika memungkinkan, alternatif yang lebih cepat dan lebih murah adalah dengan 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 host yang sama.

Untuk informasi selengkapnya, lihat Merutekan lalu lintas internet ke sumber daya Anda AWS.

Perutean DNS tingkat lanjut

• Saat menggunakan geolokasi, geoproximity, atau perutean berbasis latensi, selalu tetapkan default, kecuali jika Anda ingin beberapa klien tidak menerima tanggapan jawaban.

• Untuk meminimalkan latensi aplikasi, gunakan perutean berbasis latensi. Jenis data routing ini dapat sering berubah.

• Untuk memberikan stabilitas dan prediktabilitas perutean, gunakan perutean geolokasi atau geoproximity.

Lihat informasi selengkapnya di Perutean geolokasi, Perutean geoproximity, dan Perutean berbasis latensi.

Propagasi perubahan DNS

Saat Anda membuat atau memperbarui rekaman atau zona yang dihosting dengan menggunakan konsol atau API Route 53, perubahan akan tercermin di internet. Ini disebut propagasi 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 sedang membangun alur kerja penyediaan otomatis, dan penting untuk menunggu propagasi perubahan selesai sebelum Anda melanjutkan dengan langkah alur kerja berikutnya, gunakan GetChangeAPI untuk memverifikasi bahwa perubahan DNS Anda telah berlaku (). Status =INSYNC

Delegasi DNS

Saat Anda mendelegasikan beberapa level 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-nenek 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 respons tunggal yang besar. Jika respons lebih besar dari 512 byte, banyak penyelesai DNS harus mencoba lagi melalui TCP alih-alih UDP, yang dapat mengurangi keandalan dan menyebabkan respons yang lebih lambat. Sebaiknya gunakan routing 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 Balas DNS.