Latensi DNS yang rendah adalah faktor kunci untuk menjelajah internet cepat. Untuk menguranginya, penting untuk memilih server DNS dan relai anonim dengan cermat. Tetapi hal pertama yang harus dilakukan adalah menyingkirkan pertanyaan yang tidak berguna.

Itulah sebabnya DNS pada awalnya dibuat sebagai protokol yang sangat di-cache. Administrator zona menetapkan masa hidup (TTL) untuk catatan individual, dan resolver menggunakan informasi ini ketika menyimpan catatan dalam memori untuk menghindari lalu lintas yang tidak perlu.

Apakah caching efisien? Beberapa tahun yang lalu, penelitian kecil saya menunjukkan bahwa itu tidak sempurna. Lihatlah keadaan saat ini.

Untuk mengumpulkan informasi, saya menambal Server DNS Terenkripsi untuk menyimpan nilai TTL untuk respons. Ini didefinisikan sebagai TTL minimum dari entri untuk setiap permintaan yang masuk. Ini memberikan gambaran yang baik tentang distribusi lalu lintas nyata TTL, dan juga memperhitungkan popularitas permintaan individu. Versi server yang ditambal berfungsi selama beberapa jam.

Set data yang dihasilkan terdiri dari 1.583.579 catatan (nama, qtype, TTL, timestamp). Berikut adalah distribusi umum TTL (sumbu X adalah TTL dalam detik):



Terlepas dari gundukan kecil pada 86.400 (terutama untuk catatan SOA), sangat jelas bahwa TTL berada dalam kisaran rendah. Mari kita lihat lebih dekat:



Yah, TTL lebih dari 1 jam tidak signifikan secara statistik. Kemudian fokus pada kisaran 0−3600:



Sebagian besar TTL dari 0 hingga 15 menit:



Sebagian besar dari 0 hingga 5 menit:



Ini tidak terlalu bagus.

Distribusi kumulatif membuat masalahnya semakin jelas:



Dalam setengah dari tanggapan DNS, TTL adalah 1 menit atau kurang, dan dalam tiga perempat 5 menit atau kurang.

Tapi tunggu, ini sebenarnya lebih buruk. Bagaimanapun, ini adalah TTL dari server otoritatif. Namun, resolver klien (mis., Router, cache lokal) menerima TTL dari resolver yang lebih tinggi, dan itu menurun setiap detik.

Dengan demikian, klien dapat benar-benar menggunakan setiap catatan, rata-rata, untuk setengah dari TTL asli, setelah itu akan mengirimkan permintaan baru.

Mungkin TTL yang sangat rendah ini hanya menyangkut permintaan yang tidak biasa, bukan situs web dan API populer? Mari kita lihat:



Sumbu X adalah TTL, sumbu Y adalah popularitas permintaan.

Sayangnya, kueri paling populer juga di-cache paling buruk.

Perbesar:



Putusan: semuanya benar-benar buruk. Itu buruk sebelumnya, tetapi menjadi lebih buruk. Caching DNS menjadi hampir tidak berguna. Karena lebih sedikit orang menggunakan ISP resolver DNS mereka (untuk alasan yang baik), peningkatan latensi menjadi lebih terlihat.

Caching DNS menjadi bermanfaat hanya untuk konten yang tidak dikunjungi oleh siapa pun.

Perhatikan juga bahwa perangkat lunak dapat menginterpretasikan TTL rendah secara berbeda .

Kenapa begitu

Mengapa TTL set kecil untuk catatan DNS?

• Penyeimbang beban yang ketinggalan zaman dibiarkan dengan pengaturan default.
  
• Ada mitos bahwa penyeimbangan beban DNS tergantung pada TTL (tidak demikian - sejak zaman Netscape Navigator, klien memilih alamat IP acak dari set RR dan secara transparan mencoba yang lain jika mereka tidak dapat terhubung)
  
• Administrator ingin segera menerapkan perubahan, karena lebih mudah untuk merencanakan.
  
• Administrator server DNS atau load balancer melihat tugasnya secara efektif menggunakan konfigurasi yang diminta pengguna, bukannya mempercepat situs dan layanan.
  
• TTL rendah memberi ketenangan pikiran.
  
• Orang awalnya menetapkan TTL rendah untuk pengujian dan kemudian lupa mengubahnya.

Saya tidak memasukkan "failover" dalam daftar, karena ini semua kurang relevan. Jika Anda perlu mengarahkan ulang pengguna ke jaringan lain hanya untuk menampilkan halaman kesalahan, ketika semuanya benar-benar rusak, penundaan lebih dari 1 menit mungkin dapat diterima.

Selain itu, menit TTL berarti bahwa jika server DNS resmi diblokir lebih dari 1 menit, tidak ada orang lain yang dapat mengakses layanan dependen. 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 akan pernah melihat apa pun.

Untuk TTL rendah, sebagian besar layanan CDN dan penyeimbang beban harus disalahkan, terutama ketika mereka menggabungkan CNAME dengan TTL kecil dan catatan dengan TTL yang sama-sama kecil (tapi independen):

  $ drill raw.githubusercontent.com
 raw.githubusercontent.com.  9 DALAM CNAME github.map.fastly.net.
 github.map.fastly.net.  20 DALAM A 151.101.128.133
 github.map.fastly.net.  20 DALAM A 151.101.192.133
 github.map.fastly.net.  20 DALAM A 151.101.0.133
 github.map.fastly.net.  20 DALAM A 151.101.64.133 

Setiap kali CNAME atau salah satu catatan A kedaluwarsa, Anda harus mengirim permintaan baru. Keduanya memiliki TTL 30 detik, tetapi tidak cocok. TTL rata-rata aktual adalah 15 detik.

Tapi tunggu! Lebih buruk lagi. Beberapa resolver berperilaku sangat buruk dalam situasi ini dengan dua TTL rendah terkait:

  $ drill raw.githubusercontent.com @ 4.2.2.2
 raw.githubusercontent.com.  1 DALAM CNAME github.map.fastly.net.
 github.map.fastly.net.  1 DALAM A 151.101.16.133 

Penyelesai Level3 mungkin bekerja pada BIND. Jika Anda terus mengirim permintaan ini, TTL 1 akan selalu dikembalikan. Pada dasarnya, raw.githubusercontent.com tidak pernah di-cache.

Berikut adalah contoh lain dari situasi seperti ini dengan domain yang sangat populer:

  $ drill detectportal.firefox.com @ 1.1.1.1
 detectportal.firefox.com.  25 DALAM CNAME detectportal.prod.mozaws.net.
 detectportal.prod.mozaws.net.  26 DALAM CNAME detectportal.firefox.com-v2.edgesuite.net.
 detectportal.firefox.com-v2.edgesuite.net.  10668 DALAM CNAME a1089.dscd.akamai.net.
 a1089.dscd.akamai.net.  10 DALAM A 104.123.50.106
 a1089.dscd.akamai.net.  10 DALAM A 104.123.50.88 

Setidaknya tiga catatan CNAME. Ah. Seseorang memiliki TTL yang layak, tetapi sama sekali tidak berguna. Di CNAME lain, TTL awal adalah 60 detik, tetapi untuk domain akamai.net TTL maksimum adalah 20 detik, dan tidak satu pun dari mereka berada dalam fase.

Bagaimana dengan domain yang secara konstan menyurvei perangkat Apple?

  $ drill 1-courier.push.apple.com @ 4.2.2.2
 1-courier.push.apple.com.  1253 DALAM CNAME 1.courier-push-apple.com.akadns.net.
 1.courier-push-apple.com.akadns.net.  1 DALAM CNAME gb-courier-4.push-apple.com.akadns.net.
 gb-courier-4.push-apple.com.akadns.net.  1 DALAM A 17.57.146.84
 gb-courier-4.push-apple.com.akadns.net.  1 DALAM A 17.57.146.85 

Masalah yang sama dengan Firefox, dan TTL akan macet selama 1 detik sebagian besar saat menggunakan resolver Level3.

Dropbox?

  $ drill client.dropbox.com @ 8.8.8.8
 client.dropbox.com.  7 DALAM CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  59 IN A 162.125.67.3

 $ drill client.dropbox.com @ 4.2.2.2
 client.dropbox.com.  1 DALAM CNAME client.dropbox-dns.com.
 client.dropbox-dns.com.  1 DALAM A 162.125.64.3 

safebrowsing.googleapis.com TTL 60 detik, seperti halnya dengan domain Facebook. Dan, sekali lagi, dari sudut pandang klien, nilai-nilai ini dibelah dua.

Bagaimana dengan pengaturan TTL minimum?

Menggunakan nama, tipe permintaan, TTL, dan cap waktu yang awalnya disimpan, saya menulis sebuah skrip untuk mensimulasikan 1,5 juta permintaan yang melewati penyelesai caching untuk memperkirakan jumlah permintaan tambahan yang dikirim karena entri cache yang kadaluwarsa.

47,4% dari permintaan dibuat setelah berakhirnya catatan yang ada. Ini terlalu tinggi.

Apa efeknya terhadap caching jika TTL minimum disetel?



Sumbu X adalah nilai TTL minimum. Catatan dengan TTL sumber di atas nilai ini tidak terpengaruh.

Sumbu Y - persentase permintaan dari klien yang sudah memiliki catatan cache, tetapi telah kedaluwarsa dan itu membuat permintaan baru.

Persentase permintaan "ekstra" berkurang dari 47% menjadi 36% hanya dengan mengatur TTL minimum dalam 5 menit. Saat mengatur TTL minimum dalam 15 menit, jumlah permintaan ini dikurangi menjadi 29%. TTL minimum 1 jam menguranginya hingga 17%. Perbedaan besar!

Bagaimana kalau tidak mengubah apa pun di sisi server, tetapi sebaliknya mengatur TTL minimum dalam cache DNS klien (router, resolver lokal)?



Jumlah permintaan yang diperlukan berkurang dari 47% menjadi 34% ketika menetapkan TTL minimum dalam 5 menit, menjadi 25% dengan minimum 15 menit, dan hingga 13% dengan minimum 1 jam. Mungkin nilai optimal adalah 40 menit.

Dampak dari perubahan minimal ini sangat besar.

Apa implikasinya?

Tentu saja, layanan dapat ditransfer ke penyedia cloud baru, server baru, jaringan baru, yang mengharuskan pelanggan untuk menggunakan catatan DNS terbaru. Dan TTL yang cukup kecil membantu dengan lancar dan mulus melakukan transisi seperti itu. Tetapi dengan transisi ke infrastruktur baru, tidak ada yang mengharapkan pelanggan untuk beralih ke catatan DNS baru dalam 1 menit, 5 menit, atau 15 menit. Menetapkan usia minimum 40 menit, bukannya 5 menit tidak akan mencegah pengguna mengakses layanan.

Namun, ini akan secara signifikan mengurangi latensi dan meningkatkan kerahasiaan dan keandalan, menghindari permintaan yang tidak perlu.

Tentu saja, RFC mengatakan Anda perlu menegakkan TTL dengan ketat. Tetapi kenyataannya adalah bahwa sistem DNS menjadi terlalu tidak efisien.

Jika Anda bekerja dengan server DNS resmi, silakan periksa TTL Anda. Apakah Anda benar-benar membutuhkan nilai yang sangat rendah?

Tentu saja, ada alasan bagus untuk mengatur TTL kecil untuk catatan DNS. Tetapi tidak untuk 75% dari 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 caching tidak diaktifkan di situs Anda. Untuk alasan yang sama.

Jika Anda memiliki cache DNS lokal, seperti dnscrypt-proxy , yang memungkinkan Anda untuk mengatur TTL minimum, gunakan fungsi ini. Ini normal. Tidak ada hal buruk yang akan terjadi. Atur TTL minimum antara sekitar 40 menit (2400 detik) dan 1 jam. Rentang yang cukup masuk akal.