APNIC-Registristo, respondeca por asignado de IP-adresoj en la Azi-Pacifika regiono, rezultoj de trafika distribua analizo sur unu el la radikaj DNS-serviloj a.root-servers.net. 45.80% de petoj al la radika servilo montriĝis rilataj al kontroloj faritaj de retumiloj bazitaj sur la Chromium-motoro. Tiel, preskaŭ duono de la rimedoj de la radikaj DNS-serviloj estas elspezitaj por fari Chromium-diagnozajn kontrolojn, kaj ne prilabori demandojn de DNS-serviloj dum determinado de radikaj zonoj. Kun Chrome respondecas pri 70% de la retumila merkato, ĉi tiu diagnoza agado rezultigas ĉirkaŭ 60 miliardojn da petoj al radikserviloj ĉiutage.
Diagnozaj kontroloj estas uzataj en Chromium por determini ĉu provizantoj de servoj uzas servojn, kiuj redirektas petojn por neekzistantaj nomoj al siaj prizorgantoj. Similaj sistemoj estas efektivigitaj de iuj provizantoj por direkti trafikon al si mem por domajnaj nomoj enigitaj kun eraro - kiel regulo, por neekzistantaj domajnoj, paĝoj estas montritaj kun erara averto, listo de verŝajne ĝustaj nomoj kaj reklamado. Samtempe tia agado tute detruas la logikon determini intraretajn gastigantojn en la retumilo.
Kiam oni prilaboras serĉpeton enigitan en la adresbreto, se nur unu vorto sen punktoj estas enigita, la retumilo unue faros difinu ĉi tiun vorton en DNS, supozante ke la uzanto eble provas aliri intraretejon en la interna reto, prefere ol sendi demandon al serĉilo. Se la provizanto alidirektas demandojn al neekzistantaj domajnaj nomoj, uzantoj havas problemon - ajnaj unuvortaj serĉdemandoj enigitaj en la adresbreto komencas esti redirektitaj al la paĝoj de la provizanto, kaj ne senditaj al la serĉilo.
Por solvi la problemon, Chromium-programistoj aldonis al la retumilo , kiuj, se alidirektiloj estas detektitaj, ŝanĝas la logikon por prilaborado de petoj en la adresbreto.
Ĉiufoje kiam vi komencas, ŝanĝas viajn DNS-agordojn aŭ ŝanĝas vian IP-adreson, la retumilo sendas tri DNS-demandojn kun hazardaj supernivelaj domajnaj nomoj, kiuj plej verŝajne ne ekzistas. Nomoj inkluzivas de 7 ĝis 15 latinajn literojn (sen punktoj) kaj estas uzataj por detekti alidirektado de neekzistantaj domajnaj nomoj de la provizanto al ĝia gastiganto. Se, kiam oni prilaboras tri HTTP-petojn kun hazardaj nomoj por du, oni ricevas alidirektilon al la sama paĝo, tiam Chromium konsideras, ke la uzanto estis redirektita al triaparta paĝo.
Kiel signoj por reliefigi la agadon de Chromium de la ĝenerala fluo de petoj sur la radika DNS-servilo, maltipaj grandecoj de la unuanivela domajno (de 7 ĝis 15 literoj) kaj peto-ripetebla faktoro (nomoj estis generitaj hazarde ĉiufoje kaj ne ripetiĝis) estis uzataj.
La protokolo unue filtris petojn por neekzistantaj domajnoj (78.09%), tiam elstarigis petojn, kiuj estis ripetitaj ne pli ol tri fojojn (51.41%), kaj poste filtris domajnojn kiuj inkludis de 7 ĝis 15 literoj (45.80%). Interese, nur 21.91% de petoj al la radikaj serviloj montriĝis rilataj al la difino de ekzistantaj domajnoj.
La studo ankaŭ ekzamenis kiel la ŝarĝo sur la radikaj serviloj a.root-servers.net kaj j.root-servers.net dependas de la kreskanta populareco de Chrome.
Fajrovulpo alidirektaj kontroloj per DNS difinante alidirektilojn al aŭtentigaj paĝoj (kaptiva portalo) kaj с fiksita subdomajno "detectportal.firefox.com", sen petado de unuanivelaj domajnaj nomoj. Ĉi tiu konduto ne kreas plian ŝarĝon sur la radikaj DNS-serviloj, sed eble povas kiel likado de sentemaj datumoj pri la IP-adreso de la uzanto (petante la paĝon "detectportal.firefox.com/success.txt" ĉe ĉiu lanĉo). Fajrovulpo havas agordon "network.captive-portal-service.enabled" por malŝalti la kontrolon, kiu povas esti ŝanĝita sur la paĝo "about:config".
fonto: opennet.ru