Berapa persentase nameserver yang menghormati TTL hari ini?

29

Beberapa tahun yang lalu saya harus melakukan beberapa perubahan DNS selama beberapa minggu karena saya memindahkan sedikit peralatan dari satu pusat data ke yang lain. Pada saat saya melakukan ini, sekitar 95% dari nameserver di dunia tampaknya menghargai nilai TTL, dan sekitar 5% mengabaikan kita dan mengarangnya sendiri. Dengan kata lain, 95% dari lalu lintas bergerak dalam TTL 15 menit yang kami definisikan. 3% lainnya berhasil di jam pertama, 1% di hari pertama, dan beberapa pejalan kaki membutuhkan waktu hingga tiga hari.

(Ya, oke, saya mengacaukan persentase lalu lintas dengan persentase server nama. Harap masukkan handwaving.)

Ini sekitar tahun 2001, dan kami menggunakan dinosaurus untuk mengirimkan paket melalui tabung. Dugaan saya adalah bahwa nameserver hari ini berperilaku lebih baik, dan akan ada sedikit masalah dengan orang-orang yang tersesat. Apakah ada yang tahu berapa persen lalu lintas akan beralih dalam TTL yang ditentukan hari ini? Apakah masih banyak server nama yang mengabaikan TTL?

domain-name-system nameserver ttl

— pengguna10501
sumber

4

Saya tidak tahu, tetapi firasat saya adalah bahwa hari ini akan lebih buruk di masa lalu.

— Zoredache

Saya ingin sekali semuanya selesai dalam 3 hari! Saya melakukan perubahan besar tentang waktu itu (mungkin 2002), dan setelah dua minggu, kami akhirnya menyadari bahwa 1/3 dari server nama root sedang melihat beberapa server DNS pengembangan yang telah diekspos oleh salah satu sysadmin lain ke dunia luar. (Saya masih tidak tahu bagaimana server root tahu tentang mereka).

— Joe H.

Sesuatu yang perlu dipertimbangkan dalam hal ini adalah: Ini bukan hanya edge recursors DNS yang merekam cache. Kadang-kadang orang membuat rantai reseptor dan ini menambah waktu. Juga, beberapa catatan cache sistem operasi. Beberapa browser juga menyimpan catatan. Java dan aplikasi lain juga melakukan cache DNS. Ini dapat dengan mudah mengubah TTL 15 menit menjadi 60+ menit.

— Aaron

15

Kami baru-baru ini pindah dan memiliki segala macam masalah dengan DNS.

Ketika kami melakukan swing over, sebagian besar pelanggan mulai langsung memukul IP baru. Tetapi beberapa masih memukul IP lama selama berminggu-minggu. Kami meninggalkan server selama sebulan atau lebih. Akhirnya kami pergi melalui log IIS pada mesin lama dan memanggil pelanggan memberitahu mereka untuk menyiram DNS di sana perusahaan atau server DNS ISP. Itu membuat mereka yang terakhir pindah.

Itu adalah sejumlah kecil orang yang menggunakan IP lama. Dari 20k pelanggan, mungkin 50 mengalami masalah setelah hari pertama.

— mrdenny
sumber

1

Terima kasih! Itu tentang apa yang saya harapkan. Seperempat persen tidak terlalu buruk untuk beberapa jenis lalu lintas, meskipun tentu sangat buruk bagi yang lain.

— user10501

1

Perkiraan yang lebih baru: 13 jam perubahan server DNS, total 17/500 (3,4%) pelanggan menghubungi kami karena mereka masih dilayani situs lama dan bukan yang baru. WhatsMyDNS berguna untuk memeriksa status propagasi (dalam kasus kami, 4/140 = 2,85% server dalam sampel mereka masih menggunakan IP lama / salah - Saya berharap saya menggunakan ini sebelumnya untuk berkomunikasi dengan pelanggan dan lacak propagasi DNS.)

— Fabien Snauwaert

Jika saya ingin melakukan perubahan DNS lagi, saya akan menyiapkan nama domain cadangan terlebih dahulu, untuk melayani situs baru sementara yang lama masih menyebar.

— Fabien Snauwaert

8

(Sangat) nilai-nilai TTL panjang minggu pada bulan Mei 2011 dihormati oleh sebagian besar nameserver yang menyelesaikan DNS hingga 2 minggu.

Dalam tes menggunakan just-dnslookup.com, memiliki 50 titik pengukuran aktif terdistribusi global, dengan catatan A TTL ditetapkan ke 99,999.999 = 165 minggu (tepat: 165 minggu 2 hari 9 jam 46 menit 39 detik), dan TTL default 2 minggu (= SOA + NS TTL).

Pengembalian pencarian pertama :

TTL 1 minggu, untuk 3 dari 50 titik pengukuran
TTL 165 minggu, untuk 47 dari 50 titik pengukuran

Pengembalian pencarian berturut-turut (dikonversi ke nilai TTL asli):

TTL 1 minggu, untuk 3 dari 50 titik pengukuran
TTL 2 minggu, untuk 46 dari 50 titik pengukuran
TTL selama 165 minggu, untuk 1 dari 50 titik pengukuran

Tes kedua (menggunakan domain yang berbeda) di mana TTL default diatur ke 4 minggu (= SOA + NS TTL) hasilnya di bawah ini.

Pengembalian pencarian pertama :

TTL 1 minggu, untuk 3 dari 50 titik pengukuran
TTL 2 minggu, untuk 1 dari 50 titik pengukuran
TTL 165 minggu, untuk 46 dari 50 titik pengukuran

Pengembalian pencarian berurutan (dikonversi ke panjang TTL penuh):

TTL 1 minggu, untuk 3 dari 50 titik pengukuran
TTL 2 minggu, untuk 47 dari 50 titik pengukuran
TTL 165 minggu, untuk 0 dari 50 titik pengukuran

Dari layanan penyelesaian publik yang paling terkenal / paling terhubung:

DNS publik Google [8.8.8.8 dan 8.8.4.4] dikurangi menjadi 1 hari.
UltraDNS [rdns (1 | 2) .ultradns.net] mendapat kehormatan penuh selama 165 minggu.
Sprintlink [ns (1 | 2 | 3) .sprintlink.net] mendapat kehormatan penuh selama 165 minggu.

— Pro Backup
sumber

11

Secara pribadi, saya akan lebih khawatir tentang apakah pengaturan TTL pendek dihormati. Sudahkah Anda melakukan penelitian serupa tentang ini? Misalnya, jika TTL diatur ke 3600 detik, akankah catatan yang di-cache benar-benar berakhir setelah satu jam? Ini sangat relevan dengan situasi peralihan. Pikiran bahwa TTL 165 minggu akan dihormati sebenarnya cukup menakutkan, terutama ketika memikirkan situasi di mana saya dipanggil untuk membersihkan setelah kesalahan orang lain.

— Skyhawk

Saya pikir 8.8.8.8 sepenuhnya mengabaikan TTL dan hanya menggunakan 24 jam. Ini tentu tidak menghormati setidaknya beberapa ttl lebih rendah. Sekarang saya harus menemukan sesuatu untuk dilakukan selama 24 jam.

— Steven Parkes

3

Saya baru-baru ini memindahkan DNS untuk beberapa domain yang meng-host situs pribadi saya dan situs proyek dari GoDaddy ke DNS internal (yeah, secara harfiah rumah saya ). Secara keseluruhan, setiap situs yang saya miliki memiliki akses jarak jauh untuk menghormati TTL dan melakukan transisi dengan baik. Hal yang sama dilaporkan oleh setiap teman yang bisa saya tanyakan untuk diperiksa, baik melalui telepon rumah maupun seluler. Ironisnya, satu-satunya masalah adalah server DNS caching utama di $ University tempat saya bekerja, yang tampaknya benar-benar mengabaikan TTL untuk permintaan yang di-cache (dan bahkan mengabaikan nilai TTL yang mereka tetapkan untuk hasil cache).

Sepertinya, secara keseluruhan, TTL harus dihormati. 56% server otoritatif untuk domain .com dan .net menjalankan BIND, yang jelas sesuai dengan standar. Cablevision / Optimum (setidaknya di NJ) tampaknya menggunakan Nominum CNS, yang juga menghormati TTL.

— Jason Antman
sumber

0

Ini bukan jawaban untuk pertanyaan Anda secara khusus; melainkan, hal-hal tambahan untuk dipertimbangkan yang berperan dalam pengujian Anda:

Receptor DNS dan Caching Daemon yang Dirantai

Bukan hanya tepi reseptor DNS yang menyimpan catatan cache. Kadang-kadang orang membuat rantai reseptor dan ini menambah waktu. Apakah ini harus dilakukan atau tidak bisa menjadi diskusi yang panjang berdasarkan apa yang orang coba pecahkan. Saya telah melihat 3 level rekursi di pusat data. Pencampur rekursi dapat memiliki hasil yang beragam, karena penurunan TTL tidak selalu dipertahankan. Beberapa catatan cache sistem operasi. Beberapa sistem juga menggunakan hal-hal seperti nscd, dnsmasqdan metode lain untuk meminimalkan dampak dari masalah recursor lokal dan mengurangi beban pada recursor mereka. Karakteristik pada OS bervariasi berdasarkan versi rilis, caching daemon, versi caching daemon, dll ...

[Sunting] Untuk mengulangi, ini bukan perilaku normal dari recursor atau caching daemon. Saya tidak akan mempermalukan yang buggy, tetapi salah satu dari mereka dianggap tidak terawat, meskipun itu dibundel dengan banyak distro linux.

Tembolok DNS Aplikasi

Beberapa browser juga menyimpan catatan. Java dan aplikasi lain juga melakukan cache DNS. Terkadang Anda dapat membatasi maksimal dalam aplikasi.

Hasil Akhir Dapat Dipiringkan

Item di atas dapat dengan mudah mengubah TTL 15 menit menjadi 60+ menit atau bahkan lebih lama.

Inilah sebabnya saya sering menyarankan bahwa aplikasi atau situs web harus mempertimbangkan memiliki beberapa node aktif dalam desain toleransi kesalahan mereka, sehingga klien dapat menentukan lebih cepat ketika satu titik masuk ke situs Anda telah gagal dan secara otomatis menangani masalah ini dalam sebuah rumah yang anggun dan dapat diprediksi. , jika layak. Anycast adalah salah satu metode yang digunakan beberapa perusahaan untuk membuat failover agak transparan dan tidak terlalu bergantung pada perubahan DNS. Ada juga beberapa metode pintar load balancing yang dapat dilakukan dalam javascript menggunakan beberapa catatan DNS.

— Harun
sumber

TTL tidak mengatur ulang hanya karena catatan dikirim dari satu server DNS ke yang berikutnya. 15 menit TTL berarti 15 menit tidak peduli berapa banyak lapisan cache yang dilaluinya. Satu-satunya cara bisa menjadi lebih adalah jika beberapa perangkat lunak buggy dan tidak menerapkan DNS dengan benar.

— kasperd

Saya setuju. Saya telah mengalami sedikit reseptor kereta.

— Aaron

-1

Pertanyaan lama, tetapi jawaban baru (2017, 6 tahun kemudian):

Sepertinya hampir semua server DNS di seluruh dunia memperbarui dalam 5 menit
Google dan OpenDNS memungkinkan Anda membersihkan data DNS secara manual, mempercepat pembaruan propagasi

Sebelum percobaan di bawah ini, saya sebelumnya mengubah TTL saya dari 14400 (detik = 4 jam) menjadi 300 (detik = 5 menit) tetapi saya melakukannya 2 jam sebelum percobaan dan karena TTL sebelumnya adalah 4 jam saya tidak yakin perubahan saya akan keluar jika server DNS tidak memiliki TTL minimum mereka sendiri.

Eksperimen saya:

Eksperimen 1:

Saya mengubah terjemahan nama-ke-IP (catatan) di server otoritatif kemudian memeriksa:

Setelah 5 menit (300 detik) sekitar setengah dari server global yang diperiksa oleh situs-situs tersebut telah di-udpated.

Setelah 7 menit, semua telah diperbarui kecuali 1.

Eksperimen 2:

Google dan OpenDNS memungkinkan Anda membersihkan cache DNS secara manual untuk domain tertentu. Tautan:

Siram entri cache DNS Google untuk domain Anda: https://developers.google.com/speed/public-dns/cache
Masukkan entri cache DNS OpenDNS untuk domain Anda: https://cachecheck.opendns.com/

Saya memperbarui A-record lain, dan kemudian segera membersihkan cache DNS Google. Mereka memiliki captcha yang membuat saya "mengklik semua kotak dengan tanda" 3 kali, jadi butuh 1-2 menit sebelum saya bisa menyelesaikan flush.

Setelah 4 menit, hanya 1 server DNS yang diperiksa oleh situs-situs tersebut yang memiliki alamat IP lama. Semua yang lain telah diperbarui.

Jadi membersihkan cache DNS Google, dan memaksanya untuk meminta kembali server otoritatif, tampaknya telah mempercepat propagasi DNS global, mungkin dengan memicu pembaruan cache di seluruh server dunia.

Namun bahkan tanpa Google flush, tampaknya propagasi dalam hitungan menit, bukan jam atau hari.

— john v kumpf
sumber