Latensi DNS yang rendah adalah kunci penjelajahan internet yang cepat. Untuk meminimalkannya, penting untuk hati-hati memilih server DNS dan . Namun langkah pertama adalah membuang pertanyaan yang tidak berguna.
Inilah sebabnya mengapa DNS pada awalnya dirancang sebagai protokol yang sangat dapat di-cache. Administrator zona menetapkan waktu aktif (TTL) untuk masing-masing entri, dan penyelesai menggunakan informasi ini saat menyimpan entri dalam memori untuk menghindari lalu lintas yang tidak perlu.
Apakah cache efektif? Beberapa tahun yang lalu, penelitian kecil saya menunjukkan bahwa itu tidak sempurna. Mari kita lihat keadaan saat ini.
Untuk mengumpulkan informasi saya menambal untuk menyimpan nilai TTL untuk respons. Ini didefinisikan sebagai TTL minimum dari catatannya untuk setiap permintaan masuk. Ini memberikan gambaran yang bagus tentang distribusi lalu lintas nyata TTL, dan juga memperhitungkan popularitas permintaan individual. Versi server yang ditambal bekerja selama beberapa jam.
Kumpulan data yang dihasilkan terdiri dari 1 record (nama, qtype, TTL, stempel waktu). Berikut adalah distribusi TTL secara keseluruhan (sumbu X adalah TTL dalam hitungan detik):
Selain sedikit peningkatan pada 86 (kebanyakan untuk catatan SOA), cukup jelas bahwa TTL berada dalam kisaran rendah. Mari kita lihat lebih dekat:
Oke, TTL yang lebih besar dari 1 jam tidak signifikan secara statistik. Kalau begitu mari kita fokus pada rentang 0β3600:
Kebanyakan TTL berdurasi dari 0 hingga 15 menit:
Sebagian besar berdurasi dari 0 hingga 5 menit:
Itu tidak terlalu bagus.
Distribusi kumulatif menjadikan permasalahan ini semakin jelas:
Setengah dari respons DNS memiliki TTL 1 menit atau kurang, dan tiga perempatnya memiliki TTL 5 menit atau kurang.
Tapi tunggu, ini sebenarnya lebih buruk. Bagaimanapun, ini adalah TTL dari server resmi. Namun, penyelesai klien (misalnya router, cache lokal) menerima TTL dari penyelesai hulu, dan TTL berkurang setiap detik.
Jadi klien benar-benar dapat menggunakan setiap entri, rata-rata, setengah dari TTL asli sebelum mengirim permintaan baru.
Mungkin TTL yang sangat rendah ini hanya berlaku untuk permintaan yang tidak biasa dan bukan situs web dan API populer? Mari kita lihat:
Sumbu X adalah TTL, sumbu Y adalah popularitas kueri.
Sayangnya, kueri yang paling populer juga merupakan kueri yang paling buruk untuk di-cache.
Mari kita perbesar:
Putusan: sungguh buruk. Sebelumnya sudah buruk, tetapi menjadi lebih buruk lagi. Caching DNS menjadi hampir tidak berguna. Karena semakin sedikit orang yang menggunakan pemecah masalah DNS ISP mereka (untuk alasan yang baik), peningkatan latensi menjadi lebih nyata.
Caching DNS menjadi berguna hanya untuk konten yang tidak dikunjungi siapa pun.
Harap perhatikan juga bahwa perangkat lunak mungkin menafsirkan TTL rendah.
Mengapa begitu?
Mengapa data DNS disetel ke TTL rendah?
- Penyeimbang beban lama dibiarkan dengan pengaturan default.
- Ada mitos bahwa penyeimbangan beban DNS bergantung pada TTL (ini tidak benar - sejak zaman Netscape Navigator, klien telah memilih alamat IP acak dari sekumpulan RR dan secara transparan mencoba alamat IP lain jika mereka tidak dapat terhubung)
- Administrator ingin segera menerapkan perubahan, sehingga lebih mudah untuk merencanakannya.
- Administrator server DNS atau penyeimbang beban melihat tugasnya sebagai penerapan konfigurasi yang diminta pengguna secara efisien, dan tidak mempercepat situs dan layanan.
- TTL rendah memberi Anda ketenangan pikiran.
- Orang-orang pada awalnya menetapkan TTL rendah untuk pengujian dan kemudian lupa mengubahnya.
Saya tidak memasukkan "failover" ke dalam daftar karena semakin tidak relevan. Jika Anda perlu mengarahkan pengguna ke jaringan lain hanya untuk menampilkan halaman kesalahan ketika semuanya benar-benar rusak, penundaan lebih dari 1 menit mungkin dapat diterima.
Selain itu, TTL satu menit berarti jika server DNS otoritatif diblokir selama lebih dari 1 menit, tidak ada orang lain yang dapat mengakses layanan yang bergantung. Dan redundansi tidak akan membantu jika penyebabnya adalah kesalahan konfigurasi atau peretasan. Di sisi lain, dengan TTL yang wajar, banyak klien akan terus menggunakan konfigurasi sebelumnya dan tidak pernah menyadari apa pun.
Layanan CDN dan penyeimbang beban merupakan penyebab utama TTL yang rendah, terutama ketika mereka menggabungkan CNAME dengan TTL rendah dan catatan dengan TTL yang sama rendahnya (namun independen):
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Setiap kali CNAME atau data A mana pun kedaluwarsa, permintaan baru harus dikirim. Keduanya memiliki TTL 30 detik, namun tidak sama. TTL rata-rata sebenarnya adalah 15 detik.
Tapi tunggu! Ini bahkan lebih buruk. Beberapa penyelesai berperilaku sangat buruk dalam situasi ini dengan dua TTL rendah yang terkait:
$ bor mentah.githubusercontent.com @4.2.2.2 mentah.githubusercontent.com. 1 DI CNAME github.map.fastly.net. github.map.fastly.net. 1 DALAM A 151.101.16.133
Resolver Level3 mungkin berjalan di BIND. Jika Anda terus mengirimkan permintaan ini, TTL 1 akan selalu dikembalikan. raw.githubusercontent.com tidak pernah di-cache.
Berikut adalah contoh lain dari situasi seperti itu dengan domain yang sangat populer:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Setidaknya tiga data CNAME. Ay. Seseorang memiliki TTL yang layak, tetapi sama sekali tidak berguna. CNAME lain memiliki TTL awal 60 detik, tetapi untuk domain akamai.net TTL maksimum adalah 20 detik dan tidak ada satupun yang berada dalam fase.
Bagaimana dengan domain yang terus-menerus melakukan polling pada perangkat Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Masalah yang sama seperti Firefox dan TTL akan terhenti pada sebagian besar waktu 1 detik saat menggunakan penyelesai Level3.
Dropbox?
$ bor klien.dropbox.com @8.8.8.8 klien.dropbox.com. 7 DI klien CNAME.dropbox-dns.com. klien.dropbox-dns.com. 59 DALAM 162.125.67.3 $ bor client.dropbox.com @4.2.2.2 client.dropbox.com. 1 DI klien CNAME.dropbox-dns.com. klien.dropbox-dns.com. 1 DALAM A 162.125.64.3
Di rekaman safebrowsing.googleapis.com Nilai TTL adalah 60 detik, seperti domain Facebook. Dan, sekali lagi, dari sudut pandang klien, nilai-nilai ini dibelah dua.
Bagaimana dengan menetapkan TTL minimum?
Dengan menggunakan nama, jenis permintaan, TTL, dan stempel waktu yang awalnya disimpan, saya menulis skrip untuk mensimulasikan 1,5 juta permintaan yang melewati pemecah cache untuk memperkirakan volume permintaan yang tidak diperlukan yang dikirim karena entri cache yang kedaluwarsa.
47,4% permintaan dibuat setelah catatan yang ada habis masa berlakunya. Angka ini terlalu tinggi.
Apa dampaknya terhadap caching jika TTL minimum disetel?
Sumbu X adalah nilai TTL minimum. Catatan dengan TTL sumber di atas nilai ini tidak terpengaruh.
Sumbu Y adalah persentase permintaan dari klien yang sudah memiliki entri cache, namun telah kedaluwarsa dan membuat permintaan baru.
Porsi permintaan βekstraβ berkurang dari 47% menjadi 36% hanya dengan menyetel TTL minimum menjadi 5 menit. Dengan menetapkan TTL minimum ke 15 menit, jumlah permintaan ini turun menjadi 29%. TTL minimum 1 jam menguranginya menjadi 17%. Perbedaan yang signifikan!
Bagaimana kalau tidak mengubah apa pun di sisi server, melainkan mengatur TTL minimum di cache DNS klien (router, penyelesai lokal)?
Jumlah permintaan yang diperlukan turun dari 47% menjadi 34% dengan TTL minimum 5 menit, menjadi 25% dengan minimum 15 menit, dan menjadi 13% dengan minimum 1 jam. Mungkin 40 menit adalah waktu optimal.
Dampak dari perubahan kecil ini sangatlah besar.
Apa konsekuensinya?
Tentu saja, layanan dapat dipindahkan ke penyedia cloud baru, server baru, jaringan baru, sehingga klien harus menggunakan data DNS terbaru. Dan TTL yang cukup kecil membantu melakukan transisi dengan lancar dan tidak terlihat. Namun dengan transisi ke infrastruktur baru, tidak ada yang mengharapkan klien untuk bermigrasi ke data DNS baru dalam waktu 1 menit, 5 menit, atau 15 menit. Menetapkan TTL minimum menjadi 40 menit, bukan 5 menit, tidak akan menghalangi pengguna untuk mengakses layanan.
Namun, hal ini akan mengurangi latensi secara signifikan serta meningkatkan privasi dan keandalan dengan menghindari permintaan yang tidak diperlukan.
Tentu saja RFC mengatakan bahwa TTL harus dipatuhi dengan ketat. Namun kenyataannya sistem DNS menjadi terlalu tidak efisien.
Jika Anda bekerja dengan server DNS resmi, periksa TTL Anda. Apakah Anda benar-benar membutuhkan nilai yang sangat rendah?
Tentu saja, ada alasan bagus untuk menetapkan TTL kecil untuk data DNS. Namun tidak untuk 75% lalu lintas DNS yang hampir tidak berubah.
Dan jika karena alasan tertentu Anda benar-benar perlu menggunakan TTL rendah untuk DNS, pada saat yang sama pastikan situs Anda tidak mengaktifkan caching. Untuk alasan yang sama.
Jika Anda menjalankan cache DNS lokal, misalnya yang memungkinkan Anda menyetel TTL minimum, gunakan fungsi ini. Ini baik-baik saja. Tidak ada hal buruk yang akan terjadi. Atur TTL minimum menjadi sekitar 40 menit (2400 detik) dan 1 jam. Kisaran yang cukup masuk akal.
Sumber: www.habr.com