🥇Üks Chromiumi funktsioonidest põhjustab tohutut koormust root DNS-serveritele

Chromium, aktiivselt arenev open-source vanem Google Chrome'ist ja uuest Microsoft Edge'ist, on saanud tõsise negatiivse tähelepanu tänu funktsioonile, mis on mõeldud heade kavatsustega: see kontrollib, kas pakkuja ei „varasta“ kasutajalt olemasolevate domeenide päringute vale tulemusi.

Intranet Redirect Detector, mis genereerib valepäringuid juhuslike „domeenide“ kohta, mille olemasolu on statistiliselt ebatõenäoline, vastutab umbes poole kogu liiklusest, mida juurdomeenide serverid saavad üle maailma. Verisigni insener Matt Thomas kirjutas pikkade post postituste blogisse APNIC, mis kirjeldab probleemi ja hindab selle ulatust.

Kuidas DNS-i lahendamine tavaliselt toimub

Need serverid on kõrgeim autoriteet, kelle poole tuleb pöörduda .com, .net jne lahendamiseks, et nad saaksid teile öelda, et frglxrtmpuf ei ole ülendsed domeen (TLD).

DNS ehk Domain Name System („domeenide nimede süsteem“) on süsteem, mille abil arvutid saavad muuta meeldejäävaid domeeninimesid, nagu arstechnica.com, vähem mugavateks IP-aadressideks, näiteks 3.128.236.93. Ilma DNS-ita ei saaks Internet eksisteerida inimeste jaoks kasutataval kujul, mistõttu on ebavajalik koormus ülemise tasandi infrastruktuurile reaalne probleem.

Üheainsa kaasaegse veebi lehe laadimiseks võib osutuda vajalikuks uskumatu hulk DNS-otsingute toiminguid. Näiteks kui analüüsisime ESPN-i avalehte, leidsime 93 erinevat domeeninime, alates a.espncdn.com kuni z.motads.com. Kõik need on vajalikud lehe täielikuks laadimiseks!

Kuna sellist koormust peab taluma otsingu süsteem, mis peab teenindama kogu maailma, on DNS kavandatud mitmetasandiliseks hierarhiaks. Selle piramidi tipus asuvad juurkliendid – iga tippdomeen, näiteks .com, omab oma serverite perekonda, mis on kõige madalamate domeenide puhul kõrgeim autoriteet. Ühel tasemel kõrgemal nendest serveritest asuvad juurkliendid ise, alates a.root-servers.net kuni m.root-servers.net.

Kuidas see toimub?

Tänu mitmetasandilisele jaotustehnoloogiale DNS-i infrastruktuuris jõuab juureserveritesse väga väike osa maailma DNS-päringutest. Enamik inimesi saab DNS-i teavet otseselt oma teenusepakkujalt. Kui kasutaja seade vajab teavet, kuidas teatud veebilehteni jõuda, saadetakse päring kõigepealt DNS-serverisse, mille haldab kohalik teenusepakkuja. Kui kohaliku DNS-serveri puhul puudub vastus, suunatakse päring edasi selle enda "edastuste serveritesse" (kui need on määratud).

Kui ei kohaliku teenusepakkuja DNS-serveril ega tema konfiguratsioonis määratud "edastuste serveritel" ei ole vahemällu salvestatud vastust, tõstetakse päring otse domeeni volitatud serverile. üle sellele, mille proovite teisendada. Juhtumil domeen.com tähendaks see, et päring saadetakse domeeni volitatud serveritele com, mis asuvad aadressil gtld-servers.net.

Süsteem gtld-servers, mille päringule vastatakse domeeni domeen.com nimede autoriteetse serverite loeteluga, samuti vähemalt ühe siduva kande IP-aadressiga, mis sisaldab ühte sellist nimede serverit. Seejärel edastatakse vastused allapoole ahelas - iga edastusserver saadab need vastused tagasi sellele serverile, kes neid küsis, kuni vastus jõuab lõpuks kohaliku teenusepakkuja serverisse ja kasutaja arvutisse. Kõik nad salvestavad selle vastuse, et mitte häirida kõrgema taseme süsteeme.

Enamikul juhtudel on nimede serverite kirjed domeen.com jaoks juba salvestatud ühes neist edastusserveritest, nii et juure servereid ei häirita. Kuid kui me räägime harjumuspärasest URL-kujust - sellest, mis muudetakse tavaliseks veebisaidiks. Chrome'i päringud kuuluvad tasemele üle sellest, klastrite enda astmele root-servers.net.

Chromium ja NXDomain'i röövimise kontroll

Chromium'i kontrollid "kas see DNS-server ei petta mind?" moodustavad peaaegu poole kogu liiklusest, mis jõuab Verisign'i juure DNS-serverite klastrisse.

Chromium, Google Chrome'i, uue Microsoft Edge'i ja arvukate vähem tuntud brauserite alusprojekt, püüab pakkuda kasutajatele lihtsustatud otsingut ühes väljundis, mida mõnikord nimetatakse 'Omnibox'. Teisisõnu, kasutaja sisestab nii reaalsed URL-id kui ka otsingupäringud samasse tekstiväljale brauseri akna ülaosas. Veel ühe sammu lihtsustamiseks ei nõua see ka kasutajalt URL-i osa sisestamist. http:// või https://.

Kuigi see lähenemine on mugav, nõuab see, et brauser mõistaks, mida pidada URL-iks ja mida otsingupäringuks. Enamikul juhtudel on see üsna ilmselge — näiteks ei saa tühikuid sisaldav string olla URL. Kuid asjad võivad olla keerulisemad, kui arvestada sisevõrke — privaatseid võrke, mis võivad samuti kasutada privaatsed tippdomeenide lahendamiseks tõelisi veebisaite.

Kui kasutaja oma ettevõtte sisevõrgus sisestab 'marketing' ja ettevõtte sisevõrgus on sarnase nimega sisemine veebisait, kuvab Chromium teateakna, küsides kasutajalt, kas ta soovib otsida 'marketing' või minna edasi. https://marketing. See on veel talutav, kuid paljud Interneti- ja ühiste Wi-Fi-võrkude teenusepakkujad "varastavad" iga vigase URL-i, suunates kasutaja millegile, mis on täis reklaambännerite lehte.

Juhuslik genereerimine

Chromiumi arendajad ei soovinud, et kasutajad tavavõrkudes näeksid iga kord, kui nad otsisid üht sõna, teateakent, mis küsis, mida nad silmas pidasid, seetõttu rakendasid nad testi: kui brauser käivitub või võrku vahetatakse, teostab Chromium kolme juhuslikult genereeritud kõrgeima taseme „domeeni“, mille pikkus on seitsmest kuni viieteistkümne täheni, DNS-otsinguid. Kui kaks neist päringutest tagastavad sama IP-aadressi, eeldab Chromium, et kohalik võrk "varastab" vigu, NXDOMAIN, mida ta peaks saama, seetõttu peab brauser kuni edasise teavitamiseni kõik ühe sõna sisestatud päringud otsingupäringute katseteks.

Kahjuks võrkudes, mis ei varastavad DNS-päringute tulemusi, tõusevad need kolm toimingut tavaliselt kõige kõrgemale, mitu juurserverit: kohalik server ei tea, kuidas tõlkida qwajuixk, seetõttu suunab see päringu edasi oma edastussevrile, mis teeb sama, kuni lõpuks a.root-servers.net või üks tema "vendadest" ei pea ütlema "Kahjuks, see ei ole domeen."

Kuna on umbes 1,67*10^21 võimalikku vale domeeninime vahemikus seitsmest kuni viieteistkümne märgini, esinevad need kõige sagedamini iga nendest testidest, mis tehti "ausas" võrgus, jõuab juurserverini. See moodustab lausa pool kogu juurdns-i koormusest, kui usaldada statistikat nende klastrite osas root-servers.net, mis kuuluvad ettevõttele Verisign.

Ajaloos kordub

See ei ole esimene kord, kui hästi kavandatud projekt on põhjustanud või peaaegu põhjustanud avaliku ressursi üleliigse liikluse — see meenutab meile kohe pika ja kurva loo D-Linki ja NTP-serveerija (Network Time Protocol) Paul-Henning Kampist 2000. aastate keskpaiku.

Aastal 2005 sai FreeBSD arendaja Poul-Henning, kes omas ka Taanis ainukest Stratum 1 Network Time Protocol serverit, ootamatu ja suure arve edastatud liikluse eest. Lühidalt öeldes, põhjuseks oli see, et D-Linki arendajad olid sisse programmeerinud Stratum 1 NTP-serverite, sealhulgas Kampari serveri, aadressid ettevõtte lülitite, ruuterite ja pääsupunktide tarkvarasse. See tõstis kohe Kampari serveri liikluse üheksa korda, mille tõttu Taani Internet Exchange (Taani internetiliikluse vahetuspunkt) muutis selle tariifi "Tasuta" peale "9 000 dollarit aastas".

Probleem ei seisnenud D-Linki ruuterite arvus, vaid selles, et nad "rikkusid hierarhiat". 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 kodune ruuter, lüliti või pääsupunkt, kuhu D-Link oli NTP-serverite aadressid sisse programmeerinud, oleks pidanud saatma päringud Stratum 2 või Stratum 3 serverile.

Chromiumi projekt, tõenäoliselt kõige paremate kavatsustega, kordas NTP probleemi DNS-iga, laadides Interneti juureserverid päringutega, mida nad kunagi töötlema ei pidanud.

On lootust, et lahendus tuleb peagi

Chromiumi projekti raames on avatud viga, mis nõuab selle probleemi lahendamiseks Intranet Redirect Detector'i vaikimisi väljalülitamist. Tuleb tunnustada Chromiumi projekti: viga avastati enne seda, kui Matt Thomas Verisignist tõmbas sellele massiivset tähelepanu oma postitus APNICi blogis. Viga avati juunis, kuid jäi unustusse kuni Thomase postituseni; pärast postitust hakkas see olema rangelt jälgitud.

On lootust, et probleem lahendatakse varsti ja juure DNS-serverid ei pea enam iga päev vastama umbes 60 miljardi vale päringule.