Shfletuesi Chromium, një projekt open-source në zhvillim aktiv që është prindi i Google Chrome dhe Microsoft Edge të ri, ka tërhequr vëmendje negative për shkak të një funksioni që ishte menduar me anë të qëllimesh të mira: ai kontrollon nëse ofruesi po 'pengon' përdoruesin me rezultate të paekzistuese për domainet.
, i cili krijon kërkesa false për 'domainet' rastësore, ekzistenca e të cilave është statistike shumë e pakët, është përgjegjës për rreth gjysmën e trafikut total që merrin serverët DNS rrënjësorë në të gjithë botën. Inxhinieri i Verisign, Matt Thomas, shkroi një postim të gjerë në blogun APNIC duke përshkruar problemin dhe duke e vlerësuar shkallën e tij.
Si zakonisht kryhet transformimi DNS
Këto servera janë autoriteti më i lartë ku duhet të adresohet për zgjidhjen e .com, .net etj., për t'ju njoftuar se frglxrtmpuf nuk është një domain i nivelit të lartë (TLD).
DNS, ose Sistemi i Emrave të Domenit («sistemi i emrave të domenit») — është një sistem që mundëson kompjuterët të transformojnë emrat e domeneve të lehtë për t'u mbajtur mend, si arstechnica.com, në adresa IP shumë më pak të përshtatshme, si 3.128.236.93. Pa DNS, Interneti nuk do të ekzistonte në një format që është i përshtatshëm për njerëzit, kështu që ngarkesa e panevojshme në infrastrukturën e nivelit të lartë është një problem real.
Për ngarkimin e një faqe moderne mund të kërkohet një numër i pabesueshëm operacionesh kërkimi DNS. Për shembull, kur analizuam faqen kryesore të ESPN, numëruam 93 emra të ndryshëm domenesh, nga a.espncdn.com deri te z.motads.com. Të gjithë ata janë të nevojshëm për ngarkimin e plotë të faqes!
Për të përballuar një ngarkesë të tillë, sistemi i kërkimit, i cili duhet të shërbejë të gjithë botën, DNS është projektuar si një hierarki multi-nivel. Në majë të kësaj piramide ndodhen serverat rrënjësorë — çdo domen i nivelit të lartë, si .com, ka familjen e tij të serverëve, që janë autoriteti më i lartë për çdo domen poshtë tyre. Një nivel më lart këtyre serverëve janë vetë serverat rrënjësorë, nga a.root-servers.net deri te m.root-servers.net.
Sa shpesh ndodhin këto?
Falë hierarkisë shumënivëlëshe të memorizimit në infrastrukturën DNS, një përqindje shumë e vogël e kërkesave DNS globale arrin te serverët rrënjësorë. Shumica e njerëzve merr informacionin e rezolvuesit DNS direkt nga ofruesi i tyre. Kur pajisja e përdoruesit ka nevojë të mësojë se si të arrijë në një faqe të caktuar, kërkesa fillimisht dërgohet te serveri DNS menaxhuar nga ky ofrues lokal. Nëse serveri lokal DNS nuk e di përgjigjen, ai e redirecton kërkesën te 'serverët e përcjelljes' të tij (në rast se ata janë të specifikuar).
Nëse as serveri lokal DNS i ofruesit, as serverët e përcjelljes të specifikuar në konfigurimin e tij nuk kanë një përgjigje të memorizuar, kërkesa ngjitet direkt te serveri autoritar i domenit më sipër atij që po përpiqeni ta konvertoni. Në rastin e domen.com kjo do të thotë se kërkesa dërgohet te serverët autoritarë të vetë domenit comtë cilët ndodhen në adresën gtld-servers.net.
Sistemi gtld-servers, i cili u kërkua, përgjigjet me një listë serverësh emrash të akredituar për domenin domen.com, si dhe me të paktën një regjistrim lidhës që përmban adresën IP të njërit prej këtyre serverëve emrash. Më pas, përgjigjet kalojnë më poshtë në zinxhir - çdo server i përcjelljes dërgon këto përgjigje poshtë atij serveri që i kërkoi, derisa përgjigja të arrijë përfundimisht te serveri i ofruesit lokal dhe kompjuterit të përdoruesit. Të gjithë ata e ruajnë këtë përgjigje në cache, për të mos u shqetësuar sistemet në nivele më të larta.
Në shumicën e rastëve, regjistrimet e serverëve të emrave për domen.com do të jenë tashmë të ruajtura në një prej këtyre serverëve të përcjelljes, prandaj serverët rrënjësorë nuk shqetësohen. Megjithatë, përsa i përket formatit që njohim të URL-së - ai që transformohet në një faqe të zakonshme të internetit. Kërkesat në Chrome i nënshtrohen nivelit më sipër të këtij, në shkallën e vetë grupeve root-servers.net.
Chromium dhe kontrolli i mashtresës NXDomain
Kontrolli në Chromium "nuk po më mashtrojnë ky DNS-server?" përbën pothuajse gjysmë e gjithë trafikut që arrin grupit të serverëve rrënjësorë të DNS të Verisign.
Shfletuesi Chromium, projekti prind i Google Chrome, i ri Microsoft Edge dhe numri i pafundmë i shfletuesve të tjerë më pak të njohur, synon të ofrojë përdoruesve thjeshtësinë e kërkimit në një fushë, shpesh të quajtur "Omnibox". Në fjalë të tjera, përdoruesi fut si URL reale ashtu edhe kërkesat për motorin e kërkimit në të njëjtën fushë tekstuale në krye të dritares së shfletuesit. Duke bërë një hap tjetër drejt thjeshtësimit, ai gjithashtu nuk e detyron përdoruesin të fusë pjesën e URL-së me http:// ose https://.
Sa i lehtë që të jetë, një qasje e tillë kërkon që shfletuesi të kuptojë se çfarë duhet të shqyrtohet si URL dhe çfarë si kërkesë kërkimi. Në shumicën e rasteve, kjo është mjaft e dukshme - për shembull, një varg me hapësira nuk mund të jetë një URL. Por gjithçka mund të jetë më e komplikuar nëse merren parasysh intranetet - rrjetet private që gjithashtu mund të përdorin domain të nivelit të lartë privat për të zgjidhur faqet aktuale të internetit.
Nëse përdoruesi në intranetin e kompanisë së tij shkruan "marketing", dhe në intranetin e kompanisë ka një faqe interneri me të njëjtin emër, atëherë Chromium shfaq një dritare informacioni që e pyet përdoruesin nëse dëshiron të kërkojë "marketing", apo të kalojë tek https://marketing. Kjo është një çështje, por shumë ofrues të internetit dhe ofrues të rrjeteve të zakonshme Wi-Fi "të vjedhin" çdo URL të shkruar me gabime, duke e ridrejtuar përdoruesin në ndonjë faqe të mbushur me reklama.
Gjene të rastit
Zhvilluesit e Chromium nuk donin që përdoruesit në rrjetet e zakonshme të shihnin një dritare informacioni që i pyeste se çfarë kishin në mendje me çdo kërkesë për një fjalë, prandaj ata zbatuan një test: kur nisi shfletuesi ose ndryshoi rrjetin, Chromium kryen operacione kërkimi DNS për tre "domen" të rastësishëm të gjeneruar që kanë një gjatësi prej shtatë deri në pesëmbëdhjetë karakteresh. Nëse çdo dy nga këto kërkesa kthehen me të njëjtin adresë IP, atëherë Chromium supozon se rrjeti lokal "po vjedh" gabimet që ai duhet të marrë, prandaj shfletuesi i konsideron të gjitha kërkesat e shkruara me një fjalë si përpjekje për kërkim deri në një njoftim tjetër. NXDOMAIN, që duhet të merrte, prandaj shfletuesi deri në njoftimin e ardhshëm i konsideron të gjitha kërkesat e shkruara me një fjalë si përpjekje kërkimi.
Fatkeqësisht, në rrjetet që nuk vjedhin rezultatet e kërkesave DNS, këto tre operacione zakonisht ngrihen në majë, deri në serverët e tyre kryesorë: serveri lokal nuk e di se si ta konvertojë qwajuixk, prandaj e kalon këtë kërkesë në serverin e tij të përcjelljes, i cili bën të njëjtën gjë, derisa, përfundimisht, a.root-servers.net ose një nga «vëllezërit» e tij të detyrohet të thotë «Na falni, por ky nuk është një domain».
Duke pasur parasysh se ekzistojnë rreth 1,67*10^21 emra domain të rremë të mundshëm me gjatësi nga shtatë deri në pesëmbëdhjetë karaktere, më shpesh çdo nga këto teste, të kryera në një rrjet «të ndershëm», arrin te serveri rrënjësor. Kjo përbën madje gjysmën e ngarkesës totale në DNS-të rrënjësorë, nëse besojmë statistikave nga ajo pjesë e klastereve root-servers.net, që i përkasin kompanisë Verisign.
Historia përsëritet
Kjo nuk është hera e parë që një projekt i krijuar me qëllime të mira ose ishte në prag të dështimit të një burimi publik me trafik të panevojshëm – kjo na kujton menjëherë historinë e gjatë dhe të trishtuar të D-Link dhe serverit NTP (Protokolli i Koherencës) të Poul-Henning Kamp nga mesit të viteve 2000.
Në vitin 2005, zhvilluesi i FreeBSD, Poul-Henning, i cili gjithashtu kishte serverin e vetëm në Danimarkë të nivelit Stratum 1 për Protokollin e Kohës të Rrjetit, mori një faturë të papritur dhe të madhe për trafik të kaluar. Për ta thënë shkurt, shkaku ishte se zhvilluesit e D-Link kishin shkruar adresat e serverëve të NTP të nivelit Stratum 1, përfshirë serverin Kamp, në firmware të serive të shqiptuar, ruterëve dhe pikave të aksesit të kompanisë. Kjo rriti menjëherë trafikun e serverit Kamp në nëntëfish, saqë Danish Internet Exchange (pikë këmbimi e trafikëve të Internetit në Danimarkë) ndryshoi tarifën e tij nga "Falas" në "9,000 dollarë në vit".
Problemi nuk ishte se kishte shumë ruterë D-Link, por se ata "shkelën hierarkinë". Pothuajse si DNS, NTP duhet të funksionojë në një formë hierarkike — serverët e nivelit Stratum 0 transmetojnë informacionin te serverët Stratum 1, të cilët transmetojnë informacionin te serverët Stratum 2, e kështu me radhë, më poshtë në hierarki. Një router, switch ose pikë aksesi standarde si ato në të cilat D-Link kishte shkruar adresat e serverëve NTP, duhet të kishte dërguar kërkesa te serveri Stratum 2 ose Stratum 3.
Projekti Chromium, ndoshta duke pasur qëllime të mira, përsëriti problemin me NTP në çështjen e DNS, duke ngarkuar serverët rrënjorë të Internetit me kërkesa që ata kurrë nuk duhet të përpunonin.
Ka shpresë për një zgjidhje të shpejtë
Në projektin Chromium ka një problem të hapur , që kërkon që të çaktivizohet Intranet Redirect Detector si parazgjedhje për të zgjidhur këtë problem. Duhet të jepet merita projektit Chromium: gabimi u gjet para seMatt Thomas nga Verisign t'i jepte atij shumë vëmendje në blogun e tij të APNIC. Gabimi u raportua në qershor, por mbetet në harresë deri në postimin e Thomas; pas postimit ai filloi të jetë nën vëzhgimin e hollë. në blogun APNIC. Një defekt u hap në qershor, por mbeti në harresë deri në postimin e Tomasit; pas postimit ai filloi të monitorohej me vëmendje.
Ka shpresë që problemi të zgjidhet së shpejti, dhe serverët rrënjorë DNS nuk do të duhet më të përgjigjen çdo ditë për rreth 60 miliardë kërkesa false.
Si reklamë
Servera epik — kjo është ose Linux me procesorë të fuqishëm nga familia AMD EPYC dhe disqe shumë të shpejtë NVMe Intel. Nxitoni të porositni!
Burimi: habr.com
