DNS TTL yang disarankan


24

Saya tahu ini bisa sangat berbeda berdasarkan situasinya, tetapi untuk hosting situs web tanpa rencana untuk memindahkan server hosting, apakah TTL yang baik untuk ditetapkan pada catatan DNS?

Jawaban:


20

Saya cenderung membiarkannya pada default Slicehost, 86.400 detik (1 hari). Saya menurunkannya menjadi 10 menit ketika saya memiliki kepindahan yang tertunda dan menunggu satu atau dua hari.

sunting: Hari-hari ini (2016) saya cenderung tetap rendah - ~ 5 menit.


Itu perbedaan! Akan bermanfaat jika jawabannya termasuk alasan di balik perubahan ke TTL yang jauh lebih rendah.
Anthony G - keadilan untuk Monica

3
@AnthonyGeoghegan Server modern dapat menangani permintaan yang jauh lebih sering, dan sekarang saya menggunakan server nama yang sangat andal (AWS Route 53) Saya lebih suka memiliki fleksibilitas untuk dapat mengubah DNS saat pemberitahuan sesaat.
ceejayoz

12

Standar (ditulis lama di tahun 1987) menyarankan 86.400 detik (1 hari) sebagai TTL standar minimum.

Adalah penting bahwa TTL diatur ke nilai yang sesuai. TTL adalah waktu (dalam detik) bahwa resolver akan menggunakan data yang didapatnya dari server Anda sebelum meminta server Anda lagi. Jika Anda menetapkan nilai terlalu rendah, server Anda akan dimuat dengan banyak permintaan ulangi. Jika Anda mengaturnya terlalu tinggi, maka informasi yang Anda ubah tidak akan didistribusikan dalam jumlah waktu yang wajar. Jika Anda membiarkan bidang TTL kosong, itu akan default ke apa yang ditentukan dalam catatan SOA untuk zona.

Sebagian besar informasi host tidak banyak berubah selama periode waktu yang lama. Cara yang baik untuk mengatur TTL Anda adalah dengan menetapkannya pada nilai tinggi, dan kemudian turunkan nilainya jika Anda tahu perubahan akan segera terjadi. Anda dapat mengatur sebagian besar TTL ke mana saja antara hari (86400) dan satu minggu (604800). Kemudian, jika Anda tahu beberapa data akan berubah dalam waktu dekat, setel TTL untuk RR tersebut ke nilai yang lebih rendah (satu jam hingga satu hari) hingga perubahan terjadi, lalu pasang kembali ke nilai sebelumnya.

Juga, semua RR dengan nama, kelas, dan jenis yang sama harus memiliki nilai TTL yang sama.

Lihat RFC 1033: http://tools.ietf.org/html/rfc1033

RFC 1912 (dari 1996) menunjukkan bahwa 3 hari mungkin lebih sesuai untuk SOAcatatan.

http://www.ietf.org/rfc/rfc1912.txt


4
Saya membayangkan lalu lintas DNS dari TTL rendah secara signifikan lebih merupakan masalah pada tahun 1987 dan 1996 dari pada tahun 2011/2012.
ceejayoz

6
Kedua standar yang Anda kutip merujuk pada bidang "Minimum" dari catatan SOA saja, yang tidak lagi digunakan untuk menentukan standar atau TTL minimum, seperti yang dimaksudkan ketika standar itu ditulis. Praktik terbaik DNS yang ditulis 27 dan 18 tahun yang lalu ditulis ketika DNS - memang internet - adalah binatang yang berbeda. Saat ini, 300 detik (5 menit) adalah TTL yang cukup umum untuk catatan A / AAAA utama, meskipun hanya berguna ketika membutuhkan failover cepat jika tidak 6 jam + akan lebih tepat. Catatan NS, dan catatan A / AAAA untuk alamat NS, biasanya 1 hari atau lebih.
thomasrutter

6
Saya terlambat mengomentari hal ini, tetapi perlu dicatat bahwa tidak pantas menyebut salah satu RFC tersebut sebagai "standar". ( RFC 1796 ) Saya mencatat ini sehingga pembaca hari ini tidak menjauh dari T&J ini dengan pemahaman yang salah.
Andrew B

7

Saya telah memperhatikan bahwa menjadi lebih modis untuk memiliki TTL yang lebih pendek untuk dapat merespons dalam keadaan darurat (terutama dalam lingkungan HA DNS) lebih cepat.


1
Iya nih. CloudFlare membuat semua TTL pelanggan defaultnya menjadi 300 detik (5 menit) yang sangat pendek, tetapi mereka jelas melihat manfaatnya.
Simon East

3

Saya hanya membiarkannya pada pengaturan default yang ditetapkan oleh host Anda, kecuali jika itu sangat tinggi atau rendah untuk beberapa alasan. Kemudian jika Anda ingin memindahkannya menjadi 20 menit atau lebih beberapa hari sebelum Anda berencana untuk memindahkannya.


2

4 jam seharusnya baik-baik saja, memberikan keseimbangan yang dapat diterima. Itulah yang saya gunakan di sebagian besar zona.


4
Itu mungkin terlalu pendek.
dmourati

5
@dmourati: Ini 2011. Untuk sebagian besar server DNS kecil (yaitu, di bawah 1.000 atau lebih) dan untuk setiap dan semua klien, penambahan beban CPU dan persyaratan bandwidth benar-benar dapat diabaikan. Tentu saja, jika server DNS Anda turun selama lebih dari 4 jam Anda SOL, tetapi jika itu penting dan Anda tidak dapat memberikan layanan DNS yang dapat diandalkan, Anda tidak memiliki bisnis hosting layanan DNS Anda pada fondasi reyot sedemikian rupa di tempat pertama. ..
Mihai Limbăşan

3
Ketika seorang pengguna mengajukan pertanyaan yang dijawab langsung dalam RFC Anda mengarahkan mereka ke RFC terlepas dari tahun berapa itu.
dmourati

@dmourati Apakah ini ditentukan dalam RFC?
Joó Ádám

Ya, lihat jawaban saya di atas.
dmourati


2

(catatan: posting ini berlaku untuk TTL pada catatan indidivual A / AAAA, beberapa tipe catatan lainnya dapat memiliki TTL yang lebih panjang karena mereka tidak mewakili satu titik kegagalan dengan cara yang sama).

Anda benar-benar perlu memikirkan ini dalam hal rencana pemulihan bencana Anda. Ini bukan tentang kapan Anda berniat untuk memindahkan situs (untuk gerakan yang disengaja Anda dapat mengurangi TTL di runup ke bergerak). Ini terjadi ketika host Anda menghilang dari internet atau menendang Anda karena pelanggaran TOS atau menendang Anda keluar karena mereka tidak dapat menangani DDOS yang menghampiri Anda.

Jika Anda tidak peduli tentang situs Anda sedang down selama satu hari atau lebih dalam keadaan itu maka silakan dan biarkan TTL pada default satu hari itu. Jika Anda memiliki ruang alamat PI dan transit BGP di beberapa lokasi dari beberapa penyedia dan berniat untuk menangani pemulihan bencana di tingkat BGP kemudian lanjutkan dan biarkan itu pada standar satu hari. Di sisi lain, jika Anda menggunakan DNS sebagai mekanisme untuk mengalihkan taffic ke situs failover, maka Anda menginginkan TTL yang lebih pendek, 5 minuites adalah nilai yang cukup umum.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.