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 ini untuk mendapatkan hasil terbaik saat menggunakan DNS layanan Amazon Route 53.
- Gunakan fungsi bidang data untuk DNS failover dan pemulihan aplikasi
-
Pesawat data untuk Route 53, termasuk pemeriksaan kesehatan, dan kontrol perutean Amazon Application Recovery Controller (ARC) 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 ARC perutean yang mengandalkan fungsionalitas pesawat data untuk diperbarui. DNS Untuk informasi selengkapnya, lihat Konsep bidang kontrol dan data dan Blog: Membuat Mekanisme Pemulihan Bencana Menggunakan Amazon Route 53
. - Memilih TTL nilai untuk DNS catatan
-
DNSTTLIni adalah nilai numerik (dalam detik) yang digunakan DNS resolver untuk memutuskan berapa lama rekaman dapat di-cache tanpa membuat kueri lain ke Route 53. Semua DNS catatan harus memiliki yang TTL ditentukan untuk mereka. Rentang yang disarankan untuk TTL nilai adalah 60 hingga 172.800 detik.
Pilihan a TTL adalah trade-off antara latensi dan keandalan, dan responsif terhadap perubahan. Dengan catatan yang lebih pendekTTLs, DNS resolver melihat pembaruan ke rekaman lebih cepat karena mereka harus lebih sering melakukan kueri. Ini meningkatkan volume kueri (dan biaya). Saat Anda memperpanjangTTL, DNS resolver 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 saat Anda menetapkan TTL nilai meliputi:
-
Tetapkan DNS rekor TTLs 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, lebih lama TTLs 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), yang lebih rendah TTLs adalah tepat. Pengaturan 60 atau 120 detik adalah pilihan umum untuk skenario ini. TTL
-
Ketika Anda ingin membuat perubahan pada DNS entri kritis, kami sarankan Anda untuk sementara mempersingkat entri. TTLs 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 informasi selengkapnya, lihat TTL (detik).
-
- CNAMEcatatan
-
DNSCNAMECatatan adalah cara untuk mengarahkan satu nama domain ke yang lain. Jika DNS resolver menyelesaikan domain-1.example.com dan menemukan CNAME titik di, resolver harus melanjutkan untuk menyelesaikan sebelum dapat meresponsdomain-2.example.com. DNS domain-2.example.com Catatan ini berguna dalam banyak situasi, misalnya, untuk memastikan konsistensi ketika situs web memiliki lebih dari satu nama domain.
Namun, DNS resolver harus membuat lebih banyak pertanyaan untuk dijawabCNAMEs, 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.
- DNSPerutean lanjutan
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 routing 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.
- DNSubah propagasi
-
Saat Anda membuat atau memperbarui rekaman atau zona yang dihosting dengan menggunakan konsol Route 53 atauAPI, perlu beberapa waktu agar perubahan tersebut 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 GetChangeAPIuntuk memverifikasi bahwa DNS perubahan Anda telah berlaku ().
Status =INSYNC
- DNSdelegasi
-
Saat Anda mendelegasikan beberapa level subdomainDNS, 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 DNS respon
Hindari membuat respons tunggal yang besar. Jika respons lebih besar dari 512 byte, banyak DNS resolver harus mencoba lagi TCP alih-alihUDP, 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 DNSBalas Server Uji Ukuran
.