Kependaman DNS yang rendah adalah kunci kepada penyemakan imbas internet yang pantas. Untuk meminimumkannya, adalah penting untuk berhati-hati memilih pelayan DNS dan . Tetapi langkah pertama adalah untuk menyingkirkan pertanyaan yang tidak berguna.
Inilah sebabnya mengapa DNS pada asalnya direka sebagai protokol yang boleh disimpan dalam cache. Pentadbir zon menetapkan masa untuk hidup (TTL) untuk entri individu dan penyelesai menggunakan maklumat ini apabila menyimpan entri dalam ingatan untuk mengelakkan trafik yang tidak diperlukan.
Adakah caching berkesan? Beberapa tahun yang lalu, penyelidikan kecil saya menunjukkan bahawa ia tidak sempurna. Mari kita lihat keadaan semasa.
Untuk mengumpul maklumat saya tampal untuk menyimpan nilai TTL untuk respons. Ia ditakrifkan sebagai TTL minimum rekodnya untuk setiap permintaan masuk. Ini memberikan gambaran keseluruhan yang baik tentang pengedaran TTL trafik sebenar, dan juga mengambil kira populariti permintaan individu. Versi pelayan yang ditambal berfungsi selama beberapa jam.
Set data yang terhasil terdiri daripada 1 rekod (nama, qtype, TTL, cap waktu). Berikut ialah taburan TTL keseluruhan (paksi-X ialah TTL dalam saat):
Selain daripada benjolan kecil pada 86 (kebanyakannya untuk rekod SOA), agak jelas bahawa TTL berada dalam julat rendah. Mari kita lihat lebih dekat:
Okey, TTL yang melebihi 1 jam tidak signifikan secara statistik. Kemudian mari kita fokus pada julat 0β3600:
Kebanyakan TTL adalah dari 0 hingga 15 minit:
Sebahagian besar adalah dari 0 hingga 5 minit:
Ia tidak begitu baik.
Pengagihan kumulatif menjadikan masalah lebih jelas:
Separuh daripada respons DNS mempunyai TTL 1 minit atau kurang, dan tiga perempat mempunyai TTL 5 minit atau kurang.
Tetapi tunggu, ia sebenarnya lebih teruk. Lagipun, ini adalah TTL dari pelayan berwibawa. Walau bagaimanapun, penyelesai pelanggan (cth. penghala, cache tempatan) menerima TTL daripada penyelesai huluan, dan ia berkurangan setiap saat.
Jadi pelanggan sebenarnya boleh menggunakan setiap entri untuk, secara purata, separuh daripada TTL asal sebelum menghantar permintaan baharu.
Mungkin TTL yang sangat rendah ini hanya digunakan untuk permintaan luar biasa dan bukan tapak web dan API yang popular? Mari lihat:
Paksi X ialah TTL dan paksi Y ialah populariti pertanyaan.
Malangnya, pertanyaan yang paling popular juga adalah yang paling teruk untuk dicache.
Mari zum masuk:
Keputusan: ia sangat teruk. Ia sudah teruk sebelum ini, tetapi ia menjadi lebih teruk. Caching DNS telah menjadi hampir tidak berguna. Memandangkan lebih sedikit orang menggunakan penyelesai DNS ISP mereka (atas sebab yang baik), peningkatan kependaman menjadi lebih ketara.
Caching DNS telah menjadi berguna hanya untuk kandungan yang tiada siapa yang melawati.
Sila ambil perhatian juga bahawa perisian mungkin mentafsir TTL rendah.
Mengapa begitu?
Mengapakah rekod DNS ditetapkan kepada TTL yang begitu rendah?
- Pengimbang beban warisan ditinggalkan dengan tetapan lalai.
- Terdapat mitos bahawa pengimbangan beban DNS bergantung pada TTL (ini tidak benar - sejak zaman Netscape Navigator, pelanggan telah memilih alamat IP rawak daripada satu set RR dan mencuba yang lain secara telus jika mereka tidak dapat menyambung)
- Pentadbir mahu menggunakan perubahan dengan segera, jadi lebih mudah untuk merancang.
- Pentadbir pelayan DNS atau pengimbang beban melihat tugasnya sebagai menggunakan konfigurasi yang diminta pengguna dengan cekap dan tidak mempercepatkan tapak dan perkhidmatan.
- TTL yang rendah memberi anda ketenangan fikiran.
- Orang pada mulanya menetapkan TTL rendah untuk ujian dan kemudian lupa menukarnya.
Saya tidak memasukkan "failover" dalam senarai kerana ia semakin kurang relevan. Jika anda perlu mengubah hala pengguna ke rangkaian lain hanya untuk memaparkan halaman ralat apabila semua yang lain rosak, kelewatan lebih daripada 1 minit mungkin boleh diterima.
Selain itu, TTL satu minit bermakna jika pelayan DNS berwibawa disekat selama lebih daripada 1 minit, tiada orang lain akan dapat mengakses perkhidmatan bergantung. Dan redundansi tidak akan membantu jika puncanya ialah ralat konfigurasi atau hack. Sebaliknya, dengan TTL yang munasabah, ramai pelanggan akan terus menggunakan konfigurasi sebelumnya dan tidak pernah melihat apa-apa.
Perkhidmatan CDN dan pengimbang beban sebahagian besarnya harus dipersalahkan untuk TTL rendah, terutamanya apabila mereka menggabungkan CNAME dengan TTL rendah dan rekod dengan TTL yang sama rendah (tetapi bebas):
$ 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
Apabila CNAME atau mana-mana rekod A tamat tempoh, permintaan baharu mesti dihantar. Kedua-duanya mempunyai TTL 30 saat, tetapi ia tidak sama. Purata TTL sebenar ialah 15 saat.
Tapi tunggu! Ia lebih teruk. Sesetengah penyelesai berkelakuan sangat teruk dalam situasi ini dengan dua TTL rendah yang berkaitan:
$ gerudi mentah.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 Tahap3 mungkin berjalan pada BIND. Jika anda terus menghantar permintaan ini, TTL sebanyak 1 akan sentiasa dikembalikan. Pada asasnya, raw.githubusercontent.com tidak pernah dicache.
Berikut ialah satu lagi contoh situasi sedemikian dengan domain yang sangat popular:
$ 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
Sekurang-kurangnya tiga rekod CNAME. Ay. Satu mempunyai TTL yang baik, tetapi ia sama sekali tidak berguna. CNAME lain mempunyai TTL awal 60 saat, tetapi untuk domain akamai.net TTL maksimum ialah 20 saat dan tiada satu pun daripadanya dalam fasa.
Bagaimana pula dengan domain yang sentiasa meninjau peranti 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 tersekat pada 1 saat pada kebanyakan masa apabila menggunakan penyelesai 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 DALAM 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
Pada rakaman itu safebrowsing.googleapis.com Nilai TTL ialah 60 saat, seperti domain Facebook. Dan, sekali lagi, dari sudut pandangan pelanggan, nilai ini dibelah dua.
Bagaimana pula dengan menetapkan TTL minimum?
Menggunakan nama, jenis permintaan, TTL, dan cap waktu yang disimpan pada asalnya, saya menulis skrip untuk mensimulasikan 1,5 juta permintaan yang melalui penyelesai caching untuk menganggarkan jumlah permintaan yang tidak perlu dihantar disebabkan oleh kemasukan cache yang telah tamat tempoh.
47,4% permintaan dibuat selepas rekod sedia ada telah tamat tempoh. Ini adalah tinggi yang tidak munasabah.
Apakah kesan ke atas caching jika TTL minimum ditetapkan?
Paksi X ialah nilai TTL minimum. Rekod dengan TTL sumber di atas nilai ini tidak terjejas.
Paksi Y ialah peratusan permintaan daripada pelanggan yang sudah mempunyai entri cache, tetapi ia telah tamat tempoh dan membuat permintaan baharu.
Bahagian permintaan "tambahan" dikurangkan daripada 47% kepada 36% dengan hanya menetapkan TTL minimum kepada 5 minit. Dengan menetapkan TTL minimum kepada 15 minit, bilangan permintaan ini menurun kepada 29%. TTL minimum 1 jam mengurangkannya kepada 17%. Perbezaan yang ketara!
Bagaimana pula dengan tidak mengubah apa-apa di sisi pelayan, tetapi sebaliknya menetapkan TTL minimum dalam cache DNS pelanggan (penghala, penyelesai tempatan)?
Bilangan permintaan yang diperlukan turun daripada 47% kepada 34% dengan TTL minimum 5 minit, kepada 25% dengan minimum 15 minit, dan kepada 13% dengan minimum 1 jam. Mungkin 40 minit adalah optimum.
Kesan daripada perubahan kecil ini amat besar.
Apakah akibatnya?
Sudah tentu, perkhidmatan itu boleh dialihkan ke penyedia awan baharu, pelayan baharu, rangkaian baharu, yang memerlukan pelanggan menggunakan rekod DNS terkini. Dan TTL yang agak kecil membantu membuat peralihan sedemikian dengan lancar dan tidak dapat dilihat. Tetapi dengan peralihan kepada infrastruktur baharu, tiada siapa menjangkakan pelanggan berhijrah ke rekod DNS baharu dalam masa 1 minit, 5 minit atau 15 minit. Menetapkan TTL minimum kepada 40 minit dan bukannya 5 minit tidak akan menghalang pengguna daripada mengakses perkhidmatan.
Walau bagaimanapun, ini akan mengurangkan kependaman dengan ketara dan meningkatkan privasi serta kebolehpercayaan dengan mengelakkan permintaan yang tidak perlu.
Sudah tentu, RFC mengatakan bahawa TTL mesti diikuti dengan ketat. Tetapi realitinya ialah sistem DNS telah menjadi terlalu tidak cekap.
Jika anda bekerja dengan pelayan DNS yang berwibawa, sila semak TTL anda. Adakah anda benar-benar memerlukan nilai yang sangat rendah?
Sudah tentu, terdapat sebab yang baik untuk menetapkan TTL kecil untuk rekod DNS. Tetapi bukan untuk 75% trafik DNS yang kekal hampir tidak berubah.
Dan jika atas sebab tertentu anda benar-benar perlu menggunakan TTL rendah untuk DNS, pada masa yang sama pastikan tapak anda tidak mendayakan caching. Atas sebab yang sama.
Jika anda mempunyai cache DNS tempatan yang sedang berjalan, seperti yang membolehkan anda menetapkan TTL minimum, gunakan fungsi ini. Ini baik. Tiada perkara buruk akan berlaku. Tetapkan TTL minimum kepada kira-kira 40 minit (2400 saat) dan 1 jam. Julat yang agak munasabah.
Sumber: www.habr.com