DNS latentzia baxua Interneten nabigatzeko gakoa da. Hori gutxitzeko, garrantzitsua da DNS zerbitzariak arretaz hautatzea eta . Baina lehen urratsa alferrikako kontsultak kentzea da.
Horregatik DNS jatorriz oso cache daitekeen protokolo gisa diseinatu zen. Zonako administratzaileek bizitzeko denbora (TTL) ezartzen dute sarrera indibidualentzat, eta ebazleek informazio hori erabiltzen dute sarrerak memorian gordetzean, beharrezkoa ez den trafikoa saihesteko.
Eraginkorra al da cachea? Duela urte pare bat, nire ikerketa txikiak erakutsi zuen ez zela perfektua. Ikus dezagun egungo egoerari.
Adabaki dudan informazioa biltzeko erantzunaren TTL balioa gordetzeko. Sarrerako eskaera bakoitzeko bere erregistroen gutxieneko TTL gisa definitzen da. Honek benetako trafikoaren TTL banaketaren ikuspegi orokorra ematen du, eta banakako eskaeren ospea ere hartzen du kontuan. Zerbitzariaren adabakitutako bertsioak hainbat orduz funtzionatu zuen.
Ondorioz, datu multzoak 1 erregistrok osatzen dute (izena, qtype, TTL, denbora-zigilua). Hona hemen TTL banaketa orokorra (X ardatza TTL da segundotan):
86-n kolpe txiki bat alde batera utzita (gehienetan SOA erregistroetarako), nahiko argi dago TTLak baxuan daudela. Ikus dezagun hurbilagotik:
Ados, ordubete baino gehiagoko TTLak ez dira estatistikoki esanguratsuak. Orduan zentra gaitezen 1-0 barrutian:
TTL gehienak 0 eta 15 minutu bitartekoak dira:
Gehienak 0 eta 5 minutu bitartekoak dira:
Ez da oso ona.
Banaketa metatuak arazoa are nabarmenagoa egiten du:
DNS erantzunen erdiek minutu 1 edo gutxiagoko TTL dute, eta hiru laurdenek 5 minutu edo gutxiagoko TTL.
Baina itxaron, benetan okerragoa da. Azken finean, zerbitzari autoritarioetako TTL da. Hala ere, bezero-ebazleek (adibidez, bideratzaileak, tokiko cacheak) TTL bat jasotzen dute gorako ebazleetatik, eta segundoro murrizten da.
Beraz, bezeroak sarrera bakoitza, batez beste, jatorrizko TTL erdirako erabil dezake eskaera berri bat bidali aurretik.
Agian, TTL oso baxu hauek ezohiko eskaerei soilik aplikatzen zaizkie eta ez webgune eta API ezagunei? Ikus dezagun begirada bat:
X ardatza TTL da, Y ardatza kontsultaren ospea da.
Zoritxarrez, kontsulta ezagunenak ere cachean gordetzeko okerrenak dira.
Handitu dezagun:
Epaia: oso txarra da. Lehen jada txarra zen, baina are okerrago egin zen. DNS cachea ia alferrikakoa bihurtu da. Jende gutxiagok erabiltzen duen heinean ISPren DNS konpontzailea (arrazoi onengatik), latentziaren igoera nabariagoa da.
DNS cachea erabilgarri bihurtu da inork bisitatzen ez duen edukirako soilik.
Mesedez, kontutan izan ere softwarea izan daitekeela TTL baxuak interpretatu.
Zergatik da hori?
Zergatik ezartzen dira DNS erregistroak TTL hain baxuan?
- Karga-orekatzaile zaharrek ezarpen lehenetsiekin geratu ziren.
- Badira DNS karga orekatzea TTLren araberakoa dela dioen mitoak (hau ez da egia - Netscape Navigator-en garaitik, bezeroek ausazko IP helbide bat aukeratu dute RR multzo batetik eta beste modu gardenean saiatu dira konektatu ezin badira)
- Administratzaileek berehala aplikatu nahi dituzte aldaketak, beraz errazagoa da planifikatzea.
- DNS zerbitzari baten edo karga-orekatzailearen administratzaileak bere zeregina erabiltzaileek eskatzen duten konfigurazioa modu eraginkorrean zabaltzea dela ikusten du, eta ez guneak eta zerbitzuak bizkortzea.
- TTL baxuek lasaitasuna ematen dizute.
- Jendeak hasieran TTL baxuak ezartzen ditu probak egiteko eta gero horiek aldatzea ahaztu egiten da.
Zerrendan ez dut "failover" sartu, gero eta garrantzi gutxiago duelako. Erabiltzaileak beste sare batera birbideratu behar badituzu errore-orri bat bistaratzeko beste guztia hautsita dagoenean, minutu 1 baino gehiagoko atzerapena onargarria izango da ziurrenik.
Gainera, minutu bateko TTL batek esan nahi du DNS zerbitzari autoritarioak minutu 1 baino gehiagoz blokeatzen badira, beste inork ezingo duela menpeko zerbitzuetara sartu. Eta erredundantziak ez du lagunduko kausa konfigurazio-errore bat edo hack bat bada. Bestalde, arrazoizko TTLekin, bezero askok aurreko konfigurazioa erabiltzen jarraituko dute eta ez dute ezer nabarituko.
CDN zerbitzuak eta karga-orekatzaileak dira TTL baxuen errua, batez ere CNAMEak TTL baxuekin eta erregistroak TTL berdin baxuekin (baina independenteekin) konbinatzen dituztenean:
$ 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
CNAME edo A erregistroren bat iraungitzen den bakoitzean, eskaera berri bat bidali behar da. Biek 30 segundoko TTL dute, baina ez da berdina. Benetako batez besteko TTL 15 segundokoa izango da.
Baina itxaron! Are okerragoa da. Ebazle batzuk oso gaizki portatzen dira egoera honetan elkartuta dauden bi TTL baxuekin:
$ zulatu raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME-n github.map.fastly.net. github.map.fastly.net. 1 BAN 151.101.16.133
Level3 konpontzailea ziurrenik BIND-en exekutatzen da. Eskaera hau bidaltzen jarraitzen baduzu, 1eko TTL bat itzuliko da beti. Funtsean, raw.githubusercontent.com ez da inoiz cachean gordetzen.
Hona hemen domeinu oso ezaguna duen egoera horren beste adibide bat:
$ 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
Gutxienez hiru CNAME erregistro. Bai. Batek TTL duina dauka, baina guztiz alferrikakoa da. Beste CNAME batzuek hasierako 60 segundoko TTL dute, baina domeinuetarako akamai.net gehienezko TTL 20 segundokoa da eta horietako bat ere ez dago fasean.
Zer gertatzen da Apple gailuak etengabe galdetzen dituzten domeinuekin?
$ 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
Firefox eta TTL-ren arazo bera segundo 1ean geratuko da gehienetan Level3 konpontzailea erabiltzean.
Dropbox?
$ zulatu client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME-n client.dropbox-dns.com. client.dropbox-dns.com. 59 BATEAN 162.125.67.3 $ zulatu client.dropbox.com @4.2.2.2 client.dropbox.com. 1 CNAME-n client.dropbox-dns.com. client.dropbox-dns.com. 1 BAN 162.125.64.3
Grabazioan safebrowsing.googleapis.com TTL balioa 60 segundokoa da, Facebook domeinuak bezala. Eta, berriro ere, bezeroaren ikuspuntutik, balio horiek erdira murrizten dira.
Zer moduz gutxieneko TTL ezartzea?
Izena, eskaera mota, TTL eta jatorrian gordetako denbora-zigilua erabiliz, script bat idatzi nuen cacheko ebatzaile batetik igarotzen ziren 1,5 milioi eskaera simulatzeko, iraungitako cache-sarrera dela-eta bidalitako alferrikako eskaeren bolumena kalkulatzeko.
Eskaeren % 47,4 lehendik zegoen erregistro bat iraungi ondoren egin ziren. Hau arrazoirik gabe altua da.
Zer eragin izango du cachean gutxieneko TTL ezartzen bada?
X ardatza gutxieneko TTL balioak dira. Balio honen gainetik iturburuko TTLak dituzten erregistroek ez dute eraginik izango.
Y ardatza dagoeneko cachean dagoen sarrera bat daukan bezero baten eskaeren ehunekoa da, baina iraungi egin da eta eskaera berri bat egiten ari da.
"Aparteko" eskaeren kuota % 47tik % 36ra murrizten da gutxieneko TTL 5 minutura ezarrita. Gutxieneko TTL 15 minutura ezarriz gero, eskaera horien kopurua % 29ra jaisten da. Ordubeteko gutxieneko TTL batek %1ra murrizten ditu. Alde nabarmena!
Zer moduz zerbitzariaren aldetik ezer ez aldatzea, baizik eta bezeroen DNS cacheetan (bideratzaileak, tokiko ebatzaileak) TTL minimoa ezartzea?
Beharrezko eskaera kopurua % 47tik % 34ra jaisten da 5 minutuko gutxieneko TTL batekin, % 25era 15 minutu gutxienez eta % 13ra ordu 1 gutxienez. Beharbada, 40 minutu egokiena da.
Aldaketa txiki honen eragina izugarria da.
Zeintzuk dira ondorioak?
Jakina, zerbitzua hodeiko hornitzaile berri batera, zerbitzari berrira, sare berri batera eraman daiteke, bezeroek azken DNS erregistroak erabiltzeko eskatuz. Eta TTL nahiko txiki batek trantsizio hori arin eta hautemanezin egiten laguntzen du. Baina azpiegitura berrirako trantsizioarekin, inork ez du espero bezeroak minutu 1, 5 edo 15 minutuko epean DNS erregistro berrietara migratzea. Gutxieneko TTL 40 minutura ezartzeak 5 minuturen ordez ez du eragotziko erabiltzaileek zerbitzuan sartzea.
Hala ere, horrek nabarmen murriztuko du latentzia eta pribatutasuna eta fidagarritasuna hobetuko ditu alferrikako eskaerak saihestuz.
Noski, RFCek diote TTL zorrotz jarraitu behar dela. Baina errealitatea da DNS sistema eraginkorregia bihurtu dela.
DNS zerbitzari autoritarioekin lan egiten ari bazara, egiaztatu zure TTLak. Benetan behar al dituzu hain balio irrigarri baxuak?
Noski, arrazoi onak daude DNS erregistroetarako TTL txikiak ezartzeko. Baina ez ia aldatu gabe geratzen den DNS trafikoaren %75erako.
Eta arrazoiren batengatik DNSrako TTL baxuak erabili behar badituzu, aldi berean, ziurtatu zure guneak ez duela cachea gaituta. Arrazoi berdinengatik.
Tokiko DNS cache bat exekutatzen baduzu, adibidez horrek gutxieneko TTLak ezartzeko aukera ematen dizu, erabili funtzio hau. Hau ondo dago. Ez da ezer txarrik gertatuko. Ezarri gutxieneko TTL gutxi gorabehera 40 minutu (2400 segundo) eta ordu 1. Nahiko arrazoizko tartea.
Iturria: www.habr.com