Maža DNS delsa yra greito naršymo internete raktas. Norint jį sumažinti, svarbu atidžiai pasirinkti DNS serverius ir . Tačiau pirmas žingsnis yra atsikratyti nenaudingų užklausų.
Štai kodėl DNS iš pradžių buvo sukurtas kaip labai talpinamas protokolas. Zonos administratoriai nustato atskirų įrašų gyvavimo laiką (TTL), o sprendėjai naudoja šią informaciją saugodami įrašus atmintyje, kad išvengtų nereikalingo srauto.
Ar talpyklos kaupimas veiksmingas? Prieš porą metų mano nedidelis tyrimas parodė, kad jis nebuvo tobulas. Pažvelkime į dabartinę padėtį.
Norėdami rinkti informaciją, pataisiau kad išsaugotumėte atsakymo TTL reikšmę. Jis apibrėžiamas kaip minimalus kiekvienos gaunamos užklausos įrašų TTL. Tai suteikia gerą apžvalgą apie realaus srauto TTL paskirstymą, taip pat atsižvelgiama į individualių užklausų populiarumą. Pataisyta serverio versija veikė kelias valandas.
Gautą duomenų rinkinį sudaro 1 583 579 įrašai (pavadinimas, qtype, TTL, laiko žyma). Štai bendras TTL pasiskirstymas (X ašis yra TTL sekundėmis):
Neskaitant nedidelio 86 smūgio (daugiausia SOA įrašams), gana aišku, kad TTL yra žemame diapazone. Pažvelkime atidžiau:
Gerai, ilgesni nei 1 valanda TTL nėra statistiškai reikšmingi. Tada sutelkime dėmesį į diapazoną 0–3600:
Dauguma TTL yra nuo 0 iki 15 minučių:
Didžioji dauguma yra nuo 0 iki 5 minučių:
Tai nėra labai gerai.
Dėl kaupiamojo pasiskirstymo problema tampa dar akivaizdesnė:
Pusės DNS atsakymų TTL yra 1 minutė arba trumpesnė, o trijų ketvirtadalių TTL yra 5 minutės ar trumpesnė.
Bet palaukite, iš tikrųjų yra blogiau. Juk tai TTL iš autoritetingų serverių. Tačiau klientų sprendėjai (pvz., maršrutizatoriai, vietinės talpyklos) gauna TTL iš aukštesniojo srauto sprendėjų, ir jis mažėja kas sekundę.
Taigi klientas, prieš išsiųsdamas naują užklausą, iš tikrųjų gali naudoti kiekvieną įrašą vidutiniškai už pusę pradinio TTL.
Galbūt šie labai žemi TTL taikomi tik neįprastoms užklausoms, o ne populiarioms svetainėms ir API? Pažiūrėkime:
X ašis yra TTL, Y ašis – užklausos populiarumas.
Deja, populiariausios užklausos taip pat yra prasčiausiai talpinamos.
Padidinkime:
Verdiktas: tai tikrai blogai. Jau anksčiau buvo blogai, bet pasidarė dar blogiau. DNS talpyklos kaupimas tapo beveik nenaudingas. Kadangi mažiau žmonių naudojasi savo IPT DNS sprendiniu (dėl rimtų priežasčių), delsos padidėjimas tampa labiau pastebimas.
DNS talpyklos kaupimas tapo naudingas tik turiniui, kurio niekas nelanko.
Taip pat atkreipkite dėmesį, kad programinė įranga gali interpretuoti žemus TTL.
Kodėl taip yra?
Kodėl DNS įrašams nustatytas toks žemas TTL?
- Senieji apkrovos balansavimo įrenginiai buvo palikti su numatytaisiais nustatymais.
- Sklando mitai, kad DNS apkrovos balansavimas priklauso nuo TTL (tai netiesa – nuo „Netscape Navigator“ laikų klientai pasirinko atsitiktinį IP adresą iš RR rinkinio ir skaidriai bandė kitą, jei negali prisijungti)
- Administratoriai nori nedelsiant pritaikyti pakeitimus, todėl lengviau planuoti.
- DNS serverio arba apkrovos balansuotojo administratorius mano, kad jo užduotis yra efektyviai įdiegti konfigūraciją, kurios reikalauja vartotojai, o ne pagreitinti svetaines ir paslaugas.
- Žemi TTL suteikia jums ramybę.
- Žmonės iš pradžių nustato žemus TTL testavimui, o paskui pamiršta juos pakeisti.
Į sąrašą neįtraukiau „perdengimo“, nes jis tampa vis mažiau aktualus. Jei reikia nukreipti vartotojus į kitą tinklą vien tam, kad būtų rodomas klaidos puslapis, kai absoliučiai viskas sugenda, tikriausiai priimtinas delsimas daugiau nei 1 minutę.
Be to, vienos minutės TTL reiškia, kad jei autoritetingi DNS serveriai bus užblokuoti ilgiau nei 1 minutę, niekas kitas negalės pasiekti priklausomų paslaugų. Atleidimas nepadės, jei priežastis yra konfigūracijos klaida arba įsilaužimas. Kita vertus, turėdami pagrįstus TTL, daugelis klientų ir toliau naudos ankstesnę konfigūraciją ir niekada nieko nepastebės.
CDN paslaugos ir apkrovos balansavimo priemonės yra daugiausia kaltos dėl žemų TTL, ypač kai jie sujungia CNAME su mažais TTL ir įrašus su vienodai žemais (bet nepriklausomais) 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
Kai baigiasi CNAME arba bet kurio A įrašo galiojimo laikas, turi būti išsiųsta nauja užklausa. Abu turi 30 sekundžių TTL, bet tai nėra tas pats. Tikrasis vidutinis TTL bus 15 sekundžių.
Bet palauk! Tai dar blogiau. Kai kurie sprendėjai šioje situacijoje elgiasi labai blogai su dviem susijusiais žemais TTL:
$ grąžtas raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
3 lygio sprendiklis tikriausiai veikia BIND. Jei ir toliau siųsite šią užklausą, visada bus grąžintas 1 TTL. Iš esmės raw.githubusercontent.com niekada nėra talpykloje.
Štai dar vienas tokios situacijos pavyzdys su labai populiariu domenu:
$ 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
Bent trys CNAME įrašai. Ai. Vienas turi tinkamą TTL, bet jis visiškai nenaudingas. Kitų CNAME pradinis TTL yra 60 sekundžių, bet domenams akamai.net maksimalus TTL yra 20 sekundžių ir nė vienas iš jų nėra fazėje.
O domenai, kurie nuolat apklausia „Apple“ įrenginius?
$ 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
Ta pati problema kaip „Firefox“ ir „TTL“ dažniausiai užstrigs 1 sekundėje, kai bus naudojamas 3 lygio sprendiklis.
Dropbox?
$ gręžimas 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 $ gręžimo 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
Prie įrašo safebrowsing.googleapis.com TTL reikšmė yra 60 sekundžių, kaip ir „Facebook“ domenuose. Ir vėlgi, kliento požiūriu, šios vertės sumažinamos perpus.
O kaip nustatyti minimalų TTL?
Naudodamas pavadinimą, užklausos tipą, TTL ir iš pradžių saugomą laiko žymą, parašiau scenarijų, skirtą imituoti 1,5 milijono užklausų, perduodamų per talpyklos sprendiklį, kad įvertinčiau nereikalingų užklausų, išsiųstų dėl pasibaigusio talpyklos įrašo, kiekį.
47,4 % prašymų buvo pateikti pasibaigus esamo įrašo galiojimui. Tai yra nepagrįstai daug.
Koks bus poveikis talpyklai, jei bus nustatytas minimalus TTL?
X ašis yra mažiausios TTL reikšmės. Įrašai, kurių šaltinio TTL viršija šią vertę, neturi įtakos.
Y ašis yra kliento, kuris jau turi talpykloje saugomą įrašą, bet pasibaigė jo galiojimo laikas ir pateikia naują užklausą, užklausų procentas.
„Papildomų“ užklausų dalis sumažinama nuo 47% iki 36%, paprasčiausiai nustatant minimalų TTL iki 5 minučių. Nustačius minimalų TTL iki 15 minučių, šių užklausų skaičius sumažėja iki 29%. Minimalus 1 valandos TTL sumažina juos iki 17%. Reikšmingas skirtumas!
Kaip nieko nekeisti serverio pusėje, o vietoj to nustatyti minimalų TTL kliento DNS talpyklose (maršrutizatoriuose, vietiniuose sprendimuose)?
Reikalingų užklausų skaičius sumažėja nuo 47 % iki 34 %, kai TTL yra ne trumpesnis nei 5 minutės, iki 25 % su mažiausiai 15 minučių ir iki 13 % per mažiausiai 1 valandą. Galbūt 40 minučių yra optimalus.
Šio nedidelio pakeitimo poveikis yra didžiulis.
Kokios pasekmės?
Žinoma, paslauga gali būti perkelta į naują debesies tiekėją, naują serverį, naują tinklą, reikalaujant, kad klientai naudotų naujausius DNS įrašus. Ir gana mažas TTL padeda tokį perėjimą atlikti sklandžiai ir nepastebimai. Tačiau perėjus prie naujos infrastruktūros niekas nesitiki, kad klientai pereis prie naujų DNS įrašų per 1 minutę, 5 minutes ar 15 minučių. Nustačius minimalų TTL iki 40 minučių, o ne 5 minutes, vartotojai negalės pasiekti paslaugos.
Tačiau tai žymiai sumažins delsą ir pagerins privatumą bei patikimumą, nes išvengsite nereikalingų užklausų.
Žinoma, RFC sako, kad TTL reikia griežtai laikytis. Tačiau realybė tokia, kad DNS sistema tapo pernelyg neefektyvi.
Jei dirbate su autoritetingais DNS serveriais, patikrinkite savo TTL. Ar tikrai reikia tokių juokingai žemų vertybių?
Žinoma, yra rimtų priežasčių nustatyti mažus DNS įrašų TTL. Bet ne 75% DNS srauto, kuris išlieka beveik nepakitęs.
Ir jei dėl kokių nors priežasčių jums tikrai reikia naudoti žemus TTL DNS, tuo pačiu metu įsitikinkite, kad jūsų svetainėje nėra įjungtas talpyklos saugojimas. Dėl tų pačių priežasčių.
Jei veikia vietinė DNS talpykla, pvz kuri leidžia nustatyti minimalius TTL, naudokite šią funkciją. Tai yra gerai. Nieko blogo nenutiks. Nustatykite minimalų TTL į maždaug 40 minučių (2400 sekundžių) ir 1 valandą. Ganėtinai pagrįstas diapazonas.
Šaltinis: www.habr.com