Bijna de helft van het verkeer naar de root DNS-servers wordt veroorzaakt door de activiteit van Chromium.

De registrar APNIC, verantwoordelijk voor de verdeling van IP-adressen in de regio Aziƫ-Pacific, gepubliceerd de resultaten van de analyse van het verkeer op een van de root DNS-servers a.root-servers.net. 45,80% van de verzoeken aan de rootserver bleken gerelateerd te zijn aan controles uitgevoerd door browsers op basis van de Chromium-engine. Bijna de helft van de middelen van de root DNS-servers gaat dus naar het uitvoeren van diagnostische controles van Chromium, en niet naar het verwerken van verzoeken van DNS-servers bij het bepalen van de rootzones. Gezien het feit dat Chrome 70% van de markt voor web-browsers beslaat, leidt dergelijke diagnostische activiteit tot ongeveer 60 miljard verzoeken aan de rootservers per dag.

Diagnostische controles worden in Chromium gebruikt om te bepalen welke providers van diensten verzoeken naar niet-bestaande namen omleiden naar hun eigen handlers. Dergelijke systemen worden door sommige providers geĆÆmplementeerd om verkeer naar verkeerd ingevoerde domeinnamen naar zichzelf te leiden — doorgaans worden voor niet-bestaande domeinen foutwaarschuwingspagina's getoond, samen met een lijst van waarschijnlijk correcte namen en advertenties. Dergelijke activiteit verstoort echter volledig de logica van intranet-hosts in de browser.

Bij het verwerken van een zoekopdracht die in de adresbalk is ingevoerd, als er maar ƩƩn woord zonder punten is ingevoerd, probeert de browser eerst te dit woord in DNS te identificeren, in de veronderstelling dat de gebruiker mogelijk probeert toegang te krijgen tot een intranet site binnen het interne netwerk, in plaats van een verzoek naar de zoekmachine te sturen. In het geval dat de provider verzoeken naar niet-bestaande domeinnamen omleidt, hebben gebruikers een probleem — elke zoekopdracht van ƩƩn woord die in de adresbalk is ingevoerd, begint omgeleid te worden naar de pagina's van de provider, in plaats van naar de zoekmachine.

Om dit probleem op te lossen, hebben de ontwikkelaars van Chromium extra controles toegevoegd, die, wanneer omleidingen worden ontdekt, de logica voor het verwerken van verzoeken in de adresbalk wijzigen.
Bij elke start, wijziging van DNS-instellingen of wijziging van het IP-adres, stuurt de browser drie DNS-verzoeken met willekeurige namen van top-level domeinen die zeer waarschijnlijk niet bestaan. De namen bestaan uit 7 tot 15 Latijnse letters (zonder punten) en worden gebruikt om de omleiding van niet-bestaande domeinnamen door de provider naar zijn hosting te identificeren. Als bij de verwerking van drie HTTP-verzoeken met willekeurige namen voor twee een omleiding naar dezelfde pagina wordt ontvangen, beschouwt Chromium dit als een aanwijzing dat de gebruiker is omgeleid naar een externe pagina.

Voor het identificeren van de activiteit van Chromium uit de totale stroom verzoeken naar de root DNS-server werden atypische groottes van het top-level domein (van 7 tot 15 letters) en de herhalingsfactor van verzoeken (de namen werden telkens willekeurig gegenereerd en herhaalden zich niet) gebruikt.
In het logboek werden aanvankelijk de verzoeken van niet-bestaande domeinen gefilterd (78,09%), daarna werden verzoeken geselecteerd die niet meer dan drie keer voorkwamen (51,41%), en vervolgens werden domeinen gefilterd die bestonden uit 7 tot 15 letters (45,80%). Het is interessant dat slechts 21,91% van de verzoeken naar de rootservers verband hield met het vaststellen van bestaande domeinen.

Bijna de helft van het verkeer naar de root DNS-servers wordt veroorzaakt door de activiteit van Chromium.

Tijdens het onderzoek werd ook de afhankelijkheid van de toename van de belasting op de root-servers a.root-servers.net en j.root-servers.net van de toenemende populariteit van Chrome bestudeerd.

Bijna de helft van het verkeer naar de root DNS-servers wordt veroorzaakt door de activiteit van Chromium.

In Firefox zijn de controles voor omleidingen via DNS beperkt tot het vaststellen van omleiding naar authenticatiepagina's (captive portal) en zijn gerealiseerd met het gebruik van de vaste subdomein "detectportal.firefox.com", zonder verzoeken om top-level domeinnamen. Dit gedrag creƫert geen extra belasting op de root DNS-servers, maar kan potentieel worden beschouwd als een lek van vertrouwelijke gegevens over het IP-adres van de gebruiker (bij elke start wordt de pagina "detectportal.firefox.com/success.txt" opgevraagd). Om de controle in Firefox uit te schakelen, is er een instelling "network.captive-portal-service.enabled", die kan worden gewijzigd op de pagina "about:config".

Bron: opennet.ru

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster