De Chromium-blêder, de bloeiende iepenboarne-âlder fan Google Chrome en de nije Microsoft Edge, hat signifikant negative oandacht krigen foar in funksje dy't mei goede bedoelingen bedoeld wie: it kontrolearret oft de ISP fan 'e brûker net-besteande domeinfraachresultaten "steelt" .
, dy't falske queries makket foar willekeurige "domeinen" dy't statistysk net wierskynlik bestean, is ferantwurdlik foar likernôch de helte fan it totale ferkear ûntfongen troch root-DNS-tsjinners wrâldwiid. Verisign-yngenieur Matt Thomas skreau in lange op de APNIC blog beskriuwt it probleem en beoardielje syn skaal.
Hoe DNS-resolúsje normaal wurdt útfierd
Dizze servers binne de heechste autoriteit dy't jo kontakt opnimme moatte om .com, .net, ensfh., sadat se jo fertelle dat frglxrtmpuf gjin top-level domein (TLD) is.
DNS, of Domain Name System, is in systeem wêrmei't kompjûters memorabele domeinnammen lykas arstechnica.com kinne oplosse yn folle minder brûkerfreonlike IP-adressen lykas 3.128.236.93. Sûnder DNS soe it ynternet net bestean op in manier dy't minsken kinne brûke, wat betsjuttet dat ûnnedige lading op 'e ynfrastruktuer op boppeste nivo in echt probleem is.
It laden fan in inkele moderne webside kin in ongelooflijk oantal DNS-opsykjen fereaskje. Bygelyks, doe't wy de thússide fan ESPN analysearren, telden wy 93 aparte domeinnammen, fariearjend fan a.espncdn.com oant z.motads.com. Allegear binne nedich foar de side om folslein te laden!
Om dit soarte wurkdruk te foldwaan foar in sykmasine dy't de hiele wrâld tsjinje moat, is de DNS ûntwurpen as in multi-level hierargy. Oan 'e boppekant fan dizze piramide binne de root-tsjinners - elk top-level domein, lykas .com, hat in eigen famylje fan servers dy't de heechste autoriteit binne foar elk domein ûnder har. Ien stap omheech dizze tsjinners binne de root tsjinners sels, fan a.root-servers.net до m.root-servers.net.
Hoe faak komt dit foar?
Mei tank oan de multi-level caching hierargy fan 'e DNS-ynfrastruktuer berikt in heul lyts persintaazje fan' e DNS-fragen fan 'e wrâld de root-tsjinners. De measte minsken krije har DNS-resolverynformaasje direkt fan har ISP. As it apparaat fan in brûker moat witte hoe't jo nei in spesifike webside komme, wurdt in fersyk earst stjoerd nei in DNS-tsjinner dy't beheard wurdt troch dy lokale provider. As de lokale DNS-tsjinner it antwurd net wit, stjoert it it fersyk troch nei syn eigen "forwarders" (as spesifisearre).
As noch de DNS-tsjinner fan 'e pleatslike provider noch de "trochstjoerservers" spesifisearre yn syn konfiguraasje in antwurd yn 'e cache hawwe, wurdt it fersyk direkt op' e autoritative domeintsjinner brocht hegere dejinge dy't jo besykje te konvertearjen. Wannear домен.com dit sil betsjutte dat it fersyk stjoerd wurdt nei de autoritative tsjinners fan it domein sels com, dy't lizze by gtld-servers.net.
systeem gtld-servers. Dêrnei ferpleatse de antwurden de keatling nei ûnderen - elke trochstjoerder jout dizze antwurden troch nei de tsjinner dy't se frege hat, oant it antwurd úteinlik de tsjinner fan 'e lokale provider en de kompjûter fan 'e brûker berikt. Allegear cache dizze reaksje om net unnedich te fersteure systemen op heger nivo.
Yn de measte gefallen, namme tsjinner records foar domain.com sil al op ien fan dizze trochstjoerers yn it cache stean, sadat de root-tsjinners net fersteurd wurde. Foar no hawwe wy it lykwols oer it type URL dat wy bekend binne - dejinge dy't wurdt omboud ta in gewoane webside. Chrome-oanfragen binne op nivo hegere dit, op 'e stap fan' e klusters sels root-servers.net.
Chromium en NXDomain stellerij kontrôle
Chromium kontrolearret "is dizze DNS-tsjinner my foar de gek?" account foar hast de helte fan alle ferkear dat Verisign's kluster fan root-DNS-tsjinners berikt.
De Chromium-blêder, it âlderprojekt fan Google Chrome, de nije Microsoft Edge, en ûntelbere minder bekende browsers, wol brûkers it gemak jaan fan sykjen yn ien fak, soms in "Omnibox" neamd. Mei oare wurden, de brûker fiert sawol echte URL's as sykmasjinefragen yn itselde tekstfjild oan 'e boppekant fan it browserfinster. Troch in oare stap nei ferienfâldiging te nimmen, twingt it de brûker ek net om in diel fan 'e URL yn te fieren http:// of https://.
Sa handich as dit is, fereasket dizze oanpak de browser om te begripen wat in URL moat wurde beskôge en wat as in sykfraach beskôge wurde moat. Yn 'e measte gefallen is dit frij dúdlik - bygelyks in tekenrige mei spaasjes kin gjin URL wêze. Mar dingen kinne lestiger wurde as jo intranetten beskôgje - partikuliere netwurken dy't ek privee domeinen op topnivo kinne brûke om echte websides op te lossen.
As in brûker op it intranet fan har bedriuw "marketing" typt en it yntranet fan it bedriuw in ynterne webside hat mei deselde namme, dan lit Chromium in ynformaasjefak sjen dat de brûker freget oft se sykje wolle nei "marketing" of gean nei https://marketing. Dit kin miskien net it gefal wêze, mar in protte ISP's en iepenbiere Wi-Fi-oanbieders "kaapje" elke ferkeard stavere URL, en ferwize de brûker nei in banner-fol side.
Willekeurige generaasje
De Chromium-ûntwikkelders woene net dat brûkers op reguliere netwurken in ynformaasjefak sjogge dy't freget wat se bedoelden elke kear as se nei ien wurd sochten, sadat se in test ymplementeare: As se in browser starte of netwurk feroarje, fiert Chromium DNS-opsykjen op trije willekeurich oanmakke "domeinen" topnivo, sân oant fyftjin karakters lang. As ien fan dizze oanfragen weromkomt mei itselde IP-adres, dan giet Chromium derfan út dat it lokale netwurk de flaters "hijacket" NXDOMAIN, dy't it ûntfange moat, sadat de blêder alle ienwurdige fragen dy't ynfierd binne beskôge as sykpogingen oant fierdere notice.
Spitigernôch, yn netwurken dat net stealje de resultaten fan DNS-fragen, dizze trije operaasjes komme normaal nei de top, oant de rootnamme-tsjinners sels: de lokale server wit net hoe't se moatte oplosse qwajuixk, sa stjoert dit fersyk troch nei syn trochstjoerder, dy't itselde docht, oant úteinlik a.root-servers.net of ien fan syn "bruorren" sil net twongen wurde om te sizzen "Sorry, mar dit is gjin domein."
Sûnt d'r sawat 1,67 * 10 ^ 21 mooglik falske domeinnammen binne fariearjend fan sân oant fyftjin karakters yn 'e lingte, de meast foarkommende elk fan dizze testen útfierd op it "earlike" netwurk, komt it nei de root-tsjinner. Dit bedraacht safolle de helte fan 'e totale lading op' e root-DNS, neffens statistiken fan dat diel fan 'e klusters root-servers.net, dy't eigendom binne fan Verisign.
Skiednis herhellet himsels
Dit is net de earste kear dat in projekt makke is mei de bêste bedoelingen of hast in iepenbiere boarne oerstreamd mei ûnnedich ferkear - dit die ús fuortendaliks tinken oan 'e lange en tryste skiednis fan D-Link en Poul-Henning Kamp's NTP (Network Time Protocol) tsjinner yn 'e midden fan' e 2000s.
Yn 2005 krige FreeBSD-ûntwikkelder Poul-Henning, dy't ek de ienige Stratum 1 Network Time Protocol-tsjinner fan Denemarken hie, in ûnferwachte en grutte rekken foar trochstjoerd ferkear. Koartsein, de reden wie dat D-Link-ûntwikkelders de adressen fan Stratum 1 NTP-tsjinners skreaunen, ynklusyf de Kampa-tsjinner, yn 'e firmware fan' e line fan skeakels, routers en tagongspunten fan it bedriuw. Dit fergrutte fuortendaliks it serverferkear fan Kampa njoggen kear, wêrtroch't de Deenske Internet Exchange (Deenske Internet Exchange Point) har taryf feroare fan "Frij" nei "$ 9 per jier."
It probleem wie net dat d'r tefolle D-Link-routers wiene, mar dat se "út 'e line" wiene. Lykas DNS, moat NTP operearje yn in hiërargyske foarm - Stratum 0-tsjinners jouwe ynformaasje troch oan Stratum 1-tsjinners, dy't ynformaasje trochjaan oan Stratum 2-tsjinners, en sa fierder yn 'e hiërargy. In typyske thúsrouter, switch, of tagongspunt lykas de iene D-Link hie programmearre mei NTP-tsjinneradressen soe fersiken stjoere nei de Stratum 2- of Stratum 3-tsjinner.
It Chromium-projekt, wierskynlik mei de bêste bedoelingen, replikearre it NTP-probleem yn it DNS-probleem, en laden de root-tsjinners fan it ynternet mei oanfragen dy't se nea bedoeld wiene om te behanneljen.
Der is hope op in flugge oplossing
It Chromium-projekt hat in iepen boarne , wat fereasket dat de Intranet Redirect Detector standert útskeakele is om dit probleem op te lossen. Wy moatte kredyt jaan oan it Chromium-projekt: de brek is fûn dêrfoarhoe't Verisign's Matt Thomas him in protte oandacht brocht mei syn op de APNIC blog. De brek waard ûntdutsen yn juny, mar bleau fergetten oant Thomas syn post; Nei it fêstjen begûn er ûnder nauwe tafersjoch te stean.
It wurdt hope dat it probleem gau oplost wurde sil, en root DNS-tsjinners sille net langer hoege te reagearjen op 'e rûsde 60 miljard falske queries elke dei.
Oer de rjochten fan 'e advertinsje
Epyske tsjinners Is of Linux mei krêftige AMD EPYC-famyljeprozessors en heul rappe Intel NVMe-skiven. Haast om te bestellen!
Boarne: www.habr.com