Unu el la funkcioj de Chromium kreas grandegan ŝarĝon sur radikaj DNS-serviloj

Unu el la funkcioj de Chromium kreas grandegan ŝarĝon sur radikaj DNS-serviloj

La retumilo Chromium, la prospera malfermfonta gepatro de Google Chrome kaj la nova Microsoft Edge, ricevis signifan negativan atenton por funkcio kiu estis celita kun bonaj intencoj: ĝi kontrolas ĉu la ISP de la uzanto "ŝtelas" neekzistantajn domajnajn konsultrezultojn. .

Detektilo de alidirekta intrareto, kiu kreas falsajn demandojn por hazardaj "domajnoj" kiuj estas statistike malprobable ekzisti, respondecas pri proksimume duono de la totala trafiko ricevita de radikaj DNS-serviloj tutmonde. Verisign-inĝeniero Matt Thomas skribis longan afiŝo en la APNIC-blogo priskribante la problemon kaj taksante ĝian skalon.

Kiel DNS-rezolucio estas kutime farita

Unu el la funkcioj de Chromium kreas grandegan ŝarĝon sur radikaj DNS-serviloj
Ĉi tiuj serviloj estas la plej alta aŭtoritato, kiun vi devus kontakti por solvi .com, .net, ktp., por ke ili diru al vi, ke frglxrtmpuf ne estas ĉefnivela domajno (TLD).

DNS, aŭ Domajna Noma Sistemo, estas sistemo per kiu komputiloj povas solvi memorindajn domajnajn nomojn kiel arstechnica.com en multe malpli uzeblajn IP-adresojn kiel 3.128.236.93. Sen DNS, la Interreto ne ekzistus tiel, ke homoj povus uzi, kio signifas, ke nenecesa ŝarĝo sur la supra-nivela infrastrukturo estas vera problemo.

Ŝarĝi ununuran modernan retpaĝon povas postuli nekredeblan nombron da DNS-serĉoj. Ekzemple, kiam ni analizis la hejmpaĝon de ESPN, ni nombris 93 apartajn domajnajn nomojn, de a.espncdn.com ĝis z.motads.com. Ĉiuj ili estas necesaj por ke la paĝo plene ŝarĝu!

Por akomodi ĉi tiun tipon de laborŝarĝo por serĉilo, kiu devas servi la tutan mondon, la DNS estas desegnita kiel plurnivela hierarkio. Ĉe la supro de ĉi tiu piramido estas la radikaj serviloj - ĉiu altnivela domajno, kiel ekzemple .com, havas sian propran familion de serviloj, kiuj estas la plej alta aŭtoritato por ĉiu domajno sub ili. Unu paŝon supren el ĉi tiuj serviloj estas la radikaj serviloj mem, de a.root-servers.net por m.root-servers.net.

Kiom ofte tio okazas?

Danke al la plurnivela kaŝmemoro-hierarkio de la DNS-infrastrukturo, tre malgranda procento de la mondaj DNS-demandoj atingas la radikservilojn. Plej multaj homoj ricevas siajn informojn pri DNS-solvilo rekte de sia ISP. Kiam la aparato de uzanto bezonas scii kiel atingi specifan retejon, peto unue estas sendita al DNS-servilo administrita de tiu loka provizanto. Se la loka DNS-servilo ne scias la respondon, ĝi plusendas la peton al siaj propraj "sendantoj" (se specifite).

Se nek la DNS-servilo de la loka provizanto nek la "sendserviloj" specifitaj en ĝia agordo havas kaŝmemorigitan respondon, la peto estas levita rekte al la aŭtoritata domajna servilo. altaj tiun, kiun vi provas konverti. Kiam домен.com ĉi tio signifos, ke la peto estas sendita al la aŭtoritataj serviloj de la domajno mem com, kiuj troviĝas ĉe gtld-servers.net.

sistemo gtld-servers, al kiu la peto estis farita, respondas per listo de aŭtoritataj nomserviloj por la domajna domajno.com, same kiel almenaŭ unu ligrekordo enhavanta la IP-adreson de unu tia nomservilo. Poste, la respondoj moviĝas laŭ la ĉeno - ĉiu plusendisto pasas tiujn respondojn malsupren al la servilo kiu petis ilin, ĝis la respondo finfine atingas la servilon de la loka provizanto kaj la komputilon de la uzanto. Ĉiuj ili konservas ĉi tiun respondon por ne senbezone ĝeni pli altnivelajn sistemojn.

Plejofte, nomservilo registras por domajno.com estos jam konservita en unu el ĉi tiuj plusendiloj, do la radikaj serviloj ne estos ĝenitaj. Tamen, nuntempe ni parolas pri la tipo de URL, kiun ni konas - tiu, kiu estas konvertita en regulan retejon. Chrome-petoj estas je nivelo altaj ĉi tio, sur la ŝtupo de la aretoj mem root-servers.net.

Chromium kaj NXDomain-ŝtelkontrolo

Unu el la funkcioj de Chromium kreas grandegan ŝarĝon sur radikaj DNS-serviloj
Chromium kontrolas "ĉu ĉi tiu DNS-servilo trompas min?" respondecas pri preskaŭ duono de la tuta trafiko atinganta la areton de Verisign de radikaj DNS-serviloj.

La retumilo Chromium, la gepatra projekto de Google Chrome, la nova Microsoft Edge, kaj sennombraj malpli konataj retumiloj volas provizi uzantojn kun la facileco serĉi en ununura skatolo, foje nomita "Omnibox". Alivorte, la uzanto enmetas kaj realajn URL-ojn kaj serĉilon en la saman tekstkampon ĉe la supro de la retumila fenestro. Farante alian paŝon al simpligo, ĝi ankaŭ ne devigas la uzanton enigi parton de la URL kun http://https://.

Tiel oportuna kiel ĉi tio estas, ĉi tiu aliro postulas, ke la retumilo komprenu, kio devus esti konsiderata URL kaj kio devus esti konsiderata serĉdemando. Plejofte tio estas sufiĉe evidenta - ekzemple ĉeno kun spacoj ne povas esti URL. Sed aferoj povas fariĝi pli malfacilaj se vi konsideras intraretojn - privatajn retojn, kiuj ankaŭ povas uzi privatajn altnivelajn domajnojn por solvi realajn retejojn.

Se uzanto en la intrareto de sia firmao tajpas "merkatigo" kaj la intrareto de la firmao havas internan retejon kun la sama nomo, tiam Chromium montras informkeston demandante la uzanton ĉu ili volas serĉi "merkatado" aŭ iri al. https://marketing. Ĉi tio eble ne estas la kazo, sed multaj ISP-oj kaj publikaj Wi-Fi-provizantoj "kaptas" ĉiun misliterumitan URL, redirektante la uzanton al iu rubando-plena paĝo.

Hazarda generacio

La programistoj de Chromium ne volis, ke uzantoj en regulaj retoj vidu informkeston demandantan kion ili volis diri ĉiufoje kiam ili serĉis unu vorton, do ili efektivigis teston: Kiam ili lanĉas retumilon aŭ ŝanĝas retojn, Chromium faras DNS-serĉojn sur tri. hazarde generitaj "domajnoj" pinta nivelo, sep ĝis dek kvin karakteroj longaj. Se iuj el ĉi tiuj petoj revenas kun la sama IP-adreso, tiam Chromium supozas, ke la loka reto "kaptas" la erarojn. NXDOMAIN, kiun ĝi devus ricevi, do la retumilo konsideras ĉiujn unuvortajn demandojn enigitajn kiel serĉprovojn ĝis nova avizo.

Bedaŭrinde, en retoj tio ne ŝteli la rezultojn de DNS-demandoj, ĉi tiuj tri operacioj kutime leviĝas ĝis la plej supro, ĝis la radikaj nomserviloj mem: la loka servilo ne scias kiel solvi qwajuixk, do plusendas ĉi tiun peton al sia sendinto, kiu faras la samon, ĝis fine a.root-servers.net aŭ unu el liaj "fratoj" ne estos devigita diri "Pardonu, sed ĉi tio ne estas domajno."

Ĉar ekzistas proksimume 1,67*10^21 eblaj falsaj domajnaj nomoj intervalantaj de sep ĝis dek kvin karakteroj en longo, la plej ofta ĉiu de ĉi tiuj provoj faritaj sur la "honesta" reto, ĝi atingas la radikan servilon. Ĉi tio sumiĝas al tiom duono de la totala ŝarĝo sur la radika DNS, laŭ statistikoj de tiu parto de la aretoj root-servers.net, kiuj estas posedataj de Verisign.

Historio ripetas sin

Ĉi tio ne estas la unua fojo, ke projekto kreas kun la plej bonaj intencoj malsukcesis aŭ preskaŭ inundis publikan rimedon per nenecesa trafiko - tio tuj rememorigis al ni la longan kaj malĝojan historion de la servilo NTP (Network Time Protocol) de D-Link kaj Poul-Henning Kamp meze de la 2000-aj jaroj.

En 2005, FreeBSD-programisto Poul-Henning, kiu ankaŭ posedis la nuran Stratum 1 Network Time Protocol-servilon de Danio, ricevis neatenditan kaj grandan fakturon por elsendita trafiko. Resume, la kialo estis, ke D-Link-programistoj skribis la adresojn de Stratum 1 NTP-serviloj, inkluzive de la Kampa-servilo, en la firmvaro de la linio de la kompanio de ŝaltiloj, enkursigiloj kaj alirpunktoj. Ĉi tio tuj pliigis la serviltrafikon de Kampa naŭoble, igante la Danan Interreta Interŝanĝo (Interreta Interŝanĝa Punkto de Danio) ŝanĝi sian tarifon de "Senpaga" al "9 USD jare."

La problemo ne estis, ke estis tro da D-Link-enkursigiloj, sed ke ili estis "malkongruaj". Tre kiel DNS, NTP devas funkcii en hierarkia formo - Stratum 0-serviloj pasas informojn al Stratum 1-serviloj, kiuj pasas informojn al Stratum 2-serviloj, kaj tiel plu laŭ la hierarkio. Tipa hejma enkursigilo, ŝaltilo aŭ alirpunkto kiel tiu D-Link programis kun NTP-serviladresoj sendus petojn al la Servilo Stratum 2 aŭ Stratum 3.

La projekto Chromium, verŝajne kun la plej bonaj intencoj, reproduktis la NTP-problemon en la DNS-problemo, ŝarĝante la radikservilojn de Interreto per petoj, kiujn ili neniam intencis trakti.

Estas espero por rapida solvo

La projekto Chromium havas malferman fonton cimo, kiu postulas malŝalti Intranet-Redirektilon defaŭlte por solvi ĉi tiun problemon. Ni devas doni krediton al la projekto Chromium: la cimo estis trovita antaŭ tiokiel Matt Thomas de Verisign alportis al li multe da atento kun sia fastado en la blogo de APNIC. La cimo estis malkovrita en junio, sed restis forgesita ĝis la afiŝo de Tomaso; Post fastado, li komencis esti sub proksima superrigardo.

Oni esperas, ke la problemo baldaŭ estos solvita, kaj radikaj DNS-serviloj ne plu devos respondi al la ĉirkaŭkalkulitaj 60 miliardoj da falsaj demandoj ĉiutage.

Pri la Rajtoj de Reklamado

Epopeaj serviloj Estas VPS en Vindozo aŭ Linukso kun potencaj AMD EPYC-familiaj procesoroj kaj tre rapidaj Intel NVMe-diskoj. Rapidu mendi!

Unu el la funkcioj de Chromium kreas grandegan ŝarĝon sur radikaj DNS-serviloj

fonto: www.habr.com

Aldoni komenton