Byna die helfte van die verkeer na wortel-DNS-bedieners word deur Chromium-aktiwiteit veroorsaak

Die APNIC-registrateur, verantwoordelik vir die verspreiding van IP-adresse in die Asië-Stille Oseaan-streek, опубликовал resultate van verkeer verspreiding analise op een van die wortel DNS bedieners a.root-servers.net. 45.80% van versoeke aan die wortelbediener was verwant aan kontroles wat uitgevoer is deur blaaiers gebaseer op die Chromium-enjin. Byna die helfte van die wortel-DNS-bedieners se hulpbronne word dus bestee aan die uitvoering van Chromium-diagnostiese tjeks eerder as om versoeke van die DNS-bedieners te verwerk om wortelsones te bepaal. Aangesien Chrome 70% van die webblaaiermark uitmaak, lei sulke diagnostiese aktiwiteit daartoe dat ongeveer 60 miljard versoeke per dag na wortelbedieners gestuur word.

Diagnostiese kontroles word in Chromium gebruik om vas te stel of diensverskaffers dienste gebruik wat versoeke na nie-bestaande name na hul hanteerders herlei. Soortgelyke stelsels word deur sommige verskaffers geïmplementeer om verkeer na domeinname te lei wat met 'n fout ingevoer is - as 'n reël, vir nie-bestaande domeine, word bladsye gewys met 'n foutwaarskuwing, wat 'n lys van waarskynlik korrekte name bied, en advertensies. Boonop vernietig sulke aktiwiteit die logika van die bepaling van intranetgashere in die blaaier heeltemal.

By die verwerking van 'n soeknavraag wat in die adresbalk ingevoer is, as slegs een woord sonder kolletjies ingevoer word, moet die blaaier eers probeer om te bepaal 'n gegewe woord in DNS, met die veronderstelling dat die gebruiker dalk probeer om toegang tot 'n intranetwebwerf op 'n interne netwerk te kry, eerder as om 'n navraag na 'n soekenjin te stuur. As die verskaffer navrae na nie-bestaande domeinname herlei, het gebruikers 'n probleem – enige enkelwoord-soeknavrae wat in die adresbalk ingevoer word, begin na die verskaffer se bladsye herlei word, eerder as om na die soekenjin gestuur te word.

Om hierdie probleem op te los, het Chromium-ontwikkelaars by die blaaier gevoeg bykomende tjeks, wat, as herleidings bespeur word, die logika vir die verwerking van versoeke in die adresbalk verander.
Elke keer as jy begin, jou DNS-instellings verander of jou IP-adres verander, stuur die blaaier drie DNS-versoeke met ewekansige eerstevlakdomeinname wat heel waarskynlik nie bestaan ​​nie. Die name bevat van 7 tot 15 Latynse letters (sonder kolletjies) en word gebruik om die herleiding van nie-bestaande domeinname deur die verskaffer na sy gasheer op te spoor. As, wanneer drie HTTP-versoeke met ewekansige name verwerk word, twee 'n herleiding na dieselfde bladsy ontvang, neem Chromium in ag dat die gebruiker na 'n derdeparty-bladsy herlei is.

Atipiese eerstevlak-domeingroottes (van 7 tot 15 letters) en die navraagherhalingsfaktor (name is elke keer lukraak gegenereer en is nie herhaal nie) is as tekens gebruik om Chromium-aktiwiteit te isoleer van die algemene vloei van versoeke op die wortel-DNS-bediener.
In die logboek is versoeke vir nie-bestaande domeine eers gefiltreer (78.09%), daarna is versoeke wat nie meer as drie keer herhaal is, gekies (51.41%), en daarna is domeine wat van 7 tot 15 letters bevat gefiltreer (45.80%) . Interessant genoeg was slegs 21.91% van versoeke aan wortelbedieners verwant aan die definisie van bestaande domeine.

Byna die helfte van die verkeer na wortel-DNS-bedieners word deur Chromium-aktiwiteit veroorsaak

Die studie het ook die afhanklikheid van die groeiende las op die wortelbedieners a.root-servers.net en j.root-servers.net van die groeiende gewildheid van Chrome ondersoek.

Byna die helfte van die verkeer na wortel-DNS-bedieners word deur Chromium-aktiwiteit veroorsaak

In Firefox, DNS-herleidingkontroles is beperk definieer aanstuur na verifikasie bladsye (gevange portaal) en geïmplementeer с gebruik vaste subdomein "detectportal.firefox.com", sonder om eerstevlak-domeinname te versoek. Hierdie gedrag skep nie bykomende las op die wortel DNS-bedieners nie, maar dit kan moontlik om oorweeg te word as 'n lek van vertroulike data oor die gebruiker se IP-adres (die bladsy "detectportal.firefox.com/success.txt" word aangevra elke keer as dit bekendgestel word). Om skandering in Firefox te deaktiveer, is daar 'n instelling "network.captive-portal-service.enabled", wat op die "about:config"-bladsy verander kan word.

Bron: opennet.ru

Voeg 'n opmerking