Près de la moitié du trafic vers les serveurs DNS racine est dû à l'activité de Chromium

Le registraire APNIC, responsable de la distribution des adresses IP dans la région Asie-Pacifique, publié résultats de l'analyse de la répartition du trafic sur l'un des serveurs DNS racine a.root-servers.net. 45.80 % des requêtes adressées au serveur racine étaient liées à des contrôles effectués par les navigateurs basés sur le moteur Chromium. Ainsi, près de la moitié des ressources des serveurs DNS racine sont consacrées à l'exécution de contrôles de diagnostic Chromium plutôt qu'au traitement des requêtes des serveurs DNS pour déterminer les zones racine. Étant donné que Chrome représente 70 % du marché des navigateurs Web, une telle activité de diagnostic entraîne l'envoi d'environ 60 milliards de requêtes aux serveurs racine par jour.

Les contrôles de diagnostic sont utilisés dans Chromium pour détecter si les fournisseurs de services utilisent des services qui redirigent les requêtes vers des noms inexistants vers leurs gestionnaires. Des systèmes similaires sont mis en œuvre par certains fournisseurs pour diriger le trafic vers les noms de domaine saisis avec une erreur - en règle générale, pour les domaines inexistants, les pages sont affichées avec un avertissement d'erreur, proposant une liste de noms probablement corrects et de la publicité. De plus, une telle activité détruit complètement la logique de détermination des hôtes intranet dans le navigateur.

Lors du traitement d'une requête de recherche saisie dans la barre d'adresse, si un seul mot est saisi sans points, le navigateur est d'abord essaie déterminer un mot donné dans DNS, en supposant que l'utilisateur tente d'accéder à un site intranet sur un réseau interne, plutôt que d'envoyer une requête à un moteur de recherche. Si le fournisseur redirige les requêtes vers des noms de domaine inexistants, les utilisateurs ont un problème : toutes les requêtes de recherche d'un seul mot saisies dans la barre d'adresse commencent à être redirigées vers les pages du fournisseur, plutôt que d'être envoyées au moteur de recherche.

Pour résoudre ce problème, les développeurs de Chromium ont ajouté au navigateur contrôles supplémentaires, qui, si des redirections sont détectées, modifient la logique de traitement des demandes dans la barre d'adresse.
Chaque fois que vous lancez, modifiez vos paramètres DNS ou modifiez votre adresse IP, le navigateur envoie trois requêtes DNS avec des noms de domaine aléatoires de premier niveau qui n'existent probablement pas. Les noms comprennent de 7 à 15 lettres latines (sans points) et servent à détecter la redirection de noms de domaine inexistants par le fournisseur vers son hébergeur. Si, lors du traitement de trois requêtes HTTP avec des noms aléatoires, deux reçoivent une redirection vers la même page, alors Chromium considère que l'utilisateur a été redirigé vers une page tierce.

Des tailles de domaine atypiques de premier niveau (de 7 à 15 lettres) et le facteur de répétition des requêtes (les noms étaient générés aléatoirement à chaque fois et n'étaient pas répétés) ont été utilisés comme signes pour isoler l'activité de Chromium du flux général de requêtes sur le serveur DNS racine.
Dans le journal, les demandes de domaines inexistants ont d'abord été filtrées (78.09 %), puis les demandes répétées au maximum trois fois ont été sélectionnées (51.41 %), puis les domaines contenant de 7 à 15 lettres ont été filtrés (45.80 %). . Il est intéressant de noter que seulement 21.91 % des requêtes adressées aux serveurs racine étaient liées à la définition de domaines existants.

Près de la moitié du trafic vers les serveurs DNS racine est dû à l'activité de Chromium

L'étude a également examiné la dépendance de la charge croissante sur les serveurs racine a.root-servers.net et j.root-servers.net à la popularité croissante de Chrome.

Près de la moitié du trafic vers les serveurs DNS racine est dû à l'activité de Chromium

Dans Firefox, vérifications de redirection DNS sont limités définir des redirections vers des pages d'authentification (portail captif) et mis en œuvre с en utilisant sous-domaine fixe « detectportal.firefox.com », sans demander de noms de domaine de premier niveau. Ce comportement ne crée pas de charge supplémentaire sur les serveurs DNS racine, mais il pourrait potentiellement être considéré comme une fuite de données confidentielles sur l’adresse IP de l’utilisateur (la page « detectportal.firefox.com/success.txt » est demandée à chaque lancement). Pour désactiver l'analyse dans Firefox, il existe un paramètre « network.captive-portal-service.enabled », qui peut être modifié sur la page « about:config ».

Source: opennet.ru

Ajouter un commentaire