Die Chromium-blaaier, die florerende oopbron-ouer van Google Chrome en die nuwe Microsoft Edge, het aansienlike negatiewe aandag gekry vir 'n kenmerk wat met goeie bedoelings bedoel was: dit kyk of die gebruiker se ISP nie-bestaande domeinnavraagresultate "steel" .
, wat vals navrae skep vir ewekansige "domeine" wat statisties onwaarskynlik is om te bestaan, is verantwoordelik vir ongeveer die helfte van die totale verkeer wat wêreldwyd deur wortel-DNS-bedieners ontvang word. Verisign-ingenieur Matt Thomas het 'n lang op die APNIC-blog wat die probleem beskryf en die omvang daarvan beoordeel.
Hoe DNS-resolusie gewoonlik uitgevoer word
Hierdie bedieners is die hoogste gesag wat jy moet kontak om .com, .net, ens. op te los sodat hulle jou sal vertel dat frglxrtmpuf nie 'n topvlakdomein (TLD) is nie.
DNS, of Domain Name System, is 'n stelsel waardeur rekenaars onvergeetlike domeinname soos arstechnica.com kan omskep in baie minder gebruikersvriendelike IP-adresse soos 3.128.236.93. Sonder DNS sou die internet nie bestaan op 'n manier wat mense kan gebruik nie, wat beteken dat onnodige las op die boonste vlak infrastruktuur 'n werklike probleem is.
Om 'n enkele moderne webbladsy te laai, kan 'n ongelooflike aantal DNS-opsoeke verg. Byvoorbeeld, toe ons ESPN se tuisblad ontleed het, het ons 93 afsonderlike domeinname getel, wat wissel van a.espncdn.com tot z.motads.com. Almal van hulle is nodig vir die bladsy om ten volle te laai!
Om hierdie tipe werklading te akkommodeer vir 'n soekenjin wat die hele wêreld moet dien, is die DNS ontwerp as 'n multi-vlak hiërargie. Aan die bokant van hierdie piramide is die wortelbedieners - elke topvlakdomein, soos .com, het sy eie familie van bedieners wat die hoogste gesag vir elke domein onder hulle is. Een tree op hierdie bedieners is die wortelbedieners self, vanaf a.root-servers.net aan m.root-servers.net.
Hoe gereeld gebeur dit?
Danksy die multi-vlak caching hiërargie van die DNS-infrastruktuur, bereik 'n baie klein persentasie van die wêreld se DNS-navrae die wortelbedieners. Die meeste mense kry hul DNS-oplosserinligting direk vanaf hul ISP. Wanneer 'n gebruiker se toestel moet weet hoe om by 'n spesifieke webwerf uit te kom, word 'n versoek eers na 'n DNS-bediener gestuur wat deur daardie plaaslike verskaffer bestuur word. As die plaaslike DNS-bediener nie die antwoord ken nie, stuur dit die versoek aan sy eie “aanstuurders” (indien gespesifiseer).
As nóg die plaaslike verskaffer se DNS-bediener nóg die "aanstuurbedieners" wat in sy opstelling gespesifiseer is, 'n gekasreaksie het, word die versoek direk na die gesaghebbende domeinbediener gestel bo die een wat jy probeer omskep. Wanneer домен.com dit sal beteken dat die versoek na die gesaghebbende bedieners van die domein self gestuur word com, wat geleë is by gtld-servers.net.
System gtld-servers, waarop die versoek gerig is, reageer met 'n lys van gesaghebbende naambedieners vir die domein domain.com, sowel as ten minste een skakelrekord wat die IP-adres van een so 'n naambediener bevat. Vervolgens beweeg die antwoorde in die ketting af – elke aanstuurder gee hierdie antwoorde deur na die bediener wat hulle versoek het, totdat die antwoord uiteindelik die plaaslike verskaffer se bediener en die gebruiker se rekenaar bereik. Almal van hulle kas hierdie reaksie om nie hoërvlakstelsels onnodig te versteur nie.
In die meeste gevalle, naambediener rekords vir domain.com sal reeds op een van hierdie aanstuurders gekas word, sodat die wortelbedieners nie versteur sal word nie. Vir nou praat ons egter van die tipe URL waarmee ons vertroud is - die een wat in 'n gewone webwerf omgeskakel word. Chrome-versoeke is op vlak bo dit, op die trap van die trosse self root-servers.net.
Chromium- en NXDomain-diefstalkontrole
Chromium kontroleer "Flei hierdie DNS-bediener my?" verantwoordelik vir byna die helfte van alle verkeer wat Verisign se groep van wortel DNS-bedieners bereik.
Die Chromium-blaaier, die moederprojek van Google Chrome, die nuwe Microsoft Edge en talle minder bekende blaaiers, wil gebruikers die gemak bied om in 'n enkele blokkie te soek, wat soms 'n "Omnibox" genoem word. Met ander woorde, die gebruiker voer beide regte URL's en soekenjinnavrae in dieselfde teksveld bo-aan die blaaiervenster in. Om nog 'n stap in die rigting van vereenvoudiging te neem, dwing dit ook nie die gebruiker om 'n deel van die URL mee in te voer nie http:// of https://.
So gerieflik soos dit is, hierdie benadering vereis dat die blaaier verstaan wat as 'n URL beskou moet word en wat as 'n soeknavraag beskou moet word. In die meeste gevalle is dit redelik voor die hand liggend - byvoorbeeld, 'n string met spasies kan nie 'n URL wees nie. Maar dinge kan moeiliker raak as jy intranette oorweeg—private netwerke wat ook private topvlakdomeine kan gebruik om regte webwerwe op te los.
As 'n gebruiker op hul maatskappy se intranet "bemarking" tik en die maatskappy se intranet het 'n interne webwerf met dieselfde naam, dan vertoon Chromium 'n inligtingblokkie wat die gebruiker vra of hulle vir "bemarking" wil soek of na https://marketing. Dit is dalk nie die geval nie, maar baie ISP's en openbare Wi-Fi-verskaffers "kaap" elke verkeerd gespelde URL, wat die gebruiker na een of ander baniergevulde bladsy herlei.
Willekeurige generasie
Die Chromium-ontwikkelaars wou nie hê dat gebruikers op gewone netwerke 'n inligtingskassie moet sien wat vra wat hulle bedoel elke keer as hulle na 'n enkele woord soek nie, en daarom het hulle 'n toets geïmplementeer: Wanneer hulle 'n blaaier begin of van netwerke verander, doen Chromium DNS-opsoeke op drie ewekansig gegenereerde "domeine" topvlak, sewe tot vyftien karakters lank. As enige twee van hierdie versoeke met dieselfde IP-adres terugkeer, neem Chromium aan dat die plaaslike netwerk die foute "kaap" NXDOMAIN, wat dit behoort te ontvang, dus beskou die blaaier alle enkelwoord-navrae wat ingevoer word as soekpogings tot verdere kennisgewing.
Ongelukkig, in netwerke wat geen steel die resultate van DNS-navrae, hierdie drie bewerkings styg gewoonlik heel bo, tot by die wortelnaambedieners self: die plaaslike bediener weet nie hoe om op te los nie qwajuixk, so stuur hierdie versoek aan sy expediteur, wat dieselfde doen, totdat uiteindelik a.root-servers.net of een van sy "broers" sal nie gedwing word om te sê "Jammer, maar dit is nie 'n domein nie."
Aangesien daar ongeveer 1,67*10^21 moontlike vals domeinname is wat wissel van sewe tot vyftien karakters lank, is die mees algemene elkeen van hierdie toetse wat op die "eerlike" netwerk uitgevoer word, kom dit na die wortelbediener. Dit kom op soveel neer helfte van die totale las op die wortel-DNS, volgens statistieke van daardie deel van die groepe root-servers.net, wat deur Verisign besit word.
Die geskiedenis herhaal homself
Dit is nie die eerste keer dat 'n projek met die beste bedoelings geskep word nie of byna 'n openbare hulpbron met onnodige verkeer oorstroom het - dit het ons dadelik herinner aan die lang en hartseer geskiedenis van D-Link en Poul-Henning Kamp se NTP (Network Time Protocol)-bediener in die middel 2000's.
In 2005 het die FreeBSD-ontwikkelaar Poul-Henning, wat ook Denemarke se enigste Stratum 1 Network Time Protocol-bediener besit het, 'n onverwagte en groot rekening ontvang vir gestuurde verkeer. Kortom, die rede was dat D-Link-ontwikkelaars die adresse van Stratum 1 NTP-bedieners, insluitend die Kampa-bediener, in die firmware van die maatskappy se reeks skakelaars, routers en toegangspunte geskryf het. Dit het Kampa se bedienerverkeer onmiddellik negevoudig verhoog, wat veroorsaak het dat die Deense Internet Exchange (Denemarke se Internet Exchange Point) sy tarief verander het van "Gratis" na "$9 000 per jaar."
Die probleem was nie dat daar te veel D-Link-roeteerders was nie, maar dat hulle “uit lyn” was. Net soos DNS, moet NTP in 'n hiërargiese vorm werk - Stratum 0-bedieners gee inligting aan Stratum 1-bedieners deur, wat inligting aan Stratum 2-bedieners deurgee, ensovoorts in die hiërargie af. 'n Tipiese tuisroeteerder, skakelaar of toegangspunt soos die een wat D-Link met NTP-bedieneradresse geprogrammeer het, sal versoeke na die Stratum 2- of Stratum 3-bediener stuur.
Die Chromium-projek, waarskynlik met die beste bedoelings, het die NTP-probleem in die DNS-probleem herhaal en die internet se wortelbedieners gelaai met versoeke wat hulle nooit bedoel was om te hanteer nie.
Daar is hoop vir 'n vinnige oplossing
Die Chromium-projek het 'n oopbron , wat vereis dat die Intranet Redirect Detector by verstek gedeaktiveer word om hierdie probleem op te los. Ons moet krediet gee aan die Chromium-projek: die fout is gevind voor dithoe Verisign se Matt Thomas hom baie aandag gebring het met syne op die APNIC-blog. Die gogga is in Junie ontdek, maar het vergete gebly tot Thomas se pos; Nadat hy gevas het, het hy onder streng toesig begin wees.
Daar word gehoop dat die probleem binnekort opgelos sal word, en wortel DNS-bedieners sal nie meer elke dag op die geraamde 60 miljard valse navrae hoef te reageer nie.
Oor die regte van reklame
Epiese bedieners - Is of Linux met kragtige AMD EPYC-familieverwerkers en baie vinnige Intel NVMe-aandrywers. Maak gou om te bestel!
Bron: will.com