Près de la moitié du trafic vers les serveurs DNS racine est causée par l'activité de Chromium.

L'enregistreur APNIC responsable de la répartition des adresses IP dans la région Asie-Pacifique, a publié les résultats de l'analyse du trafic sur l'un des serveurs DNS racine a.root-servers.net. 45,80 % des requêtes vers le serveur racine étaient liées à des vérifications effectuées par des 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 vérifications de diagnostic de Chromium, plutôt qu'au traitement de requêtes des serveurs DNS pour déterminer les zones racines. Étant donné que Chrome détient 70 % du marché des navigateurs web, cette activité de diagnostic conduit à l'envoi de près de 60 milliards de requêtes aux serveurs racine par jour.

Les vérifications de diagnostic sont utilisées dans Chromium pour déterminer l'application par les fournisseurs de services qui redirigent les requêtes vers des noms inexistants vers leurs propres gestionnaires. De tels systèmes sont implémentés par certains fournisseurs pour diriger le trafic vers eux vers des noms de domaine correctement orthographiés — en règle générale, des pages d'avertissement d'erreur, une liste de noms probablement corrects et de la publicité sont affichées pour des domaines inexistants. Cela détruit complètement la logique de détermination des hôtes intranet dans le navigateur.

Lors de la traitement d'une requête de recherche saisie dans la barre d'adresse, si un seul mot sans points est saisi, le navigateur commence par essaie déterminer ce mot dans le DNS, supposant que l'utilisateur essaie d'accéder à un site intranet au sein du réseau interne, plutôt que d'envoyer une requête à un moteur de recherche. Dans le cas où le fournisseur redirige les requêtes vers les noms de domaine inexistants, les utilisateurs rencontrent un problème : toutes les requêtes de recherche d'un mot, saisies dans la barre d'adresse, commencent à être redirigées vers des 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é dans le navigateur des vérifications supplémentaires, qui, en cas de détection de redirections, modifient la logique de traitement des requêtes dans la barre d'adresse.
À chaque lancement, modification des paramètres DNS ou changement d'adresse IP, le navigateur envoie trois requêtes DNS avec des noms de domaine de premier niveau aléatoires, qui n'existent probablement pas. Ces noms contiennent entre 7 et 15 lettres latines (sans points) et sont utilisés pour identifier le redirectionnement des noms de domaine inexistants par le fournisseur vers son hébergement. Si, lors du traitement des trois requêtes HTTP avec des noms aléatoires, deux d'entre elles obtenaient une redirection vers la même page, Chromium considère que l'utilisateur a été redirigé vers une page externe.

Des caractéristiques pour distinguer l'activité de Chromium dans le flux général des requêtes sur le serveur DNS racine ont compris des tailles atypiques de domaines de premier niveau (de 7 à 15 lettres) et le facteur de répétition des requêtes (les noms étant générés aléatoirement et non répétitifs à chaque fois).
Dans le journal, les requêtes de domaines inexistants ont d'abord été filtrées (78,09 %), puis les requêtes répétées pas plus de trois fois ont été isolées (51,41 %), et ensuite les domaines comprenant de 7 à 15 lettres ont été filtrés (45,80 %). Il est intéressant de noter que seulement 21,91 % des requêtes aux serveurs racines étaient liées à la détermination de domaines existants.

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

Dans Firefox, les vérifications de redirection via DNS sont limitées à la détermination de la redirection vers les pages d'authentification (captive portal) et sont implémentés avec à l'utilisation du sous-domaine fixe «detectportal.firefox.com», sans requête sur les noms de domaine de premier niveau. Ce comportement ne crée pas de charge supplémentaire sur les serveurs DNS racines, mais pourrait potentiellement être considéré comme une fuite de données confidentielles sur l'adresse IP de l'utilisateur (une requête de la page «detectportal.firefox.com/success.txt» est effectuée à chaque lancement). Pour désactiver la vérification dans Firefox, il existe un paramètre «network.captive-portal-service.enabled», qui peut être modifié sur la page «about:config».

Source : opennet.ru