Latensi DNS sing sithik minangka kunci kanggo njelajah internet kanthi cepet. Kanggo nyilikake, iku penting kanggo kasebut kanthi teliti, milih server DNS lan . Nanging langkah pisanan 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 entri individu, lan solvers nggunakake informasi iki nalika nyimpen entri ing memori supaya ora lalu lintas sing ora perlu.
Apa caching efektif? Sawetara taun kepungkur, riset cilikku nuduhake manawa ora sampurna. Ayo padha ndeleng 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.
Set data sing diasilake dumadi saka 1 cathetan (jeneng, qtype, TTL, timestamp). Punika distribusi TTL sakabèhé (sumbu X yaiku TTL ing detik):
Aside saka bump suntingan ing 86 (biasane kanggo cathetan SOA), iku cukup cetha sing TTLs ing sawetara kurang. Ayo katon luwih cedhak:
Oke, TTL luwih saka 1 jam ora signifikan sacara statistik. Banjur ayo fokus ing kisaran 0β3600:
Umume TTL yaiku saka 0 nganti 15 menit:
Paling akeh yaiku saka 0 nganti 5 menit:
Iku 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. Sawise kabeh, iki TTL saka server resmi. Nanging, solvers klien (eg router, cache lokal) nampa TTL saka solvers hulu, lan suda saben detik.
Dadi klien bisa nggunakake saben entri 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 situs web lan API sing ora populer? Ayo dideleng:
Sumbu X yaiku TTL, sumbu Y minangka popularitas pitakon.
Sayange, pitakon sing paling populer uga paling awon kanggo cache.
Ayo zoom in:
Putusan: elek tenan. SadurungΓ© uwis ala, nanging saya tambah parah. 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 wis dadi migunani mung kanggo konten sing ora ana sing ngunjungi.
Elinga uga yen piranti lunak bisa uga kokwaca TTLs kurang.
Napa ngene
Napa cathetan DNS disetel dadi TTL sing sithik?
- Pengimbang beban warisan ditinggalake kanthi setelan gawan.
- Ana mitos yen DNS load balancing gumantung marang TTL (iki ora bener - wiwit jaman Netscape Navigator, klien wis milih alamat IP acak saka sakumpulan 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 nggunakake konfigurasi sing dijaluk pangguna, lan ora nyepetake situs lan layanan.
- TTL sing sithik menehi katentreman atine.
- Wong wiwitane nyetel TTL sing sithik kanggo dites lan banjur lali ngganti.
Aku ora kalebu "failover" ing dhaftar amarga iku dadi kurang lan 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 apa-apa.
Layanan CDN lan load balancers umume disalahake kanggo TTL sing sithik, utamane nalika nggabungake CNAME kanthi 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
Kapan 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! Malah luwih elek. Sawetara solvers tumindak banget ing kahanan iki karo loro TTLs kurang gegandhengan:
$ 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 bisa uga nganggo BIND. Yen sampeyan terus ngirim panjalukan iki, TTL 1 mesthi bakal dibalekake. Intine, raw.githubusercontent.com ora tau cached.
Iki conto liyane saka kahanan kaya domain sing populer banget:
$ 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. Ay. Siji duwe TTL sing prayoga, nanging ora ana gunane. CNAME liyane duwe TTL awal 60 detik, nanging kanggo domain akamai.net TTL maksimum 20 detik lan ora ana ing phase.
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 yaiku 60 detik, kaya domain Facebook. Lan maneh, saka sudut pandang 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 volume panjalukan sing ora perlu dikirim amarga entri cache kadaluwarsa.
47,4% panjalukan digawe sawise rekaman sing ana wis kadaluwarsa. Iki ora cukup dhuwur.
Apa bakal dadi impact ing cache yen TTL minimal disetel?
Sumbu X minangka nilai TTL minimal. Cathetan karo TTL sumber 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.
Panggabungan panjalukan "ekstra" dikurangi saka 47% dadi 36% kanthi mung nyetel TTL minimal dadi 5 menit. Kanthi nyetel TTL minimal dadi 15 menit, jumlah panjalukan kasebut mudhun dadi 29%. TTL minimal 1 jam nyuda dadi 17%. Bedane sing signifikan!
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% kanthi TTL minimal 5 menit, dadi 25% kanthi minimal 15 menit, lan dadi 13% kanthi minimal 1 jam. Mungkin 40 menit paling optimal.
Dampak saka owah-owahan cilik iki gedhe banget.
Apa akibate?
Mesthi, layanan kasebut bisa dipindhah menyang panyedhiya maya anyar, server anyar, jaringan anyar, sing mbutuhake klien nggunakake cathetan DNS paling anyar. Lan TTL sing cukup cilik mbantu nggawe transisi kasebut kanthi lancar lan ora katon. Nanging kanthi transisi menyang infrastruktur anyar, ora ana sing ngarepake klien 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.
Mesthine, RFC ujar manawa TTL kudu ditindakake 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 tetep ora owah.
Lan yen sakperangan alesan sampeyan pancene kudu nggunakake TTL kurang kanggo DNS, ing wektu sing padha priksa manawa situs sampeyan ora duwe caching aktif. Kanggo alasan sing padha.
Yen sampeyan duwe cache DNS lokal sing mlaku, kayata sing ngijini sampeyan kanggo nyetel TTLs minimal, nggunakake fungsi iki. Iki apik. Ora ana sing ala bakal kelakon. Setel TTL minimal dadi kira-kira 40 menit (2400 detik) lan 1 jam. Kisaran sing cukup cukup.
Source: www.habr.com