Lítil DNS leynd er lykillinn að hraðri netvafri. Til að lágmarka það er mikilvægt að velja vandlega DNS netþjóna og . En fyrsta skrefið er að losna við gagnslausar fyrirspurnir.
Þetta er ástæðan fyrir því að DNS var upphaflega hannað sem mjög skyndiminni samskiptareglur. Svæðisstjórar stilla tíma til að lifa (TTL) fyrir einstakar færslur og lausnarar nota þessar upplýsingar þegar þær geyma færslur í minni til að forðast óþarfa umferð.
Er skyndiminni skilvirkt? Fyrir nokkrum árum sýndi litla rannsóknin mín að það var ekki fullkomið. Lítum á stöðu mála í dag.
Til að safna upplýsingum sem ég lagaði til að vista TTL gildið fyrir svarið. Það er skilgreint sem lágmarks TTL skráa þess fyrir hverja beiðni sem berast. Þetta gefur góða yfirsýn yfir TTL dreifingu raunverulegrar umferðar og tekur einnig tillit til vinsælda einstakra beiðna. Pjattaða útgáfan af þjóninum virkaði í nokkrar klukkustundir.
Gagnasettið sem myndast samanstendur af 1 færslum (nafn, qtype, TTL, tímastimpill). Hér er heildar TTL dreifingin (X-ásinn er TTL í sekúndum):
Burtséð frá minniháttar höggi við 86 (aðallega fyrir SOA færslur), er nokkuð ljóst að TTL eru í lágmarki. Við skulum skoða nánar:
Allt í lagi, TTL sem eru lengri en 1 klukkustund eru ekki tölfræðilega marktæk. Þá skulum við einbeita okkur að bilinu 0−3600:
Flestar TTL eru frá 0 til 15 mínútur:
Langflestir eru frá 0 til 5 mínútur:
Það er ekki mjög gott.
Uppsöfnuð dreifing gerir vandamálið enn augljósara:
Helmingur DNS svara er með TTL sem er 1 mínútu eða minna og þrír fjórðu eru með TTL sem er 5 mínútur eða minna.
En bíddu, það er í rauninni verra. Þegar öllu er á botninn hvolft er þetta TTL frá opinberum netþjónum. Hins vegar, leysir viðskiptavina (t.d. beinar, staðbundin skyndiminni) fá TTL frá andstreymis leysirum og það minnkar á hverri sekúndu.
Þannig að viðskiptavinurinn getur í raun notað hverja færslu fyrir að meðaltali helming upprunalegu TTL áður en hann sendir nýja beiðni.
Kannski eiga þessi mjög lágu TTL aðeins við um óvenjulegar beiðnir en ekki vinsælar vefsíður og API? Við skulum skoða:
X-ásinn er TTL, Y-ásinn er fyrirspurnarvinsældir.
Því miður eru vinsælustu fyrirspurnirnar líka þær verstu að vista.
Við skulum þysja inn:
Dómur: það er mjög slæmt. Það var þegar slæmt áður, en það versnaði enn. DNS skyndiminni er orðin nánast gagnslaus. Eftir því sem færri nota DNS-leysara ISP síns (af góðum ástæðum) verður aukningin á leynd meira áberandi.
DNS skyndiminni hefur aðeins orðið gagnlegt fyrir efni sem enginn heimsækir.
Vinsamlegast athugaðu einnig að hugbúnaðurinn gæti túlka lága TTL.
Hvers vegna er það svo?
Af hverju eru DNS færslur stilltar á svona lágan TTL?
- Eldri álagsjafnarar voru skildir eftir með sjálfgefna stillingar.
- Það eru goðsagnir um að DNS-álagsjöfnun sé háð TTL (þetta er ekki satt - frá dögum Netscape Navigator hafa viðskiptavinir valið handahófskennt IP-tölu úr hópi RR og gagnsætt reynt annað ef þeir geta ekki tengst)
- Stjórnendur vilja beita breytingum strax, svo það er auðveldara að skipuleggja.
- Stjórnandi DNS netþjóns eða hleðslujafnara lítur á verkefni sitt sem að beita skilvirkum stillingum sem notendur biðja um, en ekki flýta síðum og þjónustu.
- Lág TTL gefur þér hugarró.
- Fólk setti upphaflega lága TTL fyrir prófun og gleymir síðan að breyta þeim.
Ég setti "failover" ekki inn á listann vegna þess að það verður minna og minna viðeigandi. Ef þú þarft að beina notendum yfir á annað net bara til að birta villusíðu þegar algerlega allt annað er bilað, er töf sem er meira en 1 mínútu líklega ásættanleg.
Að auki þýðir einnar mínútu TTL að ef opinberir DNS netþjónar eru lokaðir í meira en 1 mínútu mun enginn annar geta fengið aðgang að háð þjónustu. Og offramboð mun ekki hjálpa ef orsökin er stillingarvilla eða hakk. Á hinn bóginn, með sanngjörnum TTL, munu margir viðskiptavinir halda áfram að nota fyrri stillingar og taka aldrei eftir neinu.
CDN þjónusta og álagsjafnarar eiga að mestu sök á lágum TTL, sérstaklega þegar þeir sameina CNAME með lágum TTL og færslum með jafn lágum (en óháðum) 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
Alltaf þegar CNAME eða einhver A-skránna rennur út verður að senda nýja beiðni. Báðir hafa 30 sekúndna TTL, en það er ekki það sama. Raunverulegt meðaltal TTL verður 15 sekúndur.
En bíddu! Það er enn verra. Sumir lausnarmenn haga sér mjög illa í þessum aðstæðum með tveimur tilheyrandi lágum TTL:
$ bora raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 Í CNAME github.map.fastly.net. github.map.fastly.net. 1 Í A 151.101.16.133
Level3 leysirinn keyrir líklega á BIND. Ef þú heldur áfram að senda þessa beiðni verður TTL upp á 1 alltaf skilað. Í meginatriðum, raw.githubusercontent.com er aldrei í skyndiminni.
Hér er annað dæmi um slíkt ástand með mjög vinsælu léni:
$ 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
Að minnsta kosti þrjár CNAME færslur. Já. Einn er með ágætis TTL, en hann er algjörlega ónýtur. Önnur CNAME hafa upphaflega TTL 60 sekúndur, en fyrir lén akamai.net hámarks TTL er 20 sekúndur og engin þeirra er í fasa.
Hvað með lén sem stöðugt skoða Apple tæki?
$ 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
Sama vandamál og Firefox og TTL verða fastir í 1 sekúndu oftast þegar Level3 resolver er notað.
Dropbox?
$ bora client.dropbox.com @8.8.8.8 client.dropbox.com. 7 Í CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 Í 162.125.67.3 $ bora client.dropbox.com @4.2.2.2 client.dropbox.com. 1 Í CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 Í A 162.125.64.3
Við upptökuna safebrowsing.googleapis.com TTL gildi er 60 sekúndur, eins og Facebook lén. Og aftur, frá sjónarhóli viðskiptavinarins, eru þessi gildi helminguð.
Hvað með að setja lágmarks TTL?
Með því að nota nafnið, tegund beiðninnar, TTL, og upphaflega geymdan tímastimpil, skrifaði ég handrit til að líkja eftir 1,5 milljón beiðnum sem fara í gegnum skyndiminnisleysi til að áætla magn óþarfa beiðna sem sendar voru vegna útrunninnar skyndiminnisfærslu.
47,4% beiðna bárust eftir að núverandi skráning var útrunnin. Þetta er óeðlilega hátt.
Hver verða áhrifin á skyndiminni ef lágmarks TTL er stillt?
X-ásinn er lágmarks TTL gildi. Færslur með uppruna-TTL yfir þessu gildi hafa ekki áhrif.
Y-ásinn er hlutfall beiðna frá biðlara sem hefur þegar færslu í skyndiminni, en hann er útrunninn og er að leggja fram nýja beiðni.
Hlutur „auka“ beiðna minnkar úr 47% í 36% með því einfaldlega að stilla lágmarks TTL í 5 mínútur. Með því að stilla lágmarks TTL á 15 mínútur lækkar fjöldi þessara beiðna í 29%. Lágmarks TTL 1 klukkustund lækkar þá í 17%. Verulegur munur!
Hvernig væri að breyta ekki neinu á netþjóninum, heldur setja lágmarks TTL í DNS skyndiminni viðskiptavinarins (beini, staðbundin lausn)?
Fjöldi beiðna sem krafist er lækkar úr 47% í 34% með lágmarks TTL í 5 mínútur, í 25% með að lágmarki 15 mínútur og í 13% með að lágmarki 1 klukkustund. Kannski eru 40 mínútur ákjósanlegur.
Áhrifin af þessari litlu breytingu eru gríðarleg.
Hverjar eru afleiðingarnar?
Auðvitað er hægt að færa þjónustuna yfir á nýjan skýjaveitu, nýjan netþjón, nýtt net, sem krefst þess að viðskiptavinir noti nýjustu DNS færslurnar. Og nokkuð lítill TTL hjálpar til við að gera slíka umskipti slétt og ómerkjanlega. En með umskiptum yfir í nýja innviði býst enginn við að viðskiptavinir flytji yfir í nýjar DNS-skrár innan 1 mínútu, 5 mínútna eða 15 mínútna. Að stilla lágmarks TTL á 40 mínútur í stað 5 mínútur kemur ekki í veg fyrir að notendur fái aðgang að þjónustunni.
Hins vegar mun þetta draga verulega úr leynd og bæta næði og áreiðanleika með því að forðast óþarfa beiðnir.
Auðvitað segja RFC að TTL verði að fylgja nákvæmlega. En raunin er sú að DNS kerfið er orðið of óhagkvæmt.
Ef þú ert að vinna með opinbera DNS netþjóna, vinsamlegast athugaðu TTL. Þarftu virkilega svona fáránlega lág gildi?
Auðvitað eru góðar ástæður til að setja lítil TTL fyrir DNS færslur. En ekki fyrir 75% af DNS umferð sem er nánast óbreytt.
Og ef þú af einhverjum ástæðum þarft virkilega að nota lága TTL fyrir DNS, vertu viss um að vefsvæðið þitt sé ekki með skyndiminni virkt. Af sömu ástæðum.
Ef þú ert með staðbundið DNS skyndiminni í gangi, svo sem sem gerir þér kleift að stilla lágmarks TTL, notaðu þessa aðgerð. Þetta er fínt. Ekkert slæmt mun gerast. Stilltu lágmarks TTL á um það bil 40 mínútur (2400 sekúndur) og 1 klukkustund. Alveg þokkalegt svið.
Heimild: www.habr.com