Ang ubos nga DNS latency mao ang yawe sa paspas nga pag-browse sa internet. Aron mamenosan kini, importante nga maampingong pilion ang mga DNS server ug . Apan ang unang lakang mao ang pagwagtang sa walay pulos nga mga pangutana.
Mao kini ang hinungdan nga ang DNS orihinal nga gidisenyo isip usa ka protocol nga ma-cacheable. Ang mga administrador sa sona nagtakda ug panahon sa pagkinabuhi (TTL) alang sa tagsa-tagsa nga mga entri, ug ang mga tigresolba mogamit niini nga impormasyon kon magtipig sa mga entri sa memorya aron malikayan ang wala kinahanglana nga trapiko.
Epektibo ba ang pag-cache? Pipila ka tuig ang milabay, ang akong gamay nga panukiduki nagpakita nga kini dili perpekto. Atong tan-awon ang kasamtangan nga kahimtang sa mga kalihokan.
Aron mangolekta og impormasyon akong gi-patch sa pagluwas sa TTL bili alang sa tubag. Gihubit kini nga minimum nga TTL sa mga rekord niini alang sa matag umaabot nga hangyo. Naghatag kini usa ka maayo nga pagtan-aw sa pag-apod-apod sa TTL sa tinuud nga trapiko, ug gikonsiderar usab ang pagkapopular sa mga indibidwal nga hangyo. Ang patched nga bersyon sa server nagtrabaho sa daghang oras.
Ang resulta nga set sa datos naglangkob sa 1 nga mga rekord (ngalan, qtype, TTL, timestamp). Ania ang kinatibuk-ang pag-apod-apod sa TTL (X-axis mao ang TTL sa mga segundo):
Gawas sa usa ka menor de edad nga bump sa 86 (kadaghanan alang sa mga rekord sa SOA), klaro kaayo nga ang mga TTL naa sa ubos nga sakup. Atong tan-awon pag-ayo:
Okay, ang mga TTL nga labaw sa 1 ka oras dili importante sa istatistika. Dayon mag-focus kita sa range 0β3600:
Kadaghanan sa mga TTL gikan sa 0 hangtod 15 ka minuto:
Ang kadaghanan gikan sa 0 hangtod 5 minuto:
Dili kaayo maayo.
Ang kumulative distribution naghimo sa problema nga mas klaro:
Ang katunga sa mga tubag sa DNS adunay TTL nga 1 ka minuto o ubos pa, ug ang tulo ka quarter adunay TTL nga 5 ka minuto o mas ubos.
Pero teka, mas grabe pa gyud. Pagkahuman, kini ang TTL gikan sa mga awtoritatibo nga server. Bisan pa, ang mga solusyon sa kliyente (pananglitan, mga router, lokal nga cache) makadawat usa ka TTL gikan sa mga solusyon sa upstream, ug kini mikunhod matag segundo.
Mao nga magamit gyud sa kliyente ang matag entry alang, sa kasagaran, katunga sa orihinal nga TTL sa dili pa magpadala usa ka bag-ong hangyo.
Tingali kining ubos kaayo nga mga TTL magamit lamang sa dili kasagaran nga mga hangyo ug dili popular nga mga website ug mga API? Atong tan-awon:
Ang X axis kay TTL, ang Y axis kay query popularity.
Ikasubo, ang labing inila nga mga pangutana mao usab ang labing daotan sa cache.
Atong i-zoom in:
Paghukom: grabe gyud. Daotan na kaniadto, pero nisamot pa gyud. Ang DNS caching nahimong halos walay kapuslanan. Samtang nagkagamay ang mga tawo nga naggamit sa DNS resolver sa ilang ISP (alang sa maayong mga rason), ang pagtaas sa latency mahimong mas mamatikdan.
Ang DNS caching nahimong mapuslanon lamang alang sa sulod nga walay usa nga mibisita.
Palihug timan-i usab nga ang software mahimo paghubad sa ubos nga TTLs.
Ngano?
Ngano nga ang mga rekord sa DNS gibutang sa ingon ka ubos nga TTL?
- Ang mga legacy load balancer gibilin nga adunay mga default nga setting.
- Adunay mga tumotumo nga ang pagbalanse sa load sa DNS nagdepende sa TTL (dili kini tinuod - sukad sa mga adlaw sa Netscape Navigator, ang mga kliyente mipili sa usa ka random nga IP address gikan sa usa ka set sa mga RR ug tin-aw nga misulay sa lain kung dili sila makakonektar)
- Gusto sa mga tagdumala nga mag-apply dayon sa mga pagbag-o, aron mas dali ang pagplano.
- Ang tigdumala sa DNS server o load balancer nagtan-aw sa iyang tahas nga episyente sa pagdeploy sa configuration nga gipangayo sa mga user, ug dili pagpadali sa mga site ug serbisyo.
- Ang mga mubu nga TTL naghatag kanimo og kalinaw sa hunahuna.
- Ang mga tawo sa sinugdan nagbutang ug mubu nga mga TTL alang sa pagsulay ug unya nakalimot sa pag-ilis niini.
Wala nako giapil ang "failover" sa lista tungod kay nagkagamay na. Kung kinahanglan nimo nga i-redirect ang mga tiggamit sa lain nga network aron lang magpakita sa usa ka panid sa sayup kung hingpit nga naguba ang tanan, ang paglangan nga labaw sa 1 minuto mahimoβg madawat.
Dugang pa, ang usa ka minuto nga TTL nagpasabut nga kung ang mga awtoritatibo nga DNS server gibabagan sa sobra sa 1 minuto, walaβy lain nga maka-access sa mga nagsalig nga serbisyo. Ug ang redundancy dili makatabang kung ang hinungdan usa ka sayup sa pag-configure o usa ka hack. Sa laing bahin, uban ang makatarunganon nga mga TTL, daghang mga kliyente ang magpadayon sa paggamit sa miaging pag-configure ug walaβy namatikdan bisan unsa.
Ang mga serbisyo sa CDN ug mga load balancer maoy kasagarang mabasol sa ubos nga TTL, ilabina kung ilang gihiusa ang mga CNAME nga adunay ubos nga TTL ug mga rekord nga adunay parehas nga ubos (apan independente) nga mga TTL:
$ 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
Sa matag higayon nga ang CNAME o bisan unsa sa A nga mga rekord matapos, usa ka bag-ong hangyo kinahanglan ipadala. Ang duha adunay 30 segundos nga TTL, apan kini dili parehas. Ang aktuwal nga kasagaran nga TTL mahimong 15 segundos.
Apan paghulat! Mas grabe pa gyud. Ang ubang mga solver naglihok nga dili maayo sa kini nga sitwasyon nga adunay duha ka kaubang ubos nga TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 SA CNAME github.map.fastly.net. github.map.fastly.net. 1 SA A 151.101.16.133
Ang Level3 solver lagmit nagdagan sa BIND. Kung magpadayon ka sa pagpadala niini nga hangyo, usa ka TTL nga 1 ang kanunay ibalik. raw.githubusercontent.com dili gayud naka-cache.
Ania ang laing pananglitan sa ingon nga sitwasyon nga adunay popular kaayo nga domain:
$ 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
Labing menos tulo ka mga rekord sa CNAME. Ay. Ang usa adunay usa ka desente nga TTL, apan kini hingpit nga walay kapuslanan. Ang ubang mga CNAME adunay inisyal nga TTL nga 60 segundos, apan alang sa mga domain akamai.net ang pinakataas nga TTL kay 20 segundos ug walay usa niini ang anaa sa hugna.
Unsa man ang bahin sa mga domain nga kanunay nga nagsusi sa mga aparato sa 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
Ang parehas nga problema sama sa Firefox ug TTL ma-stuck sa 1 segundo sa kadaghanan sa oras kung gigamit ang Level3 solver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 SA CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 SA USA ka 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 SA CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 SA A 162.125.64.3
Sa recording safebrowsing.googleapis.com Ang kantidad sa TTL 60 segundos, sama sa mga domain sa Facebook. Ug, usab, gikan sa punto sa panglantaw sa kliyente, kini nga mga kantidad gibahin sa tunga.
Unsa man ang bahin sa pagtakda sa usa ka minimum nga TTL?
Gamit ang ngalan, tipo sa hangyo, TTL, ug orihinal nga gitipigan nga timestamp, nagsulat ako usa ka script aron i-simulate ang 1,5 milyon nga mga hangyo nga moagi sa usa ka solver sa caching aron mabanabana ang gidaghanon sa wala kinahanglana nga mga hangyo nga gipadala tungod sa usa ka na-expire nga pagsulod sa cache.
Ang 47,4% sa mga hangyo gihimo pagkahuman sa usa ka kasamtangan nga rekord nga na-expire. Kini dili makatarunganon nga taas.
Unsa ang mahimong epekto sa pag-cache kung ang minimum nga TTL gitakda?
Ang X axis mao ang minimum nga TTL values. Ang mga rekord nga adunay gigikanan nga TTL nga labaw sa kini nga kantidad dili maapektuhan.
Ang Y axis mao ang porsyento sa mga hangyo gikan sa usa ka kliyente nga aduna nay naka-cache nga entry, apan kini na-expire na ug naghimo og bag-ong hangyo.
Ang bahin sa "dugang" nga mga hangyo gipakunhod gikan sa 47% ngadto sa 36% pinaagi lamang sa pagtakda sa minimum nga TTL ngadto sa 5 minutos. Pinaagi sa pagbutang sa minimum nga TTL ngadto sa 15 minutos, ang gidaghanon niini nga mga hangyo mikunhod ngadto sa 29%. Ang usa ka minimum nga TTL sa 1 ka oras makapakunhod kanila ngadto sa 17%. Dakong kalainan!
Unsa man ang bahin sa dili pagbag-o sa bisan unsang butang sa bahin sa server, apan imbes itakda ang labing gamay nga TTL sa mga cache sa DNS sa kliyente (mga ruta, mga lokal nga solusyon)?
Ang gidaghanon sa mga hangyo nga gikinahanglan mikunhod gikan sa 47% ngadto sa 34% nga adunay minimum nga TTL nga 5 minutos, ngadto sa 25% nga adunay minimum nga 15 minutos, ug ngadto sa 13% nga adunay minimum nga 1 ka oras. Tingali ang 40 minuto mao ang labing maayo.
Ang epekto niining gamay nga pagbag-o dako kaayo.
Unsa ang mga sangputanan?
Siyempre, ang serbisyo mahimong ibalhin sa usa ka bag-ong cloud provider, bag-ong server, bag-ong network, nga nagkinahanglan sa mga kliyente sa paggamit sa pinakabag-o nga DNS records. Ug ang medyo gamay nga TTL makatabang sa paghimo sa ingon nga pagbalhin nga hapsay ug dili mamatikdan. Apan sa transisyon ngadto sa bag-ong imprastraktura, walay nagdahom nga ang mga kliyente molalin ngadto sa bag-ong mga rekord sa DNS sulod sa 1 ka minuto, 5 ka minuto, o 15 ka minuto. Ang pagbutang sa minimum nga TTL ngadto sa 40 minutos imbes 5 minutos dili makapugong sa mga tiggamit sa pag-access sa serbisyo.
Bisan pa, kini makapakunhod pag-ayo sa latency ug makapauswag sa pagkapribado ug kasaligan pinaagi sa paglikay sa wala kinahanglana nga mga hangyo.
Siyempre, ang mga RFC nag-ingon nga ang TTL kinahanglan nga hugot nga sundon. Apan ang tinuod mao nga ang sistema sa DNS nahimong dili kaayo epektibo.
Kung nagtrabaho ka sa mga awtoritatibo nga DNS server, palihug susiha ang imong mga TTL. Kinahanglan ba gyud nimo ang ingon nga kataw-anan nga ubos nga mga kantidad?
Siyempre, adunay maayo nga mga rason sa pagbutang sa gagmay nga mga TTL alang sa mga rekord sa DNS. Apan dili alang sa 75% sa trapiko sa DNS nga nagpabilin nga halos wala mausab.
Ug kung sa usa ka hinungdan kinahanglan nimo nga mogamit mga mubu nga TTL alang sa DNS, sa samang higayon siguroha nga ang imong site walaβy pag-enable sa caching. Sa samang mga rason.
Kung ikaw adunay lokal nga DNS cache nga nagdagan, sama sa nga nagtugot kanimo sa pagtakda sa minimum nga mga TTL, gamita kini nga function. Maayo kini. Walay daotang mahitabo. Itakda ang minimum nga TTL sa gibana-bana nga 40 minutos (2400 segundos) ug 1 ka oras. Usa ka makatarunganon nga range.
Source: www.habr.com