Nizka zakasnitev DNS je ključna za hitro brskanje po internetu. Da bi ga zmanjšali, je pomembno skrbno izbrati strežnike DNS in . Toda prvi korak je, da se znebite neuporabnih poizvedb.
Zato je bil DNS prvotno zasnovan kot protokol z visoko stopnjo predpomnilnika. Skrbniki območij nastavijo čas življenja (TTL) za posamezne vnose, razreševalci pa te informacije uporabljajo pri shranjevanju vnosov v pomnilnik, da se izognejo nepotrebnemu prometu.
Je predpomnjenje učinkovito? Pred nekaj leti je moja majhna raziskava pokazala, da ni popoln. Poglejmo si trenutno stanje.
Za zbiranje informacij sem zakrpal da shranite vrednost TTL za odgovor. Definiran je kot najmanjši TTL njegovih zapisov za vsako dohodno zahtevo. To daje dober pregled nad TTL porazdelitvijo realnega prometa in upošteva tudi priljubljenost posameznih zahtevkov. Popravljena različica strežnika je delovala nekaj ur.
Nastali niz podatkov je sestavljen iz 1 zapisov (ime, qtype, TTL, časovni žig). Tukaj je splošna porazdelitev TTL (os X je TTL v sekundah):
Poleg manjšega padca pri 86 (večinoma za zapise SOA) je precej jasno, da so TTL v nizkem območju. Poglejmo si pobližje:
V redu, TTL, daljši od 1 ure, niso statistično pomembni. Nato se osredotočimo na območje 0–3600:
Večina TTL-jev je od 0 do 15 minut:
Velika večina je od 0 do 5 minut:
Ni zelo dobro.
Zaradi kumulativne porazdelitve je problem še bolj očiten:
Polovica odgovorov DNS ima TTL 1 minuto ali manj, tri četrtine pa 5 minut ali manj.
Toda počakajte, v resnici je še huje. Navsezadnje je to TTL iz avtoritativnih strežnikov. Vendar odjemalski razreševalci (npr. usmerjevalniki, lokalni predpomnilniki) prejmejo TTL od zgornjih razreševalcev in se zmanjša vsako sekundo.
Tako lahko odjemalec dejansko uporabi vsak vnos v povprečju za polovico prvotnega TTL, preden pošlje novo zahtevo.
Mogoče ti zelo nizki TTL veljajo samo za neobičajne zahteve in ne za priljubljena spletna mesta in API-je? Poglejmo si:
Os X je TTL, os Y je priljubljenost poizvedbe.
Na žalost je najbolj priljubljene poizvedbe tudi najslabše za predpomnilnik.
Povečajmo:
Razsodba: res je slabo. Hudo je bilo že prej, pa je postalo še slabše. Predpomnjenje DNS je postalo tako rekoč neuporabno. Ker manj ljudi uporablja razreševalec DNS svojega ponudnika internetnih storitev (zaradi dobrih razlogov), postane povečanje zakasnitve bolj opazno.
Predpomnjenje DNS je postalo uporabno samo za vsebine, ki jih nihče ne obišče.
Upoštevajte tudi, da lahko programska oprema interpretirati nizke TTL.
Zakaj tako?
Zakaj so zapisi DNS nastavljeni na tako nizek TTL?
- Podedovani izravnalniki obremenitve so ostali s privzetimi nastavitvami.
- Obstajajo miti, da je uravnoteženje obremenitve DNS odvisno od TTL (to ni res - od časov Netscape Navigatorja so odjemalci izbrali naključni naslov IP iz nabora RR-jev in pregledno poskusili drugega, če se ne morejo povezati)
- Skrbniki želijo spremembe uveljaviti takoj, zato je lažje načrtovati.
- Skrbnik strežnika DNS ali izravnalnika obremenitve vidi svojo nalogo kot učinkovito uvajanje konfiguracije, ki jo uporabniki zahtevajo, in ne pospeševanje spletnih mest in storitev.
- Nizki TTL vam zagotavljajo mir.
- Ljudje sprva nastavijo nizke TTL za testiranje in jih nato pozabijo spremeniti.
"Failover" nisem uvrstil na seznam, ker je vedno manj relevanten. Če morate uporabnike preusmeriti v drugo omrežje samo zato, da prikažete stran z napako, ko je absolutno vse drugo pokvarjeno, je zamuda, daljša od 1 minute, verjetno sprejemljiva.
Poleg tega enominutni TTL pomeni, da če so avtoritativni strežniki DNS blokirani za več kot 1 minuto, nihče drug ne bo mogel dostopati do odvisnih storitev. In redundanca ne bo pomagala, če je vzrok konfiguracijska napaka ali vdor. Po drugi strani pa bo z razumnimi TTL številni odjemalci še naprej uporabljali prejšnjo konfiguracijo in nikoli ne opazijo ničesar.
Storitve CDN in izravnalniki obremenitve so v veliki meri krivi za nizke TTL, zlasti če združujejo CNAME z nizkimi TTL in zapise z enako nizkimi (vendar neodvisnimi) 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
Kadar koli poteče zapis CNAME ali kateri koli od zapisov A, je treba poslati novo zahtevo. Oba imata 30 sekundni TTL, vendar ni enak. Dejanski povprečni TTL bo 15 sekund.
Ampak počakaj! Še huje je. Nekateri razreševalci se v tej situaciji obnašajo zelo slabo z dvema povezanima nizkima TTL:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 V A 151.101.16.133
Reševalec Level3 verjetno deluje na BIND. Če nadaljujete s pošiljanjem te zahteve, bo vedno vrnjen TTL 1. V bistvu, raw.githubusercontent.com ni nikoli predpomnjen.
Tu je še en primer takšne situacije z zelo priljubljeno domeno:
$ 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
Vsaj trije zapisi CNAME. Aja. Eden ima spodoben TTL, vendar je popolnoma neuporaben. Drugi CNAME imajo začetni TTL 60 sekund, vendar za domene akamai.net največji TTL je 20 sekund in nobena od njih ni v fazi.
Kaj pa domene, ki nenehno anketirajo naprave 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
Ista težava kot pri Firefoxu in TTL bo ob uporabi razreševalnika Level1 večino časa obstal na 3 sekundi.
Dropbox?
$ drill 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 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 V A 162.125.64.3
Na snemanju safebrowsing.googleapis.com Vrednost TTL je 60 sekund, kot pri Facebook domenah. In spet, z vidika naročnika so te vrednosti prepolovljene.
Kaj pa nastavitev minimalnega TTL?
Z uporabo imena, vrste zahteve, TTL in prvotno shranjenega časovnega žiga sem napisal skript za simulacijo 1,5 milijona zahtev, ki gredo skozi razreševalec predpomnjenja, da ocenim količino nepotrebnih zahtev, poslanih zaradi potečenega vnosa v predpomnilnik.
47,4 % zahtevkov je bilo vloženih po poteku obstoječe evidence. To je nerazumno visoko.
Kakšen bo vpliv na predpomnjenje, če je nastavljen najmanjši TTL?
Os X so najmanjše vrednosti TTL. To ne vpliva na zapise z izvornimi TTL-ji nad to vrednostjo.
Os Y je odstotek zahtev odjemalca, ki že ima predpomnjen vnos, vendar je potekel in postavlja novo zahtevo.
Delež "dodatnih" zahtev se zmanjša s 47 % na 36 % s preprosto nastavitvijo minimalnega TTL na 5 minut. Z nastavitvijo minimalnega TTL na 15 minut se število teh zahtev zmanjša na 29 %. Najmanjši TTL 1 ure jih zmanjša na 17 %. Bistvena razlika!
Kaj pa če ne spremenite ničesar na strani strežnika, temveč namesto tega nastavite najmanjši TTL v predpomnilnikih DNS odjemalcev (usmerjevalniki, lokalni razreševalci)?
Število zahtevanih zahtev se zmanjša s 47 % na 34 % z minimalnim TTL 5 minut, na 25 % z najmanj 15 minutami in na 13 % z najmanj 1 uro. Morda je 40 minut optimalno.
Vpliv te majhne spremembe je ogromen.
Kakšne so posledice?
Seveda je storitev mogoče premakniti k novemu ponudniku oblaka, novemu strežniku, novemu omrežju, pri čemer morajo stranke uporabljati najnovejše zapise DNS. In dokaj majhen TTL pomaga, da je tak prehod gladek in neopazen. Toda s prehodom na novo infrastrukturo nihče ne pričakuje, da bodo stranke migrirale na nove zapise DNS v 1 minuti, 5 minutah ali 15 minutah. Nastavitev najnižjega TTL na 40 minut namesto 5 minut uporabnikom ne bo preprečila dostopa do storitve.
Vendar bo to znatno zmanjšalo zakasnitev ter izboljšalo zasebnost in zanesljivost z izogibanjem nepotrebnim zahtevam.
Seveda RFC pravijo, da je treba TTL strogo upoštevati. Toda v resnici je sistem DNS postal preveč neučinkovit.
Če delate z avtoritativnimi strežniki DNS, preverite svoje TTL-je. Ali res potrebujete tako smešno nizke vrednosti?
Seveda obstajajo dobri razlogi za nastavitev majhnih TTL za zapise DNS. Vendar ne za 75 % prometa DNS, ki ostaja skoraj nespremenjen.
In če iz nekega razloga res morate uporabiti nizke TTL za DNS, se hkrati prepričajte, da vaše spletno mesto nima omogočenega predpomnjenja. Iz istih razlogov.
Če imate zagnan lokalni predpomnilnik DNS, kot npr ki vam omogoča nastavitev minimalnih TTL, uporabite to funkcijo. To je v redu. Nič hudega se ne bo zgodilo. Najmanjši TTL nastavite na približno 40 minut (2400 sekund) in 1 uro. Kar razumen razpon.
Vir: www.habr.com