Chromium arakatzaileak, Google Chrome eta Microsoft Edge berriaren kode irekiko guraso oparoak, arreta negatibo handia jaso du asmo onekin pentsatutako eginbide bati: erabiltzailearen ISP-ak existitzen ez diren domeinu-kontsulten emaitzak "lapurtzen" ote dituen egiaztatzen du. .
, estatistikoki nekez existituko diren ausazko "domeinuetarako" kontsulta faltsuak sortzen dituena, erro DNS zerbitzariek mundu osoan jasotako trafiko osoaren erdiaren erantzule da gutxi gorabehera. Matt Thomas Verisign ingeniariak luze bat idatzi zuen APNIC blogean arazoa deskribatuz eta bere tamaina ebaluatuz.
DNS ebazpena nola egiten den normalean
Zerbitzari hauek .com, .net, etab. konpontzeko harremanetan jarri behar duzun agintari gorena dira, beraz, frglxrtmpuf ez dela goi-mailako domeinua (TLD) esango dizute.
DNS edo domeinu-izenen sistema, ordenagailuek arstechnica.com bezalako domeinu-izen gogoangarriak ebatzi ditzaketen sistema bat da, 3.128.236.93 bezalako IP helbide askoz ere ez hain atseginak. DNSrik gabe, Internet ez litzateke gizakiek erabil dezaketen moduan existituko, hau da, goi-mailako azpiegituran beharrezkoa ez den karga benetako arazoa da.
Web orri moderno bakarra kargatzeak DNS bilaketa kopuru ikaragarria eska dezake. Esaterako, ESPNren hasierako orrialdea aztertu dugunean, 93 domeinu-izen bereizi zenbatu ditugu, a.espncdn.com-tik z.motads.com-era. Horiek guztiak beharrezkoak dira orrialdea guztiz kargatzeko!
Mundu osoa zerbitzatu behar duen bilatzaile baten lan-karga mota hau egokitzeko, DNS maila anitzeko hierarkia gisa diseinatu da. Piramide honen goialdean erro-zerbitzariak daude: goi-mailako domeinu bakoitzak, adibidez, .com, bere beheko domeinu bakoitzaren agintaritza handiena duten zerbitzari-familia du. Pauso bat gora horien artean zerbitzariak erro zerbitzariak dira beraiek, batetik a.root-servers.net to m.root-servers.net.
Zenbatetan gertatzen da hau?
DNS azpiegituraren maila anitzeko cachearen hierarkiari esker, munduko DNS kontsulten ehuneko oso txiki bat erro zerbitzarietara iristen da. Jende gehienek DNS ebazteko informazioa zuzenean lortzen dute ISPtik. Erabiltzaile baten gailuak webgune jakin batera nola iritsi jakin behar duenean, eskaera bat tokiko hornitzaile horrek kudeatzen duen DNS zerbitzari batera bidaltzen da lehenik. Tokiko DNS zerbitzariak erantzuna ezagutzen ez badu, eskaera bere "desbideratzaileei" birbidaltzen die (zehazten bada).
Tokiko hornitzailearen DNS zerbitzariak eta bere konfigurazioan zehaztutako "birbidaltze-zerbitzariek" ez badute cacheko erantzunik, eskaera zuzenean domeinu-zerbitzari autoritariora igotzen da. arriba,ru bihurtzen saiatzen ari zarena. Noiz Π΄ΠΎΠΌΠ΅Π½.com horrek esan nahi du eskaera domeinuaren beraren zerbitzari autoritarioetara bidaltzen dela com, helbidean kokatzen direnak gtld-servers.net.
Sistema gtld-servers, eskaera egin zaion, domeinuaren domeinuaren izen-zerbitzari agintarrien zerrenda batekin erantzuten du, baita izen-zerbitzari baten IP helbidea duen gutxienez esteka-erregistro batekin ere. Jarraian, erantzunak katean behera mugitzen dira: birbidaltzaile bakoitzak erantzun horiek eskatu dituen zerbitzariari pasatzen dizkio, erantzuna azkenean tokiko hornitzailearen zerbitzarira eta erabiltzailearen ordenagailura iritsi arte. Guztiek erantzun hau cacheatzen dute goi-mailako sistemak alferrik nahasteko.
Kasu gehienetan, izen-zerbitzariaren erregistroak domeinua.com dagoeneko cachean gordeko da birbideratzaile horietako batean, beraz, erro-zerbitzariak ez dira trabarik izango. Hala ere, oraingoz ezagutzen dugun URL motaz ari gara -ohiko webgune bihurtzen dena-. Chrome eskaerak maila berean daude arriba,ru hau, klusterren urratsean root-servers.net.
Chromium eta NXDomain lapurreta egiaztatzea
Chromium-ek egiaztatzen du "DNS zerbitzari honek engainatzen al nau?" Verisign-en erro DNS zerbitzarien multzora iristen den trafikoaren ia erdia hartzen du.
Chromium arakatzaileak, Google Chrome-ren proiektu nagusiak, Microsoft Edge berriak eta ezezagunak diren hamaika arakatzailek, erabiltzaileei koadro bakarrean bilatzeko erraztasuna eskaini nahi die, batzuetan "Omnibox" izenekoa. Beste era batera esanda, erabiltzaileak URL errealak eta bilatzaileen kontsultak sartzen ditu arakatzailearen leihoaren goialdean dagoen testu eremu berean. Sinplifikaziorako beste urrats bat emanez, erabiltzailea ez du URLaren zati bat sartzera behartzen http:// edo https://.
Hau bezain erosoa den bezala, ikuspegi honek arakatzaileak zer URLtzat hartu behar den eta bilaketa-kontsultatzat hartu behar diren ulertzea eskatzen du. Kasu gehienetan hori nahiko agerikoa da; adibidez, zuriuneak dituen kate bat ezin da URL bat izan. Baina gauzak zailagoak izan daitezke intranetak kontuan hartzen badituzu, benetako webguneak konpontzeko goi-mailako domeinu pribatuak ere erabil ditzaketen sare pribatuak.
Bere enpresaren intraneten erabiltzaile batek "marketing" idazten badu eta konpainiaren intranetak izen bereko barneko webgune bat badu, Chromium-ek informazio-koadro bat bistaratzen du erabiltzaileari "marketing" bilatu nahi duen edo joan nahi duen galdetuz. https://marketing. Agian ez da horrela izango, baina ISP eta Wi-Fi hornitzaile publiko askok gaizki idatzitako URL bakoitza "bahiatu" egiten dute, erabiltzailea pankartaz betetako orri batera birbideratuz.
Ausazko belaunaldia
Chromium-eko garatzaileek ez zuten nahi ohiko sareetako erabiltzaileek hitz bakar bat bilatzen zuten bakoitzean zer esan nahi zuten galdetzen zuen informazio-koadro bat ikustea, beraz, proba bat ezarri zuten: arakatzailea abiarazten dutenean edo sareak aldatzen dituztenean, Chromium-ek DNS bilaketak egiten ditu hirutan. ausaz sortutako "domeinuak" goi-mailakoak, zazpi eta hamabost karakterekoak. Eskaera horietako bi IP helbide berdinarekin itzultzen badira, Chromium-ek sare lokalak erroreak "bahiatzen" dituela suposatuko du. NXDOMAIN, jaso beharko lukeena, beraz, arakatzaileak sartutako hitz bakarreko kontsulta guztiak bilaketa-saiotzat hartzen ditu abisu berrira arte.
Zoritxarrez, sareetan hori ez DNS kontsulten emaitzak lapurtzen dituzte, hiru eragiketa hauek goialdera igo ohi dira, erroko izen-zerbitzarietaraino: tokiko zerbitzariak ez daki nola konpondu. qwajuixk, beraz, eskaera hau bere bidaltzaileari bidaltzen dio, honek gauza bera egiten du, azkenean arte a.root-servers.net edo bere "anaia"ren bat ez da "Barkatu, baina hau ez da domeinu bat" esatera behartuko.
Zazpi eta hamabost karaktere bitarteko 1,67*10^21 domeinu-izen posible direnez, ohikoena. bakoitzeko sare βzintzoanβ egindako proba horietatik, erroko zerbitzarira iristen da. Horrek bezainbeste balio du erdia erroko DNS-ko karga osoaren arabera, klusterren zati horretako estatistiken arabera root-servers.net, Verisign-en jabetzakoak.
Historia errepikatzen da
Ez da proiektu bat asmo onenekin sortzen den lehen aldia edo ia baliabide publiko bat alferrikako trafikoz gainezka egin zuen - honek berehala gogorarazi zigun D-Link eta Poul-Henning Kamp-en NTP (Network Time Protocol) zerbitzariaren historia luze eta tristea 2000ko hamarkadaren erdialdean.
2005ean, Poul-Henning FreeBSD garatzaileak, Danimarkako Stratum 1 Network Time Protocol zerbitzari bakarraren jabea ere bai, igorritako trafikoaren ustekabeko faktura handia jaso zuen. Laburbilduz, arrazoia izan zen D-Link-eko garatzaileek Stratum 1 NTP zerbitzarien helbideak idatzi izana, Kampa zerbitzaria barne, konpainiaren etengailuen, bideratzaileen eta sarbide-puntuen firmwarean. Honek berehala bederatzi bider handitu zuen Kamparen zerbitzariaren trafikoa, eta Danimarkako Internet Exchange-k (Danimarkako Internet Exchange Point) tarifa "Doakoa"tik "9 $ urtean" izatera aldatu zuen.
Arazoa ez zen D-Link bideratzaile gehiegi zeudela, "lerrotik kanpo" zeudela baizik. DNS antzera, NTPk forma hierarkikoan funtzionatu behar du - Stratum 0 zerbitzariek informazioa pasatzen dute Stratum 1 zerbitzarietara, eta horiek Stratum 2 zerbitzarietara pasatzen dute informazioa, eta abar hierarkian behera. Etxeko bideratzaile, etengailu edo sarbide-puntu tipiko batek D-Link-ek NTP zerbitzariaren helbideekin programatu zuena bezalakoak eskaerak bidaliko lituzke Stratum 2 edo Stratum 3 zerbitzariari.
Chromium proiektuak, ziurrenik asmo onenarekin, NTP arazoa DNS arazoan errepikatu zuen, Interneteko erro-zerbitzariak inoiz kudeatu behar ez zituzten eskaerak kargatuz.
Konponbide azkar baten itxaropena dago
Chromium proiektuak kode irekia du , eta horrek modu lehenetsian Intranet Redirect Detector desgaitu behar du arazo hau konpontzeko. Chromium proiektuari meritua eman behar diogu: akatsa aurkitu da aurretiknola Verisign-en Matt Thomas-ek berearekin arreta handia jarri zion APNIC blogean. Akatsa ekainean aurkitu zuten, baina ahaztuta egon zen Thomasen mezura arte; Barau egin ondoren, zaintza estua izaten hasi zen.
Arazoa laster konponduko dela espero da, eta erro DNS zerbitzariek ez diete gehiago erantzun beharko egunero zenbatetsitako 60 milioi kontsulta faltsuei.
Publizitatearen Eskubideei buruz
Zerbitzari epikoak - Is edo Linux AMD EPYC familiako prozesadore indartsuekin eta Intel NVMe unitate oso azkarrekin. Azkar ibili eskaera egitera!
Iturria: www.habr.com