Shfletuesi Chromium, projekti open-source që zhvillohet aktivisht dhe që shërben si bazë për Google Chrome dhe Microsoft Edge-in e ri, ka tërhequr vëmendje serioze negative për shkak të një veçorie të krijuar me qëllime të mira: ajo kontrollon nëse ofruesi i internetit i përdoruesit po «rrëmben» rezultatet e kërkesave për domene që nuk ekzistojnë.
, i cili krijon kërkesa të rreme për «domene» të rastësishme, ekzistenca e të cilave është statistikisht shumë e pamundur, është përgjegjës për afërsisht gjysmën e trafikut total që marrin serverët rrënjë DNS në mbarë botën. Inxhinieri i Verisign, Matt Thomas, shkroi një postim të gjatë në blogun e APNIC, ku përshkruan problemin dhe vlerëson përmasat e tij.
Si kryhet zakonisht zgjidhja DNS
Këta serverë janë instanca më e lartë ku duhet të drejtoheni për zgjidhjen e .com, .net e kështu me radhë, në mënyrë që t’ju tregojnë se frglxrtmpuf nuk është një domen i nivelit të lartë (TLD).
DNS, ose Domain Name System («sistemi i emrave të domeneve»), është sistemi që u mundëson kompjuterëve të shndërrojnë emra domenesh të lehtë për t’u mbajtur mend, si arstechnica.com, në adresa IP shumë më pak të përshtatshme, si p.sh. 3.128.236.93. Pa DNS, interneti nuk do të mund të ekzistonte në një formë të përdorshme për njerëzit, prandaj ngarkesa e panevojshme mbi infrastrukturën e nivelit të lartë është një problem real.
Për ngarkimin e një faqeje të vetme moderne të internetit mund të nevojitet një numër i paimagjinueshëm operacionesh kërkimi DNS. Për shembull, kur analizuam faqen kryesore të ESPN, numëruam 93 emra domenesh të veçantë, nga a.espncdn.com deri te z.motads.com. Të gjithë ata janë të nevojshëm që faqja të ngarkohet plotësisht!
Që sistemi i kërkimit të mund ta përballojë një ngarkesë të tillë, ndërsa duhet t’i shërbejë të gjithë botës, DNS është projektuar si një hierarki shumë-nivelëshe. Në majë të kësaj piramide ndodhen serverët rrënjë — çdo domen i nivelit të lartë, si p.sh. .com, ka familjen e vet të serverëve, të cilët janë instanca më e lartë për çdo domen poshtë tyre. Një nivel më lart se këta serverë ndodhen vetë serverët rrënjë, nga a.root-servers.net në m.root-servers.net.
Sa shpesh ndodh kjo?
Falë hierarkisë shumë-nivelëshe të cache-it në infrastrukturën DNS, vetëm një përqindje shumë e vogël e kërkesave globale DNS arrin te serverët rrënjë. Shumica e përdoruesve e marrin informacionin e zgjidhësit DNS drejtpërdrejt nga ofruesi i tyre. Kur pajisja e përdoruesit duhet të mësojë si të arrijë një faqe të caktuar, kërkesa fillimisht dërgohet te serveri DNS i menaxhuar nga ky ofrues lokal. Nëse serveri lokal DNS nuk e di përgjigjen, ai e përcjell kërkesën te “serverët e ridrejtimit” të vet (nëse janë të përcaktuar).
Nëse as serveri DNS i ofruesit lokal dhe as “serverët e ridrejtimit” të përcaktuar në konfigurimin e tij nuk kanë një përgjigje të ruajtur në cache, kërkesa ngjitet drejtpërdrejt te serveri autoritativ i domenit më sipër se ai që po përpiqeni të zgjidhni. Në rastin e domen.com kjo do të thotë që kërkesa dërgohet te serverët autoritativë të vetë domenit com, të cilët ndodhen në adresën gtld-servers.net.
Sistemi gtld-servers, te i cili u dërgua kërkesa, i përgjigjet asaj me një listë të serverëve autoritativë të emrave për domenin domen.com, si dhe me të paktën një regjistrim glue që përmban adresën IP të një serveri të tillë emrash. Më pas përgjigjet zbresin përgjatë zinxhirit — secili server ridrejtimi ia kalon këto përgjigje serverit më poshtë që i kishte kërkuar, derisa përgjigjja më në fund arrin te serveri i ofruesit lokal dhe te kompjuteri i përdoruesit. Gjatë këtij procesi, të gjithë e ruajnë këtë përgjigje në cache që të mos ngarkohen pa nevojë sistemet e niveleve më të larta.
Në shumicën e rasteve, regjistrimet e serverëve të emrave për domen.com do të jenë tashmë të ruajtura në cache në një nga këta serverë ridrejtimi, kështu që serverët rrënjë nuk preken fare. Megjithatë, deri tani po flasim për formën e zakonshme të URL-së — atë që zgjidhet në një faqe standarde web. Kërkesat e Chrome i përkasin nivelit më sipër nën këtij, në shkallën e vetë klasterëve root-servers.net.
Chromium dhe kontrolli i rrëmbimit të NXDomain
Kontrollet e Chromium “a nuk po më mashtron ky server DNS?” përbëjnë pothuajse gjysmën e gjithë trafikut që arrin te klasteri i serverëve rrënjë DNS të Verisign.
Shfletuesi Chromium, projekti mëmë i Google Chrome, Microsoft Edge të ri dhe i një numri të madh shfletuesish më pak të njohur, synon t’u ofrojë përdoruesve thjeshtësi në kërkim përmes një fushe të vetme, që nganjëherë quhet «Omnibox». Me fjalë të tjera, përdoruesi shkruan si URL reale, ashtu edhe kërkesa për motorin e kërkimit, në të njëjtën fushë teksti në krye të dritares së shfletuesit. Duke e thjeshtuar edhe më tej, ai gjithashtu nuk e detyron përdoruesin të shkruajë pjesën e URL-së me http:// ose https://.
Sado i përshtatshëm që të jetë ky qasje, ai kërkon që shfletuesi të kuptojë se çfarë duhet të konsiderohet URL dhe çfarë — kërkesë kërkimi. Në shumicën e rasteve kjo është mjaft e qartë — për shembull, një varg me hapësira nuk mund të jetë URL. Por gjithçka mund të bëhet më e ndërlikuar kur merren parasysh intranetet — rrjete private që mund të përdorin edhe domene private të nivelit të lartë për të zgjidhur faqe reale interneti.
Nëse një përdorues në intranetin e kompanisë së tij shkruan «marketing», dhe në intranetin e kompanisë ekziston një faqe e brendshme interneti me të njëjtin emër, atëherë Chromium shfaq një dritare informuese duke pyetur përdoruesin nëse dëshiron të kërkojë për «marketing», apo të shkojë te https://marketing. Kjo ende është e pranueshme, por shumë ofrues interneti dhe ofrues të rrjeteve publike Wi‑Fi «rrëmbejnë» çdo URL të shkruar me gabim, duke e ridrejtuar përdoruesin në ndonjë faqe të mbushur me banerë reklamash.
Gjenerim i rastësishëm
Zhvilluesit e Chromium nuk donin që përdoruesit në rrjete të zakonshme të shihnin sa herë që kërkonin një fjalë të vetme një dritare informuese që i pyeste se çfarë kishin parasysh, prandaj zbatuan një test: gjatë nisjes së shfletuesit ose kur ndërrohet rrjeti, Chromium kryen operacione kërkimi DNS për tre «domene» të nivelit të lartë të gjeneruara rastësisht, me gjatësi nga shtatë deri në pesëmbëdhjetë karaktere. Nëse cilatdo dy nga këto kërkesa kthehen me të njëjtën adresë IP, atëherë Chromium supozon se rrjeti lokal «rrëmben» gabimet NXDOMAIN, të cilat ai duhet t’i marrë, prandaj shfletuesi, deri në njoftim të mëtejshëm, i konsideron të gjitha kërkesat e futura me një fjalë si tentativa kërkimi.
Për fat të keq, në rrjetet që jo rrëmbejnë rezultatet e kërkesave DNS, këto tri operacione zakonisht ngrihen deri në majë, deri te vetë serverët rrënjë të emrave: serveri lokal nuk di si ta zgjidhë qwajuixk, prandaj ia përcjell këtë kërkesë serverit të vet të përcjelljes, i cili bën të njëjtën gjë, derisa më në fund, a.root-servers.net ose një nga «vëllezërit» e tij të detyrohet të thotë «Na vjen keq, por ky nuk është një domen».
Meqenëse ekzistojnë afërsisht 1,67*10^21 emra domenesh të rremë të mundshëm me gjatësi nga shtatë deri në pesëmbëdhjetë karaktere, më së shpeshti secili nga këto prova, të kryera në një rrjet «të ndershëm», arrin deri te serveri rrënjë. Kjo përbën plot gjysmën e ngarkesës totale mbi DNS-të rrënjë, nëse u besohet statistikave nga ajo pjesë e klasterëve root-servers.net, që i përkasin kompanisë Verisign.
Historia përsëritet
Nuk është hera e parë që një projekt i krijuar me qëllimet më të mira ose pothuajse e ka mbingarkuar një burim publik me trafik të panevojshëm — kjo na kujtoi menjëherë historinë e gjatë dhe të trishtë të D-Link dhe serverit NTP (Network Time Protocol) të Poul-Henning Kamp nga mesi i viteve 2000.
Në vitin 2005, zhvilluesi i FreeBSD, Poul-Henning, i cili zotëronte gjithashtu të vetmin server Network Time Protocol të nivelit Stratum 1 në Danimarkë, mori një faturë të papritur dhe të madhe për trafikun e transmetuar. Shkurt, arsyeja ishte se zhvilluesit e D-Link kishin përfshirë adresat e serverëve NTP Stratum 1, përfshirë edhe serverin e Kamp, në firmware-in e linjës së switch-eve, ruterëve dhe pikave të aksesit të kompanisë. Kjo e rriti menjëherë nëntëfish trafikun e serverit të Kamp, gjë që bëri që Danish Internet Exchange (pika daneze e shkëmbimit të trafikut të internetit) t’ia ndryshonte tarifën nga «Falas» në «9 000 dollarë në vit».
Problemi nuk ishte se kishte tepër shumë ruterë D-Link, por se ata «shkelën hierarkinë». Pothuajse njësoj si DNS, edhe NTP duhet të funksionojë në formë hierarkike — serverët e nivelit Stratum 0 ua transmetojnë informacionin serverëve Stratum 1, të cilët ua transmetojnë informacionin serverëve Stratum 2, dhe kështu me radhë, poshtë në hierarki. Një ruter i zakonshëm shtëpie, switch ose pikë aksesi si ato ku D-Link kishte futur adresat e serverëve NTP, duhej t’i dërgonte kërkesat te një server Stratum 2 ose Stratum 3.
Projekti Chromium, me shumë gjasë me qëllimet më të mira, e përsëriti problemin e NTP në kontekstin e DNS, duke i ngarkuar serverët rrënjë të internetit me kërkesa që ata nuk do të duhej t’i përpunonin kurrë.
Ka shpresë për një zgjidhje të shpejtë
Në projektin Chromium ka një të hapur , i cili për të zgjidhur këtë problem kërkon çaktivizimin si parazgjedhje të Intranet Redirect Detector. Duhet t’i jepet merita projektit Chromium: defekti u zbulua përpara se, Matt Thomas nga Verisign t’i kushtonte vëmendje të madhe me e tij në blogun e APNIC. Defekti u raportua në qershor, por mbeti në harresë deri te postimi i Thomas; pas publikimit të tij, ai kaloi nën vëzhgim të kujdesshëm.
Ka shpresë që problemi të zgjidhet së shpejti dhe serverët rrënjë DNS të mos kenë më nevojë t’u përgjigjen çdo ditë rreth 60 miliardë kërkesave fiktive.
SOF6
Serverë epikë — është ose Linux me procesorë të fuqishëm të familjes AMD EPYC dhe disqe shumë të shpejta Intel NVMe. Nxitoni të porosisni!
Burimi: habr.com
