Dënda e ulët DNS është një faktor kyç për një performancë të shpejtë në internet. Për ta minimizuar, është e rëndësishme të zgjidhni me kujdes serverët DNS dhe . Por fillimisht duhet të eliminojmë kërkesat e panevojshme.
Pikërisht për këtë arsye DNS fillimisht u krijua si një protokoll me shumë keq të ruajtur. Administratorët e zonave vendosin kohën e jetës (TTL) për regjistrimet e veçanta, ndërsa rezolverët e përdorin këtë informacion për të ruajtur regjistrimet në memorie, për të shmangur trafikun e panevojshëm.
A është efikase keqburimi? Disa vjet më parë, një hulumtim i vogël i tregoi se nuk është perfekt. Le të shikojmë situatën aktuale.
Për të mbledhur informacion, kam patch-uar për të ruajtur vlerën TTL për përgjigjen. Ajo përcaktohet si TTL minimale e regjistrimeve të tij, për çdo kërkesë në hyrje. Kjo jep një pamje të mirë të shpërndarjes së TTL të trafikut real, si dhe merr parasysh popullaritetin e kërkesave të veçanta. Versioni i patch-uar i serverit punoi për disa orë.
Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение TTL (ось X — это TTL в секундах):
Если не считать незначительного бугра на 86 400 (в основном, для записей SOA), довольно очевидно, что TTL находятся в низком диапазоне. Посмотрим ближе:
Mirë, TTL mbi 1 orë nuk janë statistikorisht të rëndësishme. Pra, le të përqendrohemi në diapazonin 0−3600:
Shumica e TTL nga 0 deri në 15 minuta:
Një shumicë e madhe nga 0 deri në 5 minuta:
Kjo nuk është shumë mirë.
Shpërndarja akumuluese e bën problemin edhe më të qartë:
В половине DNS-ответов TTL составляет 1 минуту или меньше, а у трёх четвертей — 5 минут или меньше.
Por prit, në fakt është edhe më keq. Sepse këto janë TTL nga serverët autoritativë. Megjithatë, rezolverët klientë (p.sh., routerët, cache të vendosura lokale) marrin TTL nga rezolverët e sipërm, dhe ai zvogëlohet çdo sekondë.
Prandaj, klienti në fakt mund të përdorë çdo regjistrim, mesatarisht, për gjysmë të TTL-të fillestar, pas së cilës do të dërgojë një kërkesë të re.
Mund të jetë se këto TTL shumë të ulta lidhen vetëm me kërkesa të pazakonta dhe jo me site të njohura dhe API? Le të shohim:
Ось X — это TTL, ось Y — популярность запросов.
Fatkeqësisht, kërkesat më të popullarizuara gjithashtu kanë keqburimin më të dobët.
Le ta afrojmë:
Verdikti: gjendja është me të vërtetë e keqe. Ka qenë e keqe më parë, dhe tani është akoma më keq. Keqmbushja DNS ka bërë pothuajse të pahijshme. Meqë gjithnjë e më pak njerëz përdorin rezolutorin DNS të ofruesit të tyre (për arsye të drejtë), rritja e vonesës bëhet më e dukshme.
Keqmbushja DNS është e dobishme vetëm për përmbajtjen që askush nuk viziton.
Gjithashtu, vini re se software-i mund TTL-të e ulëta.
Pse është kështu?
Pse vendosen TTL kaq të ulëta për regjistrimet DNS?
- Balancuesit e ngarkesës të vjetëruar kanë mbetur me konfigurime të paracaktuara.
- Ходят мифы, что балансировка нагрузки по DNS зависит от TTL (это не так — со времён Netscape Navigator клиенты выбирают случайный IP-адрес из набора RR и прозрачно пробуют другой, если не могут подключиться)
- Administratorët duan të aplikojnë ndryshime menjëherë, sepse është më e lehtë të planifikosh.
- Administratori i serverit DNS ose balancuesit të ngarkesës e sheh si detyrë të tij të shpërndajë në mënyrë efektive konfigurimin që kërkojnë përdoruesit, dhe jo të përshpejtojë funksionimin e faqeve dhe shërbimeve.
- TTL-të e ulëta ofrojnë qetësi mendore.
- Njerëzit fillimisht vendosin TTL të ulët për të testuar dhe pastaj harrojnë t'i ndryshojnë.
Nuk e përfshiva ‘përballimin e dështimit’ në listë, sepse është gjithnjë e më pak relevante. Nëse duhet të redirigjosh përdoruesit në një rrjet tjetër vetëm për të shfaqur një faqe gabimi kur gjithçka tjetër ka dështuar, ndoshta një vonesë mbi 1 minutë është e pranueshme.
Për më tepër, një TTL një minutësh do të thotë se nëse serverat autoritativë DNS bllokohen për më shumë se 1 minutë, askush tjetër nuk do të ketë mundësi të aksesojë shërbimet e varura. Dhe mbivendosja nuk ndihmon, nëse shkaku është një gabim konfigurimi ose një thyerje. Nga ana tjetër, me TTL të arsyeshme shumë klientë do të vazhdojnë të përdorin konfigurimin e mëparshëm dhe kurrë nuk do ta vënë re.
TTL-të e ulëta janë kryesisht të fajësuar për shërbimet CDN dhe balancuesit e ngarkesës, veçanërisht kur ata bashkojnë CNAME me TTL të ulëta dhe regjistrime me TTL të tilla (por të pavarura) të ulëta:
$ 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
Çdo herë që skadon CNAME ose ndonjë nga regjistrimet A, duhet të dërgohet një kërkesë e re. Të dy kanë një TTL prej 30 sekondash, por ato nuk përputhen. TTL mesatar real do të jetë 15 sekonda.
Por prisni! Është akoma më keq. Disa rezolvues veprojnë shumë keq në një situatë të tillë me dy TTL të ulëta të lidhura:
$ drill 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
Rezolvuesi Level3, ndoshta, punon me BIND. Nëse vazhdoni të dërgoni këtë kërkesë, gjithmonë do të kthehet një TTL që është 1. Po në esencë, raw.githubusercontent.com kurrë nuk ruhet në cache.
Ja një tjetër shembull i tillë me një domen shumë të njohur:
$ 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
Të paktën tre regjistrime CNAME. Ah. Një ka një TTL të arsyeshëm, por kjo është krejtësisht e pafrytshme. Në të tjerat, TTL fillestar i CNAME është 60 sekonda, por për domenet akamai.net TTL maks është 20 sekonda, dhe asnjëra prej tyre nuk është në fazë.
Si për domenet që nënshkruajnë vazhdimisht pajisjet 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
E njëjta problem si me Firefox, dhe TTL do të ngelët shumicën e kohës në 1 sekondë kur përdoret rezolvuesi Level3.
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 IN A 162.125.64.3
Në regjistrimin safebrowsing.googleapis.com vlera TTL është 60 sekonda, si në rastin e domenëve të Facebook. Dhe, përsëri, nga këndvështrimi i klientit, këto vlera reduktohen me gjysmë.
Si përvendosjen e një TTL minimal?
Duke përdorur emrin, llojin e kërkesës, TTL dhe timestampin fillestar të ruajtur, shkrova një skript për të imituar 1,5 milion kërkesa që kalojnë përmes një rezolvuesi me cache, për të vlerësuar sasinë e kërkesave të tepërta që dërgohen për shkak të një regjistrimi të skaduar në cache.
47.4% e kërkesave u bënë pas skadimit të një regjistrimi ekzistues. Kjo është një përqindje e tepërt.
Cila do të jetë ndikimi në caching nëse vendoset një TTL minimal?
Aksi X është vlerat minimale TTL. Rekordet me TTL origjinale më të larta se kjo vlerë nuk preken.
Aksi Y është përqindja e kërkesave nga klienti, i cili tashmë ka një rekord të ruajtur, por me afatin e skadimit të kaluar dhe bën një kërkesë të re.
Shpresa e "kërkesave të tepërta" bie nga 47% në 36% me thjesht vendosjen e TTL minimale në 5 minuta. Me vendosjen e TTL minimale në 15 minuta, numri i këtyre kërkesave bie në 29%. TTL minimale në 1 orë e ul këto kërkesa në 17%. Diferenca e konsiderueshme!
Çfarë mendoni të mos ndryshoni asgjë në server, dhe përkundrazi të vendosni TTL minimale në cache-t e DNS të klientëve (rrugëtarët, rezolutorët lokalë)?
Numri i kërkesave të nevojshme bie nga 47% në 34% me vendosjen e TTL minimale në 5 minuta, në 25% me një minimum prej 15 minutash dhe në 13% me një minimum prej 1 ore. Ndoshta, vlera optimale është 40 minuta.
Ndikimi i këtij ndryshimi minimal është i madh.
Cilat janë pasojat?
Sigurisht, shërbimi mund të transferohet te një ofrues të ri të cloud, një server i ri, një rrjet i ri, duke kërkuar nga klientët të përdorin rekordet më të fundit DNS. Dhe një TTL mjaft i vogël ndihmon në një kalim të tillë pa probleme dhe pa u vënë re. Por me kalimin në infrastrukturë të re, askush nuk pret që klientët të kalojnë në rekordet e reja DNS brenda 1 minute, 5 minutave ose 15 minutash. Vendosja e një afati minimal jetëshkurtër prej 40 minutash në vend të 5 minutave nuk do të pengojë përdoruesit të kenë qasje në shërbim.
Megjithatë, kjo do të reduktojë ndjeshëm vonesën dhe do të rrisë intimitetin dhe besueshmërinë, duke shmangur kërkesat e panevojshme.
Sigurisht, RFC thonë që duhet të respektohen rreptësisht TTL. Por realiteti është se sistemi DNS ka bërë shumë të paefikas.
Nëse punoni me servera autoritativë DNS, ju lutemi kontrolloni TTL-t tuaj. A ju nevojiten vlera kaq qesharake të ulëta?
Sigurisht, ka arsye të forta për vendosjen e TTL të vogla për rekordet DNS. Por jo për 75% të trafikut DNS, i cili ndryshon praktikisht.
Dhe nëse për ndonjë arsye ju nevojitet vërtet përdorimi i TTL të ulëta për DNS, sigurohuni gjithashtu që në faqen tuaj të mos jetë aktivizuar ruajtja. Për të njëjtat arsye.
Nëse keni një cache lokale DNS, siç është , i cili ju lejon të vendosni TTL minimale, përdorni këtë funksion. Është në rregull. Asgjë e keqe nuk do ndodhë. Vendosni një TTL minimal midis 40 minutash (2400 sekonda) dhe 1 ore. Një gamë krejtësisht e arsyeshme.
Burimi: habr.com
