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

De APNIC-registrar, verantwoordelijk voor de distributie van IP-adressen in de regio Azië-Pacific, gepubliceerd resultaten van analyse van de verkeersdistributie op een van de root-DNS-servers a.root-servers.net. 45.80% van de verzoeken aan de rootserver hadden betrekking op controles uitgevoerd door browsers op basis van de Chromium-engine. Bijna de helft van de bronnen van de root-DNS-servers wordt dus besteed aan het uitvoeren van diagnostische Chromium-controles in plaats van aan het verwerken van verzoeken van de DNS-servers om de rootzones te bepalen. Aangezien Chrome 70% van de webbrowsermarkt voor zijn rekening neemt, resulteren dergelijke diagnostische activiteiten erin dat ongeveer 60 miljard verzoeken per dag naar rootservers worden verzonden.

In Chromium worden diagnostische controles gebruikt om te detecteren of serviceproviders services gebruiken die verzoeken omleiden naar niet-bestaande namen naar hun handlers. Soortgelijke systemen worden door sommige providers geïmplementeerd om verkeer naar domeinnamen te leiden die met een fout zijn ingevoerd. In de regel worden voor niet-bestaande domeinen pagina's weergegeven met een foutwaarschuwing, met een lijst met waarschijnlijk correcte namen en advertenties. Bovendien vernietigt dergelijke activiteit de logica van het bepalen van intranethosts in de browser volledig.

Als bij het verwerken van een zoekopdracht die in de adresbalk is ingevoerd, slechts één woord zonder punten wordt ingevoerd, zal de browser eerst proberen een bepaald woord in DNS bepalen, ervan uitgaande dat de gebruiker probeert toegang te krijgen tot een intranetsite op een intern netwerk, in plaats van een zoekopdracht naar een zoekmachine te sturen. Als de provider zoekopdrachten doorverwijst naar niet-bestaande domeinnamen, hebben gebruikers een probleem: alle zoekopdrachten die uit één woord bestaan, worden in de adresbalk omgeleid naar de pagina's van de provider, in plaats van naar de zoekmachine te worden gestuurd.

Om dit probleem op te lossen, hebben Chromium-ontwikkelaars aan de browser toegevoegd extra controles, die, als omleidingen worden gedetecteerd, de logica voor het verwerken van verzoeken in de adresbalk wijzigen.
Elke keer dat u de browser start, uw DNS-instellingen wijzigt of uw IP-adres wijzigt, verzendt de browser drie DNS-verzoeken met willekeurige domeinnamen van het eerste niveau die hoogstwaarschijnlijk niet bestaan. De namen bevatten 7 tot 15 Latijnse letters (zonder punten) en worden gebruikt om de doorverwijzing van niet-bestaande domeinnamen door de provider naar zijn host te detecteren. Als er bij het verwerken van drie HTTP-verzoeken met willekeurige namen twee een omleiding naar dezelfde pagina ontvangen, gaat Chromium ervan uit dat de gebruiker is omgeleid naar een pagina van derden.

Atypische domeingroottes op het eerste niveau (van 7 tot 15 letters) en de herhalingsfactor van de zoekopdracht (namen werden elke keer willekeurig gegenereerd en werden niet herhaald) werden gebruikt als tekenen om Chromium-activiteit te isoleren van de algemene stroom van verzoeken op de root-DNS-server.
In het logboek werden eerst verzoeken voor niet-bestaande domeinen gefilterd (78.09%), daarna werden verzoeken geselecteerd die niet meer dan drie keer werden herhaald (51.41%), en vervolgens werden domeinen met 7 tot 15 letters gefilterd (45.80%) . Interessant genoeg was slechts 21.91% van de verzoeken aan rootservers gerelateerd aan de definitie van bestaande domeinen.

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

In het onderzoek werd ook gekeken naar de afhankelijkheid van de groeiende belasting van de rootservers a.root-servers.net en j.root-servers.net en de groeiende populariteit van Chrome.

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

In Firefox worden DNS-omleidingen gecontroleerd zijn beperkt het definiëren van omleidingen naar authenticatiepagina's (captive portal) en geïmplementeerd с gebruik makend van vast subdomein “detectportal.firefox.com”, zonder domeinnamen op het eerste niveau aan te vragen. Dit gedrag veroorzaakt geen extra belasting op de root-DNS-servers, maar kan dit wel doen worden overwogen als een lek van vertrouwelijke gegevens over het IP-adres van de gebruiker (de pagina “detectportal.firefox.com/success.txt” wordt elke keer dat deze wordt gestart opgevraagd). Om het scannen 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

Voeg een reactie