Latensi DNS anu rendah mangrupikeun konci pikeun browsing internét gancang. Pikeun ngaleutikan éta, hal anu penting pikeun taliti milih server DNS na . Tapi lengkah kahiji nyaéta pikeun ngaleungitkeun patarosan anu teu aya gunana.
Ieu naha DNS asalna dirancang salaku protokol kacida cacheable. Administrator Zona nyetél waktos hirup (TTL) pikeun éntri individu, sareng solvers nganggo inpormasi ieu nalika nyimpen éntri dina mémori pikeun nyegah lalu lintas anu teu perlu.
Naha cache efektif? Sababaraha taun ka pengker, panilitian sakedik kuring nunjukkeun yén éta henteu sampurna. Hayu urang tingali kaayaan kiwari.
Pikeun ngumpulkeun informasi kuring patched pikeun nyimpen nilai TTL pikeun respon. Ieu diartikeun salaku TTL minimum rékaman na pikeun tiap pamundut asup. Ieu méré gambaran alus ngeunaan sebaran TTL lalulintas nyata, sarta ogé tumut kana akun popularitas requests individu. Versi patched tina server digawé pikeun sababaraha jam.
Set data anu dihasilkeun diwangun ku 1 rékaman (ngaran, qtype, TTL, timestamp). Ieu distribusi TTL sakabéh (sumbu X nyaéta TTL dina detik):
Kumisan ti nabrak minor dina 86 (lolobana pikeun rékaman SOA), éta geulis jelas yén TTLs aya dina rentang low. Hayu urang nempo leuwih deukeut:
Oké, TTL leuwih ti 1 jam teu signifikan sacara statistik. Teras hayu urang difokuskeun rentang 0−3600:
Paling TTLs ti 0 nepi ka 15 menit:
Seuseueurna ti 0 dugi ka 5 menit:
Éta henteu saé pisan.
Distribusi kumulatif ngajantenkeun masalahna langkung atra:
Satengah tina réspon DNS gaduh TTL 1 menit atanapi kirang, sareng tilu-saparapat gaduh TTL 5 menit atanapi kirang.
Tapi antosan, éta sabenerna parah. Barina ogé, ieu TTL ti server otoritatif. Sanajan kitu, solvers klien (misalna routers, caches lokal) narima TTL ti solvers hulu, sarta eta nurun unggal detik.
Jadi klien sabenerna bisa ngagunakeun unggal entri pikeun, rata-rata, satengah tina TTL aslina saméméh ngirim pamundut anyar.
Meureun TTLs pisan low ieu ngan dilarapkeun ka requests mahiwal jeung teu populér jaba jeung API? Hayu urang tingali:
Sumbu X nyaéta TTL, sumbu Y nyaéta popularitas query.
Hanjakal, queries nu pang populerna oge awon ka cache.
Hayu urang zum in:
Putusan: éta bener goréng. Éta parantos parah sateuacanna, tapi janten langkung parah. cache DNS geus jadi ampir euweuh gunana. Kusabab pangsaeutikna jalma anu nganggo DNS resolver ISP na (kusabab anu saé), paningkatan latency janten langkung jelas.
DNS cache geus jadi mangpaat ukur keur eusi nu teu saurang ogé didatangan.
Punten dicatet ogé yén parangkat lunak tiasa nafsirkeun TTLs low.
Kunaon kitu
Naha rékaman DNS disetel ka TTL anu handap?
- Pangimbang beban warisan ditinggalkeun ku setélan standar.
- Aya mitos yén kasaimbangan beban DNS gumantung kana TTL (ieu henteu leres - ti jaman Netscape Navigator, klien parantos milih alamat IP acak tina sakumpulan RR sareng sacara transparan nyobian anu sanés upami aranjeunna henteu tiasa nyambung)
- Administrator hoyong langsung nerapkeun parobahan, janten langkung gampang ngarencanakeun.
- Administrator server DNS atanapi load balancer ningali tugasna salaku épisién nyebarkeun konfigurasi anu dipénta ku pangguna, sareng henteu nyepetkeun situs sareng jasa.
- TTL rendah masihan anjeun katenangan.
- Jalma mimitina nyetél TTLs low pikeun nguji lajeng poho ngarobahna.
Kuring henteu ngalebetkeun "failover" dina daptar sabab éta janten kirang relevan. Upami anjeun kedah alihan pangguna ka jaringan anu sanés ngan ukur ningalikeun halaman kasalahan nalika leres-leres sadayana rusak, reureuh langkung ti 1 menit sigana tiasa ditampi.
Salaku tambahan, TTL hiji-menit hartina lamun server DNS otoritatif dipeungpeuk leuwih ti 1 menit, teu saurang ogé bakal bisa ngakses jasa gumantung. Sareng redundansi moal ngabantosan upami panyababna nyaéta kasalahan konfigurasi atanapi hack. Di sisi séjén, kalawan TTLs lumrah, loba klien bakal neruskeun migunakeun konfigurasi saméméhna tur pernah aya bewara nanaon.
Ladenan CDN sareng penyeimbang beban umumna disalahkeun pikeun TTL rendah, khususna nalika aranjeunna ngagabungkeun CNAME sareng TTL rendah sareng rékaman sareng TTL anu sami rendah (tapi mandiri):
$ 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
Iraha waé CNAME atanapi salah sahiji rékaman A tamat, pamundut énggal kedah dikirim. Duanana mibanda TTL 30 detik, tapi teu sarua. Rata-rata TTL sabenerna bakal 15 detik.
Tapi antosan! Malah leuwih parah. Sababaraha solvers kalakuanana parah pisan dina kaayaan ieu sareng dua TTLs low pakait:
$ bor raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 DI CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Resolver Level3 sigana dijalankeun dina BIND. Upami anjeun neraskeun ngirim pamundut ieu, TTL 1 bakal salawasna dipulangkeun. raw.githubusercontent.com teu pernah sindangan.
Ieu conto sejen tina kaayaan sapertos domain pisan populér:
$ 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
Sahenteuna tilu rékaman CNAME. Ay. Hiji boga TTL santun, tapi sagemblengna gunana. CNAMEs séjén boga TTL awal 60 detik, tapi pikeun domain akamai.net TTL maksimum nyaéta 20 detik sareng henteu aya dina fase.
Kumaha upami domain anu terus-terusan polling alat 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 anu sami sareng Firefox sareng TTL bakal macét dina 1 detik paling sering nalika nganggo solver Level3.
Dropbox?
$ bor client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN 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 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
Dina rékaman safebrowsing.googleapis.com Nilai TTL nyaéta 60 detik, sapertos domain Facebook. Sareng, sakali deui, tina sudut pandang klien, nilai-nilai ieu dipotong satengah.
Kumaha upami netepkeun TTL minimum?
Ngagunakeun ngaran, tipe pamundut, TTL, sarta mimitina disimpen timestamp, Kuring nulis naskah pikeun simulate 1,5 juta requests ngaliwatan resolver cache keur estimasi volume requests perlu dikirim alatan éntri cache kadaluwarsa.
47,4% tina requests dijieun sanggeus rékaman aya geus kadaluwarsa. Ieu unreasonably tinggi.
Naon bakal dampak dina cache lamun TTL minimum disetel?
Sumbu X nyaéta nilai TTL minimum. Rékaman kalawan TTLs sumber luhur nilai ieu teu kapangaruhan.
Sumbu Y nyaéta persentase pamundut ti klien anu parantos ngagaduhan éntri sindangan, tapi parantos kadaluwarsa sareng ngadamel pamundut énggal.
Pangsa tina "tambahan" requests diréduksi tina 47% ka 36% ku saukur netepkeun TTL minimum pikeun 5 menit. Ku netepkeun TTL minimum ka 15 menit, jumlah pamundut ieu turun ka 29%. TTL minimum 1 jam ngirangan aranjeunna janten 17%. bédana signifikan!
Kumaha upami henteu ngarobih nanaon di sisi server, tapi netepkeun TTL minimum dina cache DNS klien (router, solvers lokal)?
Jumlah pamundut anu diperyogikeun turun tina 47% ka 34% kalayan TTL minimum 5 menit, janten 25% kalayan sahenteuna 15 menit, sareng ka 13% kalayan minimum 1 jam. Panginten 40 menit optimal.
Dampak parobahan leutik ieu gede pisan.
Naon balukarna?
Tangtu, jasa bisa dipindahkeun ka panyadia awan anyar, server anyar, jaringan anyar, merlukeun klien ngagunakeun rékaman DNS panganyarna. Sareng TTL anu cukup leutik ngabantosan transisi sapertos kitu lancar sareng teu katingali. Tapi kalayan transisi ka infrastruktur anyar, teu saurang ogé nyangka klien migrasi ka rékaman DNS anyar dina 1 menit, 5 menit, atawa 15 menit. Nyetél TTL minimum ka 40 menit tibatan 5 menit moal nyegah pangguna pikeun ngaksés jasa éta.
Nanging, ieu sacara signifikan bakal ngirangan latency sareng ningkatkeun privasi sareng reliabilitas ku ngahindarkeun pamundut anu teu perlu.
Tangtosna, RFC nyarios yén TTL kedah diturutan sacara ketat. Tapi kanyataanana éta sistem DNS geus jadi teuing episien.
Upami anjeun damel sareng server DNS anu otoritatif, mangga parios TTL anjeun. Naha anjeun leres-leres peryogi nilai anu ridiculously low?
Tangtosna, aya alesan anu saé pikeun nyetél TTL leutik pikeun rékaman DNS. Tapi henteu pikeun 75% lalu lintas DNS anu tetep ampir teu robih.
Sareng upami pikeun sababaraha alesan anjeun leres-leres kedah nganggo TTL anu rendah pikeun DNS, dina waktos anu sami pastikeun yén situs anjeun henteu ngaktipkeun cache. Pikeun alesan anu sarua.
Upami Anjeun gaduh cache DNS lokal ngajalankeun, kayaning nu ngidinan Anjeun pikeun nyetél TTLs minimum, make pungsi ieu. Ieu sae. Euweuh goréng bakal kajadian. Setel TTL minimum ka sakitar 40 menit (2400 detik) sareng 1 jam. Rentang anu lumayan.
sumber: www.habr.com