Latensi DNS sing sithik minangka faktor kunci kanggo browsing cepet. Kanggo nyilikake, iku penting kanggo kasebut kanthi teliti, milih server DNS lan . Nanging bab pisanan sing kudu ditindakake yaiku nyingkirake pitakon sing ora ana gunane.
Mulane DNS wiwitane dirancang minangka protokol sing bisa di-cache. Administrator zona nyetel wektu kanggo urip (TTL) kanggo rekaman individu, lan solvers nggunakake informasi iki nalika nyimpen rekaman ing memori supaya ora lalu lintas sing ora perlu.
Apa caching efektif? Sawetara taun kepungkur, riset cilikku nuduhake manawa ora sampurna. Coba deleng kahanan saiki.
Kanggo ngumpulake informasi aku patched kanggo nyimpen Nilai TTL kanggo nanggepi. Iki ditetepake minangka TTL minimal saka cathetan, kanggo saben panjalukan sing mlebu. Iki menehi gambaran apik babagan distribusi TTL saka lalu lintas nyata, lan uga njupuk popularitas panjalukan individu. Versi patched saka server makarya kanggo sawetara jam.
Dataset sing diasilake dumadi saka 1 cathetan (jeneng, qtype, TTL, timestamp). Punika distribusi TTL sakabèhé (sumbu-x yaiku TTL ing detik):
Loro saka bump tipis ing 86 (biasane kanggo cathetan SOA), iku cukup ketok sing TTLs ing sawetara kurang. Ayo katon luwih cedhak:
Oke, TTL luwih saka 1 jam sacara statistik ora pati penting. Ayo fokus ing kisaran 0-3600 banjur:
Umume TTL antara 0 nganti 15 menit:
Paling akeh yaiku saka 0 nganti 5 menit:
Iki ora apik banget.
Distribusi kumulatif ndadekake masalah luwih jelas:
Setengah saka tanggapan DNS duwe TTL 1 menit utawa kurang, lan telung perempat duwe TTL 5 menit utawa kurang.
Nanging ngenteni, nyatane luwih elek. Iki TTL saka server wewenang. Nanging, solvers klien (eg router, cache lokal) entuk TTL saka solvers hulu, lan suda saben detik.
Mangkono, klien bisa nggunakake saben rekaman kanggo, rata-rata, setengah saka TTL asli sadurunge ngirim panjalukan anyar.
Mungkin TTL sing sithik banget iki mung ditrapake kanggo panjaluk sing ora biasa lan ora kanggo situs web lan API sing populer? Ayo dideleng:
Sumbu X yaiku TTL, sumbu Y minangka popularitas pitakon.
Sayange, pitakon sing paling populer uga dadi cache sing paling awon.
Ayo zoom in:
Putusan: Pancen ala. Iku wis ala, lan dadi luwih elek. Caching DNS wis meh ora ana gunane. Amarga luwih sithik wong nggunakake solver DNS ISP (kanggo alasan sing apik), tambah latensi dadi luwih katon.
Caching DNS mung dadi migunani kanggo konten sing ora ana sing ngunjungi.
Wigati uga yen piranti lunak bisa uga kokwaca TTLs kurang.
Napa ngene
Napa cathetan DNS disetel menyang TTL cilik?
- Pengimbang beban warisan ditinggalake kanthi setelan gawan.
- Ana mitos manawa imbangan beban DNS gumantung marang TTL (iki ora bener - amarga Netscape Navigator, klien milih alamat IP acak saka set RR lan kanthi transparan nyoba liyane yen ora bisa nyambung)
- Administrator pengin langsung ngetrapake owah-owahan, supaya luwih gampang ngrancang.
- Administrator server DNS utawa load balancer ndeleng tugase kanthi efisien ngetrapake konfigurasi sing dijaluk pangguna, lan ora nyepetake operasi situs lan layanan.
- Low TTL menehi katentreman atine.
- Wong wiwitane nyetel TTL sing sithik kanggo dites lan banjur lali ngganti.
Aku ora kalebu "failover" amarga dadi kurang relevan. Yen sampeyan kudu ngarahake pangguna menyang jaringan liya mung kanggo nampilake kaca kesalahan nalika kabeh liyane rusak, wektu tundha luwih saka 1 menit bisa uga ditrima.
Kajaba iku, TTL siji menit tegese yen server DNS otoritatif diblokir luwih saka 1 menit, ora ana wong liya sing bisa ngakses layanan sing gumantung. Lan redundansi ora bakal mbantu yen sababe kesalahan konfigurasi utawa hack. Ing sisih liya, kanthi TTL sing cukup, akeh klien bakal terus nggunakake konfigurasi sadurunge lan ora bakal weruh.
TTL sing sithik minangka kesalahan layanan CDN lan penyeimbang beban, utamane nalika nggabungake CNAME karo TTL sing sithik lan cathetan kanthi TTL sing padha (nanging 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
Saben wektu CNAME utawa cathetan A kadaluwarsa, panjalukan anyar kudu dikirim. Loro-lorone duwe TTL 30 detik, nanging ora padha. TTL rata-rata sing bener yaiku 15 detik.
Nanging ngenteni! Iku dadi luwih elek. Sawetara solvers tumindak ala banget ing kahanan iki kanthi rong TTL sing kurang:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ING CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Penyelesai Level3 mbokmenawa mlaku ing BIND. Yen sampeyan terus ngirim pitakon iki, mesthi bakal ngasilake TTL 1. Intine, raw.githubusercontent.com tau cached.
Iki conto liyane saka kahanan iki karo domain banget 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
Paling ora telung cathetan CNAME. Adhuh. Siji duwe TTL sing prayoga, nanging ora ana gunane. CNAME liyane duwe TTL awal 60 detik, nanging kanggo domain akamai.net TTL maksimum yaiku 20 detik lan ora ana sing ana ing fase.
Apa babagan domain sing terus-terusan polling piranti 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 sing padha karo Firefox lan TTL bakal macet ing 1 detik paling akeh nalika nggunakake Level3 solver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 ING CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ bor client.dropbox.com @4.2.2.2 client.dropbox.com. 1 ING CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Ing rekaman safebrowsing.googleapis.com Nilai TTL 60 detik, kaya domain Facebook. Lan maneh, saka perspektif klien, nilai kasebut dikurangi setengah.
Kepiye carane nyetel TTL minimal?
Nggunakake jeneng, jinis panjalukan, TTL, lan timestamp sing asline disimpen, aku nulis skrip kanggo simulasi 1,5 yuta panjalukan liwat solver caching kanggo ngira jumlah panjalukan ekstra sing dikirim amarga entri cache kadaluwarsa.
47,4% panjalukan digawe sawise rekaman sing ana wis kadaluwarsa. Iki ora cukup dhuwur.
Apa bakal dadi impact ing caching yen TTL minimal disetel?
Sumbu X minangka nilai TTL minimal. Cathetan kanthi TTL mentah ing ndhuwur nilai iki ora kena pengaruh.
Sumbu Y minangka persentase panjalukan saka klien sing wis duwe entri cache, nanging wis kadaluwarsa lan nggawe panjalukan anyar.
Bagian saka panjalukan "ekstra" dikurangi saka 47% dadi 36% kanthi mung nyetel TTL minimal dadi 5 menit. Nyetel TTL minimal nganti 15 menit nyuda jumlah panjaluk kasebut dadi 29%. TTL minimal 1 jam nyuda dadi 17%. Bentenipun pinunjul!
Kepiye carane ora ngganti apa wae ing sisih server, nanging nyetel TTL minimal ing cache DNS klien (router, solver lokal)?
Jumlah panjalukan sing dibutuhake mudhun saka 47% dadi 34% nalika nyetel TTL minimal dadi 5 menit, dadi 25% kanthi minimal 15 menit, lan dadi 13% kanthi minimal 1 jam. Mungkin 40 menit paling optimal.
Dampak saka owah-owahan minimal iki gedhe banget.
Apa akibate?
Mesthi, sampeyan bisa migrasi layanan menyang panyedhiya maya anyar, server anyar, jaringan anyar, lan mbutuhake pelanggan nggunakake cathetan DNS paling anyar. Lan TTL sing cukup cilik mbantu nggawe transisi kasebut lancar lan lancar. Nanging nalika sampeyan pindhah menyang infrastruktur anyar, ora ana sing ngarepake pelanggan migrasi menyang cathetan DNS anyar sajrone 1 menit, 5 menit, utawa 15 menit. Nyetel TTL minimal dadi 40 menit tinimbang 5 menit ora bakal nyegah pangguna ngakses layanan kasebut.
Nanging, iki bakal nyuda latensi kanthi signifikan lan nambah privasi lan linuwih kanthi ngindhari panjaluk sing ora perlu.
Mesthi, RFC ujar manawa TTL kudu dileksanakake kanthi ketat. Nanging kasunyatane yaiku sistem DNS wis dadi ora efisien.
Yen sampeyan nggarap server DNS sing duwe wewenang, priksa TTL sampeyan. Sampeyan pancene kudu nilai ridiculously kurang kuwi?
Mesthi, ana alasan sing apik kanggo nyetel TTL cilik kanggo cathetan DNS. Nanging ora kanggo 75% lalu lintas DNS sing meh ora owah.
Lan yen ana alesan sampeyan kudu nggunakake TTL sing sithik kanggo DNS, priksa manawa situs sampeyan ora ngaktifake cache. Kanggo alasan sing padha.
Yen sampeyan duwe cache DNS lokal sing mlaku, kayata , sing ngidini sampeyan nyetel TTL minimal, gunakake fungsi iki. Iki normal. Ora ana sing ala bakal kelakon. Setel TTL minimal ing antarane 40 menit (2400 detik) nganti 1 jam. Kisaran sing cukup.
Source: www.habr.com
