De APNIC-registrar, ferantwurdlik foar de distribúsje fan IP-adressen yn 'e regio Azië-Stille Oseaan, resultaten fan ferkear distribúsje analyze op ien fan 'e root DNS tsjinners a.root-servers.net. 45.80% fan oanfragen nei de root-tsjinner wiene relatearre oan kontrôles útfierd troch browsers basearre op de Chromium-motor. Sa wurdt hast de helte fan 'e boarnen fan' e root-DNS-tsjinners bestege oan it útfieren fan Chromium-diagnostyske kontrôles ynstee fan it ferwurkjen fan fersiken fan 'e DNS-tsjinners om root-sônes te bepalen. Sjoen dat Chrome 70% fan 'e webbrowsermerk útmakket, resultearret sa'n diagnostyske aktiviteit yn sawat 60 miljard oanfragen dy't per dei nei root-tsjinners stjoerd wurde.
Diagnostyske kontrôles wurde brûkt yn Chromium om te detektearjen oft tsjinstferlieners tsjinsten brûke dy't fersiken nei net-besteande nammen trochferwize nei har handlers. Fergelykbere systemen wurde troch guon providers ymplementearre om ferkear te rjochtsjen nei domeinnammen dy't mei in flater ynfierd binne - yn 'e regel wurde foar net-besteande domeinen siden werjûn mei in flaterwarskôging, in list mei wierskynlik juste nammen oanbiede, en reklame. Boppedat ferneatiget sa'n aktiviteit de logika fan it bepalen fan intranethosts yn 'e browser folslein.
By it ferwurkjen fan in sykfraach ynfierd yn 'e adresbalke, as mar ien wurd sûnder stippen ynfierd wurdt, sil de browser earst bepale in opjûn wurd yn DNS, oannommen dat de brûker miskien besykje tagong te krijen ta in intranetside op in ynterne netwurk, ynstee fan in fraach nei in sykmasine te stjoeren. As de provider fragen trochlaat nei net-besteande domeinnammen, hawwe brûkers in probleem - alle ienwurdige sykfragen dy't ynfierd binne yn 'e adresbalke begjinne te wurde omlaat nei de siden fan' e provider, ynstee fan te stjoerd nei de sykmasine.
Om dit probleem op te lossen, hawwe Chromium-ûntwikkelders tafoege oan de browser , dy't, as trochferwizings ûntdutsen wurde, de logika foar it ferwurkjen fan oanfragen yn 'e adresbalke feroarje.
Elke kear as jo starte, jo DNS-ynstellingen feroarje, of jo IP-adres feroarje, stjoert de browser trije DNS-oanfragen mei willekeurige domeinnammen op earste nivo dy't nei alle gedachten net bestean. De nammen omfetsje fan 7 oant 15 Latynske letters (sûnder stippen) en wurde brûkt om de trochferwizing fan net-besteande domeinnammen troch de provider nei syn host te spoaren. As, by it ferwurkjen fan trije HTTP-oanfragen mei willekeurige nammen, twa in trochferwizing nei deselde side krije, dan fynt Chromium dat de brûker trochferwiisd is nei in side fan tredden.
Atypyske domeingrutte op earste nivo (fan 7 oant 15 letters) en de query-werhellingsfaktor (nammen waarden elke kear willekeurich oanmakke en waarden net werhelle) waarden brûkt as tekens om Chromium-aktiviteit te isolearjen fan 'e algemiene stream fan oanfragen op' e root-DNS-tsjinner.
Yn it logboek waarden oanfragen foar net-besteande domeinen earst filtere (78.09%), dêrnei waarden oanfragen dy't net mear as trije kear werhelle waarden selektearre (51.41%), en dêrnei waarden domeinen mei 7 oant 15 letters filtere (45.80%) . Ynteressant wiene mar 21.91% fan oanfragen nei root-tsjinners relatearre oan de definysje fan besteande domeinen.
De stúdzje ûndersocht ek de ôfhinklikens fan 'e groeiende lading op' e root-servers a.root-servers.net en j.root-servers.net op 'e groeiende populariteit fan Chrome.
Yn Firefox kontrolearret DNS-omlieding definiearje trochferwizings nei autentikaasje siden (captive portal) en с fêste subdomein "detectportal.firefox.com", sûnder it oanfreegjen fan earste-nivo domeinnammen. Dit gedrach makket gjin ekstra lading op 'e root-DNS-tsjinners, mar it kin mooglik as in lek fan fertroulike gegevens oer it IP-adres fan de brûker (de side "detectportal.firefox.com/success.txt" wurdt oanfrege elke kear as it wurdt lansearre). Om it skennen út te skeakeljen yn Firefox is d'r in ynstelling "network.captive-portal-service.enabled", dy't feroare wurde kin op 'e "about:config" side.
Boarne: opennet.ru