Le navigateur Chromium, le parent open-source en pleine évolution de Google Chrome et du nouveau Microsoft Edge, a attiré une attention négative sérieuse en raison d'une fonctionnalité conçue avec de bonnes intentions : elle vérifie si le fournisseur ne « vole » pas à l'utilisateur des résultats de recherche de domaines inexistants.
, générant de fausses requêtes pour des « domaines » aléatoires dont l'existence est statistiquement peu probable, est responsable d'environ la moitié du trafic total reçu par les serveurs DNS racine à travers le monde. L'ingénieur de Verisign, Matt Thomas, a écrit un long sur le blog d'APNIC décrivant le problème et évaluant son ampleur.
Comment la résolution DNS est généralement effectuée
Ces serveurs constituent la dernière instance à laquelle il convient de s'adresser pour résoudre des domaines tels que .com, .net, etc., afin qu'ils vous informent que frglxrtmpuf n'est pas un domaine de premier niveau (TLD).
Le DNS, ou système de noms de domaine, est un système qui permet aux ordinateurs de convertir des noms de domaine mémorables comme arstechnica.com en adresses IP beaucoup moins conviviales, par exemple 3.128.236.93. Sans DNS, Internet ne pourrait exister sous une forme accessible aux humains, et donc la charge indésirable sur l'infrastructure de haut niveau est un véritable problème.
Pour charger une seule page web moderne, un nombre incroyable d'opérations de recherche DNS peut être nécessaire. Par exemple, lorsque nous avons analysé la page d'accueil d'ESPN, nous avons compté 93 noms de domaine distincts, allant de a.espncdn.com à z.motads.com. Tous sont nécessaires pour le chargement complet de la page !
Pour que le système de recherche puisse supporter une telle charge, le DNS est conçu comme une hiérarchie multilevel. Au sommet de cette pyramide se trouvent les serveurs racine : chaque domaine de premier niveau, comme .com, a sa propre famille de serveurs qui sont la dernière instance pour chaque domaine en dessous d'eux. Juste un niveau au-dessus de ces serveurs se trouvent les serveurs racine eux-mêmes, à partir de a.root-servers.net à m.root-servers.net.
À quelle fréquence cela se produit-il ?
Grâce à la hiérarchie de mise en cache à plusieurs niveaux de l'infrastructure DNS, un très faible pourcentage des requêtes DNS mondiales atteint les serveurs racines. La plupart des gens obtiennent des informations du résolveur DNS directement auprès de leur fournisseur. Lorsqu'un appareil utilisateur doit savoir comment accéder à un site Web spécifique, la requête est d'abord envoyée à un serveur DNS géré par ce fournisseur local. Si le serveur DNS local ne connaît pas la réponse, il redirige la requête vers ses propres « serveurs de transfert » (s'ils sont spécifiés).
Si ni le serveur DNS du fournisseur local ni les « serveurs de transfert » spécifiés dans sa configuration n'ont une réponse mise en cache, la requête est directement envoyée au serveur de domaine autorisé. supérieur à celui que vous essayez de résoudre. Dans le cas de domaine.com cela signifie que la requête est envoyée aux serveurs autorisés du domaine lui-même. com, qui se trouvent à l'adresse gtld-servers.net.
Le système serveurs gtld, le serveur auquel la requête a été faite répond avec une liste de serveurs de noms autorisés pour le domaine domaine.com, ainsi qu'au moins un enregistrement de liaison contenant l'adresse IP d'un tel serveur de noms. Ensuite, les réponses sont transmises en chaîne : chaque serveur de transfert transmet ces réponses vers le serveur qui les a demandées, jusqu'à ce que la réponse atteigne finalement le serveur du fournisseur local et l'ordinateur de l'utilisateur. Tous cachent cette réponse afin de ne pas déranger les systèmes de niveau supérieur.
Dans la plupart des cas, les enregistrements des serveurs de noms pour domaine.com seront déjà mis en cache sur l'un de ces serveurs de transfert, donc les serveurs racines ne sont pas dérangés. Cependant, tant que nous parlons de l'URL familière - celle qui est résolue en un site Web normal. Les requêtes Chrome concernent le niveau supérieur de cela, au niveau même des clusters root-servers.net.
Chromium et la vérification de l'usurpation NXDomain
Les vérifications de Chromium « ce serveur DNS ne me trompe pas ? » représentent presque la moitié de tout le trafic atteignant le cluster des serveurs DNS racines Verisign.
Le navigateur Chromium, le projet parent de Google Chrome, du nouveau Microsoft Edge et de nombreux autres navigateurs moins connus, souhaite offrir aux utilisateurs une expérience de recherche simplifiée dans un seul champ, parfois appelé « Omnibox ». En d'autres termes, l'utilisateur peut saisir à la fois de véritables URL et des requêtes de moteur de recherche dans le même champ de texte en haut de la fenêtre du navigateur. Pour aller encore plus loin dans la simplification, il ne demande également pas à l'utilisateur de saisir une partie de l'URL. http:// ou https://.
Aussi pratique que cela puisse paraître, cette approche nécessite que le navigateur comprenne ce qui doit être considéré comme une URL et ce qui est une requête de recherche. Dans la plupart des cas, cela est assez évident — par exemple, une chaîne avec des espaces ne peut pas être une URL. Mais tout peut devenir plus complexe lorsque l'on considère les intranets — des réseaux privés qui peuvent également utiliser des domaines de premier niveau privés pour résoudre de véritables sites web.
Si un utilisateur dans l'intranet de son entreprise saisit « marketing » et qu'il existe un site web interne portant ce nom, alors Chromium affichera une fenêtre contextuelle demandant à l'utilisateur s'il souhaite rechercher « marketing » ou se rendre sur https://marketing. Cela pourrait aller, mais de nombreux fournisseurs d'accès à Internet et fournisseurs de réseaux Wi-Fi publics « détournent » chaque URL mal orthographiée saisie en redirigeant l'utilisateur vers une page remplie de bannières publicitaires.
Génération aléatoire
Les développeurs de Chromium ne souhaitaient pas que les utilisateurs sur des réseaux standards voient à chaque recherche d'un seul mot une fenêtre contextuelle leur demandant ce qu'ils voulaient dire, ils ont donc implémenté un test : lors du démarrage du navigateur ou du changement de réseau, Chromium effectue des recherches DNS pour trois « domaines » de premier niveau générés aléatoirement, dont la longueur varie de sept à quinze caractères. Si deux de ces requêtes retournent la même adresse IP, alors Chromium suppose que le réseau local « détourne » les erreurs NXDOMAIN, qu'il devrait recevoir, donc jusqu'à nouvel ordre, le navigateur considère toutes les requêtes à un mot comme des tentatives de recherche.
Malheureusement, dans les réseaux qui ne détournent pas les résultats des requêtes DNS, ces trois opérations sont généralement portées au niveau supérieur, jusqu'aux serveurs de noms racines : le serveur local ne sait pas comment résoudre qwajuixk, donc il renvoie cette demande à son serveur de relais, qui fait de même jusqu'à ce que finalement, a.root-servers.net ou l'un de ses « frères » soit contraint de dire « Désolé, mais ce n'est pas un domaine ».
Étant donné qu'il existe environ 1,67*10^21 noms de domaine falsifiés possibles d'une longueur de sept à quinze caractères, le plus souvent chacun de ces tests effectués dans un réseau « honnête » parvient au serveur DNS racine. Cela représente environ la moitié de la charge totale sur les DNS racines, si l'on en croit les statistiques de la partie des clusters root-servers.net, qui appartiennent à la société Verisign.
L'histoire se répète
Ce n'est pas le premier cas où un projet créé avec les meilleures intentions ou a failli submerger une ressource publique avec un trafic non nécessaire — cela nous rappelle immédiatement la longue et triste histoire de D-Link et du serveur NTP (Network Time Protocol) de Poul-Hennings Kamp au milieu des années 2000.
En 2005, le développeur de FreeBSD, Poul-Henning, qui possédait également le seul serveur NTP de niveau Stratum 1 au Danemark, a reçu une facture inattendue et élevée pour le trafic transmis. En résumé, la raison était que les développeurs de D-Link avaient inscrit les adresses des serveurs NTP Stratum 1, y compris celle de Kamp, dans le firmware de sa gamme de commutateurs, de routeurs et de points d'accès. Cela a instantanément multiplié par neuf le trafic du serveur de Kamp, ce qui a entraîné un changement de son tarif de « Gratuit » à « 9 000 dollars par an » de la part de Danish Internet Exchange (le point d'échange du trafic Internet au Danemark).
Le problème n'était pas le nombre excessif de routeurs D-Link, mais le fait qu'ils « enfreignaient la hiérarchie ». Tout comme le DNS, le NTP doit fonctionner de manière hiérarchique — les serveurs de niveau Stratum 0 transmettent les informations aux serveurs de Stratum 1, qui transmettent les informations aux serveurs de Stratum 2, et ainsi de suite, en descendant dans la hiérarchie. Un routeur domestique ordinaire, un commutateur ou un point d'accès comme ceux dans lesquels D-Link a intégré les adresses des serveurs NTP auraient dû envoyer des demandes au serveur Stratum 2 ou Stratum 3.
Le projet Chromium, probablement avec les meilleures intentions, a répété le problème du NTP dans le problème du DNS, en surchargeant les serveurs racines d'Internet avec des requêtes qu'ils n'auraient jamais dû traiter.
Il y a de l'espoir pour une résolution rapide
Il existe un rapport ouvert dans le projet Chromium , nécessitant la désactivation par défaut du Détecteur de Redirection Intranet pour résoudre ce problème. Il faut rendre hommage au projet Chromium : le bug a été découvert avant que, Matt Thomas de Verisign n'attire une attention considérable avec son sur le blog d'APNIC. Le bug a été signalé en juin, mais est resté dans l'oubli jusqu'à l'article de Thomas ; après sa publication, il a commencé à être surveillé de près.
On espère que le problème sera bientôt résolu et que les serveurs DNS racine n'auront plus à répondre chaque jour à environ 60 milliards de requêtes fictives.
En tant que publicité
Serveurs Épiques — ce sont des ou Linux avec des processeurs puissants de la famille AMD EPYC et des disques NVMe Intel très rapides. Commandez dès maintenant !
Source : habr.com
