🥇Üks Chromiumi funktsioone tekitab juurdomeeni DNS-serveritele tohutut koormust

Chromium on aktiivselt arenev avatud lähtekoodiga projekt, millel on Google Chrome'i ja uue Microsoft Edge'i taust, on tähelepanu köitnud tõsise negatiivse tähelepanuga seoses funktsiooniga, mis oli algselt mõeldud heade kavatsustega: see kontrollib, kas kasutaja pakkuja ei "varasta" mitteeksisteerivaid päringutulemusi domeenidelt.

Intranet Redirect Detector, luues vale päringuid juhuslike "domeenide" kohta, mille olemasolu on statistiliselt ebaoluline, on vastutav umbes poole üldise liikluse eest, mida juurdomeenide nimed saavad üle kogu maailma. Verisigni insener Matt Thomas kirjutas laiaulatusliku postitus blogipostituse APNICis probleemi kirjeldamise ja selle ulatuse hindamisega.

Kuidas toimub DNS-i lahendamine

Need serverid on kõrgeim instants, mille poole tuleks pöörduda .com, .net jne lahendamiseks, et teavitada teid, et frglxrtmpuf ei ole ülemine domeen (TLD).

DNS, ehk domeeninime süsteem, on süsteem, tänu millele saavad arvutid tõlkida meeldejäävaid domeeninimesid nagu arstechnica.com palju vähem mugavateks IP-aadressideks, näiteks 3.128.236.93. Ilma DNS-ita ei saaks Internet eksisteerida inimkeelsetes vormides, seega on ülemise taseme infrastruktuurile liialdatud koormus tõeline probleem.

Ühe kaasaegse veebilehe laadimiseks võib olla vajalik uskumatult suur hulk DNS-päringute toiminguid. Näiteks, kui analüüsisime ESPN-i peamist lehte, lugesime 93 erinevat domeeninime alates a.espncdn.com kuni z.motads.com. Kõik need on vajalikud lehe täielikuks laadimiseks!

Kuna süsteem peab taluma kogu maailma teenindamise koormust, on DNS kavandatud kui mitmetasandiline hierarhia. Selle piramidi tipus asuvad juurdomeeni serverid — igal ülemisel domeenil, nagu .com, on oma serverite perekond, mis on kõrgem instants iga madalamate domeenide jaoks. Üks samm kõrgemal needest serveritest asuvad juurdomeeni serverid, alates a.root-servers.net kuni m.root-servers.net.

Kui tihti see juhtub?

Tänu DNS-i infrastruktuuri mitmetasandilise vahemäcache'ile jõuab juursüsteemide serveritesse väga väike osa maailma DNS-i päringutest. Enamik inimesi saab DNS-i lahendaja teavet otse oma teenusepakkujalt. Kui kasutaja seadmel on vaja teada, kuidas teatud veebisaidile pääseda, saadetakse päring esmalt selle kohaliku teenusepakkuja halduses olevale DNS-serverile. Kui kohalik DNS-server ei tea vastust, suunab ta päringu edasi oma "edastuste serveritele", kui need on määratud.

Kui ei kohaliku teenusepakkuja DNS-serveril ega tema konfigureeritud "edastuste serveritel" pole vahemällu salvestatud vastust, tõstetakse päring otse domeeni volitatud serverile. üle selle, mille soovite muuta. Juhul kui domeen.com tähendab, et päring saadetakse domeeni volitatud serveritele. ok, mis asuvad aadressil gtld-servers.net.

Süsteem gtld-servers, millele päring on esitatud, vastab nime serverite loetelu domeeni domeen.com jaoks, samuti vähemalt ühe siduva kirje, mis sisaldab ühe sellise nimiserveri IP-aadressi. Edasi edastatakse vastused allapoole - iga edastusserver edastab need vastused sellele serverile, mis neid küsis, kuni vastus lõpuks jõuab kohaliku teenusepakkuja serverisse ja kasutaja arvutisse. Kõik need salvestavad selle vastuse vahemällu, et mitte häirida kõrgema taseme süsteeme.

Enamikul juhtudel on nime serveri kirjed domeen.com juba vahemälus ühe neist edastusserveritest, mistõttu juursüsteemi servereid ei häirita. Kuid seni, kuni räägime meile tuntud URL-ist - selle, mis muudetakse tavaliseks veebisaitiks. Chrome'i päringud viitavad tasemele üle sellel, klastrite tasemel root-servers.net.

Chromium ja NXDomain'i röövimise kontroll

Chromiumi kontrollimised "kas see DNS-server ei peta mind?" moodustavad peaaegu poole kogu liiklusest, mis jõuab Verisigni juursüsteemide serverite klastrisse.

Chromium, Google Chrome'i, uue Microsoft Edge'i ja lugematute vähem tuntud brauserite vanemprojekt, soovib kasutajatele pakkuda lihtsust ühes otsinguväljas, mida mõnikord nimetatakse „Omniboxiks“. Teisisõnu, kasutaja sisestab nii tegelikud URL-id kui ka päringud otsingumootorisse samasse tekstiväljasse, mis asub brauseri akna ülavarre. Tehes veel ühe sammu lihtsustamise suunas, ei nõua see ka kasutajalt URL-i osa sisestamist http:// või https://.

Kuigi see on mugav, eeldab selline lähenemine, et brauser mõistaks, mida pidada URL-iks ja mida otsingupäringuks. Enamikul juhtudel on see üsna ilmne — näiteks, tühikute sisaldav rida ei saa olla URL. Kuid kõik võib olla keerulisem, kui arvesse võtta sisemisi võrgustikke — privaatseid võrgustikke, mis võivad samuti kasutada privaatseid tipp-domeene tõeliste veebisaitide lahendamiseks.

Kui kasutaja oma ettevõtte sisevõrgus sisestab 'marketing', ja kui ettevõtte sisevõrgus on selle nimega sisemine veebisait, siis Chromium kuvab dialooge, küsides kasutajalt, kas ta soovib otsida 'marketing' või minna. https://marketing. See on veel talutav, kuid paljud Interneti-teenuse pakkujad ja avalike Wi-Fi-võrkude teenuse pakkujad 'varastavad' iga vale URL-i sisestuse, suunates kasutaja mõne reklaamibanneritega lehele.

Juhuslik genereerimine

Chromium'i arendajad ei soovinud, et kasutajad tavalistes võrkudes näeksid iga sõna otsingu puhul dialooge, küsides, mida nad silmas pidanud, seetõttu rakendasid nad testi: brauseri käivitamisel või võrgu vahetamisel viib Chromium läbi DNS-otsingu kolme juhuslikult genereeritud tippdomeeni üle 7 kuni 15 tähemärki. KuiNeed kahest päringust tagastatakse sama IP-aadressiga, oletab Chromium, et lokaalne võrk 'varastab' vigasusi NXDOMAIN, mida ta peaks saama, seega peab brauser kuni edasise teavitamiseni kõiki ühesõnalisi päringuid otsingupüüdlusteks.

Kahjuks on võrkudes, mis ei varastab DNS-päringute tulemusi, need kolm toimingut tavaliselt ülendatud kõige kõrgemal tasemel, kuni nime süsteemi juurkserveriteni: lokaalne server ei tea, kuidas teisendada qwajuixk, seetõttu suunab see päringu oma edastamise serverile, mis teeb sama, kuni lõpuks a.root-servers.net või üks tema

vennas ei pea ütlema: "Vabandust, aga see ei ole domeen." Kuna on umbes 1,67*10^21 võimalikku vale domeeninime pikkusega seitsme kuni viieteistkümne tähemärgiga, juhtub kõige sagedamini iga nendest testidest, mis on tehtud "ausas" võrgus, jõuab juure DNS-serverisse. See moodustab lausa pool root-servers.netkogu koormusest juure DNS-ile, kui uskuda Verisign'i statistikat.

Ajalugu kordub

See ei ole esimene kord, kui kõige paremate kavatsustega loodud projekt kogub või peaaegu kogub avaliku ressursi jaoks vajalikku liiklust — see tuletab meelde pikka ja kurba lugu D-Linkist ning NTP-serverist (Network Time Protocol) Poul-Henning Campist 2000. aastate keskpaiku.

Aastal 2005 sai FreeBSD arendaja Poul-Henning, kes omas ka ühte Taani Stratum 1 NTP serveritest, ootamatu ja suure arve edastatud liikluse eest. Lühidalt, põhjus oli selles, et D-Link'i arendajad olid määranud Stratum 1 NTP-serverite aadressid, sealhulgas ka Campi serveri, ettevõtte lülitite, ruuterite ja pääsupunktide kindlatele firmware'ile. See suurendas Campi serveri liiklust üheksa korda, mistõttu Taani Interneti vahetuspunkt (Taani Interneti liikluse vahetuspunkt) muutis tema tasu "Tasuta" pealt "9000 dollarit aastas".

Probleem ei seisnenud D-Link'i ruuterite arvu liiga suures koguses, vaid selles, et nad "rikusid alluvussuhet". Peaaegu nagu DNS, peaks NTP toimima hierarhiliselt — Stratum 0 taseme serverid edastavad teavet Stratum 1 serveritele, mis edastavad teavet Stratum 2 serveritele ja nii edasi, allapoole hierarhias. Tavaline koduruuter, lüliti või pääsupunkt, nagu need, kuhu D-Link on määranud NTP-serverite aadressid, pidid saatma päringud Stratum 2 või Stratum 3 serverile.

Chromium projekt, omades tõenäoliselt parimaid kavatsusi, kordas NTP probleemiga seotud probleemi DNS-i osas, laadides Interneti juure serverisse päringute hulgaga, mida nad kunagi ei pidanud töötlema.

Loodame varajase lahenduse

Chromium projektis on avatud viga, mis nõuab selle probleemi lahendamiseks vaikimisi Intranet Redirect Detector'i väljalülitamist. Tuleb anda tunnustust Chromiumi projektile: viga avastati enne, kui Matt Thomas Verisign'ist tõmbas sellele tohutu tähelepanu oma postitusega APNICi blogis. Viga tuvastati juunis, kuid see jäi unustusse kuni Thomase postituseni; pärast postitust hakkas see olema hoolikalt jälgitud.

On lootust, et probleem lahendatakse peagi ja juurdomeeni DNS-serverid ei pea enam iga päev umbes 60 miljardile valele päringule vastama.