Le navigateur Chromium, le parent open source florissant de Google Chrome et du nouveau Microsoft Edge, a reçu une attention négative importante pour une fonctionnalité conçue avec de bonnes intentions : il vérifie si le FAI de l'utilisateur "vole" des résultats de requête de domaine inexistants. .
, qui crée de fausses requêtes pour des « domaines » aléatoires dont l'existence est statistiquement improbable, est responsable d'environ la moitié du trafic total reçu par les serveurs DNS racine dans le monde. L'ingénieur Verisign, Matt Thomas, a écrit un long article sur le blog de l'APNIC décrivant le problème et évaluant son ampleur.
Comment la résolution DNS est généralement effectuée
Ces serveurs sont la plus haute autorité que vous devez contacter pour résoudre les domaines .com, .net, etc. afin qu'ils vous disent que frglxrtmpuf n'est pas un domaine de premier niveau (TLD).
DNS, ou Domain Name System, est un système par lequel les ordinateurs peuvent résoudre des noms de domaine mémorables comme arstechnica.com en adresses IP beaucoup moins conviviales comme 3.128.236.93. Sans DNS, Internet n’existerait pas d’une manière que les humains pourraient utiliser, ce qui signifie qu’une charge inutile sur l’infrastructure de niveau supérieur constitue un réel problème.
Le chargement d’une seule page Web moderne peut nécessiter un nombre incroyable de recherches DNS. Par exemple, lorsque nous avons analysé la page d'accueil d'ESPN, nous avons dénombré 93 noms de domaine distincts, allant de a.espncdn.com à z.motads.com. Tous sont nécessaires pour que la page se charge complètement !
Pour répondre à ce type de charge de travail pour un moteur de recherche qui doit servir le monde entier, le DNS est conçu comme une hiérarchie à plusieurs niveaux. Au sommet de cette pyramide se trouvent les serveurs racine : chaque domaine de premier niveau, tel que .com, possède sa propre famille de serveurs qui constituent la plus haute autorité pour chaque domaine situé en dessous. Un pas en avant ces les serveurs sont les serveurs racine eux-mêmes, de a.root-servers.net à m.root-servers.net.
A quelle fréquence ceci se passe-t-il?
Grâce à la hiérarchie de mise en cache à plusieurs niveaux de l'infrastructure DNS, un très petit pourcentage des requêtes DNS mondiales atteint les serveurs racine. La plupart des gens obtiennent les informations de leur résolveur DNS directement auprès de leur FAI. Lorsque l'appareil d'un utilisateur a besoin de savoir comment accéder à un site Web spécifique, une 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 transmet la requête à ses propres « redirecteurs » (si spécifiés).
Si ni le serveur DNS du fournisseur local ni les « serveurs de transfert » spécifiés dans sa configuration n'ont de réponse en cache, la demande est adressée directement au serveur de domaine faisant autorité. au-dessus celui que vous essayez de convertir. Quand домен.com cela signifie que la demande est envoyée aux serveurs faisant autorité du domaine lui-même com, qui sont situés à gtld-servers.net.
Système gtld-servers, auquel la demande a été adressée, répond avec une liste de serveurs de noms faisant autorité pour le domaine domain.com, ainsi qu'au moins un enregistrement de lien contenant l'adresse IP d'un de ces serveurs de noms. Ensuite, les réponses descendent dans la chaîne : chaque transitaire transmet ces réponses au 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 mettent en cache cette réponse afin de ne pas perturber inutilement les systèmes de niveau supérieur.
Dans la plupart des cas, le serveur de noms enregistre pour domaine.com sera déjà mis en cache sur l'un de ces redirecteurs, afin que les serveurs racine ne soient pas perturbés. Cependant, pour l’instant, nous parlons du type d’URL que nous connaissons : celle qui est convertie en un site Web classique. Les requêtes Chrome sont au niveau au-dessus ceci, sur le pas des clusters eux-mêmes root-servers.net.
Vérification du vol Chromium et NXDomain
Chromium vérifie « est-ce que ce serveur DNS me trompe ? » représentent près de la moitié de tout le trafic atteignant le cluster de serveurs DNS racine de Verisign.
Le navigateur Chromium, le projet parent de Google Chrome, du nouveau Microsoft Edge et d'innombrables navigateurs moins connus, souhaite offrir aux utilisateurs la facilité de recherche dans une seule boîte, parfois appelée « Omnibox ». En d’autres termes, l’utilisateur saisit à la fois les URL réelles et les requêtes des moteurs de recherche dans le même champ de texte en haut de la fenêtre du navigateur. Faisant un autre pas vers la simplification, cela n'oblige pas non plus l'utilisateur à saisir une partie de l'URL avec 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 doit être considéré comme une requête de recherche. Dans la plupart des cas, cela est assez évident : par exemple, une chaîne contenant des espaces ne peut pas être une URL. Mais les choses peuvent devenir plus délicates lorsque l’on considère les intranets, des réseaux privés qui peuvent également utiliser des domaines privés de premier niveau pour résoudre de vrais sites Web.
Si un utilisateur sur l'intranet de son entreprise saisit « marketing » et que l'intranet de l'entreprise possède un site Web interne portant le même nom, Chromium affiche une boîte d'informations demandant à l'utilisateur s'il souhaite rechercher « marketing » ou accéder à https://marketing. Ce n’est peut-être pas le cas, mais de nombreux FAI et fournisseurs de Wi-Fi publics « détournent » chaque URL mal orthographiée, redirigeant l’utilisateur vers une page remplie de bannières.
Génération aléatoire
Les développeurs de Chromium ne voulaient pas que les utilisateurs des réseaux classiques voient une boîte d'information leur demandant ce qu'ils voulaient dire à chaque fois qu'ils recherchaient un seul mot. Ils ont donc mis en œuvre un test : lorsqu'ils lancent un navigateur ou changent de réseau, Chromium effectue des recherches DNS sur trois mots. "domaines" générés aléatoirement de premier niveau, longs de sept à quinze caractères. Si deux de ces requêtes reviennent avec la même adresse IP, Chromium suppose que le réseau local « détourne » les erreurs. NXDOMAIN, qu'il devrait recevoir, de sorte que le navigateur considère toutes les requêtes d'un seul mot saisies comme des tentatives de recherche jusqu'à nouvel ordre.
Malheureusement, dans les réseaux qui aucun voler les résultats des requêtes DNS, ces trois opérations remontent généralement tout en haut, jusqu'aux serveurs de noms racine eux-mêmes : le serveur local ne sait pas comment résoudre qwajuixk, transmet donc cette demande à son transitaire, qui fait de même, jusqu'à ce qu'enfin a.root-servers.net ou alors l'un de ses « frères » ne sera pas obligé de dire « Désolé, mais ce n'est pas un domaine ».
Puisqu'il existe environ 1,67*10^21 faux noms de domaine possibles, allant de sept à quinze caractères, le plus courant chaque à partir de ces tests effectués sur le réseau « honnête », il parvient au serveur racine. Cela revient à autant moitié de la charge totale sur le DNS racine, selon les statistiques de cette partie des clusters root-servers.net, qui appartiennent à Verisign.
L'histoire se répète
Ce n'est pas la première fois qu'un projet créé avec les meilleures intentions ou presque inondé une ressource publique avec un trafic inutile - cela nous a immédiatement rappelé la longue et triste histoire du serveur NTP (Network Time Protocol) de D-Link et Poul-Henning Kamp au milieu des années 2000.
En 2005, le développeur FreeBSD Poul-Henning, qui possédait également le seul serveur Stratum 1 Network Time Protocol du Danemark, a reçu une facture inattendue et importante pour le trafic transmis. En bref, la raison en était que les développeurs de D-Link ont écrit les adresses des serveurs NTP Stratum 1, y compris le serveur Kampa, dans le micrologiciel de la gamme de commutateurs, routeurs et points d'accès de l'entreprise. Cela a instantanément multiplié par neuf le trafic du serveur de Kampa, ce qui a amené le Danish Internet Exchange (le point d'échange Internet du Danemark) à modifier son tarif de « gratuit » à « 9 000 $ par an ».
Le problème n’était pas qu’il y avait trop de routeurs D-Link, mais qu’ils étaient « hors ligne ». Tout comme le DNS, NTP doit fonctionner sous une forme hiérarchique : les serveurs de la strate 0 transmettent les informations aux serveurs de la strate 1, qui transmettent les informations aux serveurs de la strate 2, et ainsi de suite dans la hiérarchie. Un routeur domestique, un commutateur ou un point d'accès typique comme celui que D-Link avait programmé avec des adresses de serveur NTP enverrait des requêtes au serveur Stratum 2 ou Stratum 3.
Le projet Chromium, probablement avec les meilleures intentions du monde, a reproduit le problème NTP dans le problème DNS, chargeant les serveurs racine d'Internet de requêtes qu'ils n'étaient jamais censés traiter.
Il y a de l'espoir pour une solution rapide
Le projet Chromium est open source , ce qui nécessite de désactiver le détecteur de redirection intranet par défaut pour résoudre ce problème. Il faut donner du crédit au projet Chromium : le bug a été trouvé avant çacomment Matt Thomas de Verisign lui a attiré beaucoup d'attention avec son sur le blog de l'APNIC. Le bug a été découvert en juin, mais est resté oublié jusqu'au message de Thomas ; Après avoir jeûné, il commença à être étroitement surveillé.
On espère que le problème sera bientôt résolu et que les serveurs DNS racine n'auront plus à répondre aux 60 milliards de fausses requêtes estimées chaque jour.
Comme la publicité
Serveurs épiques - Est ou Linux avec de puissants processeurs de la famille AMD EPYC et des disques Intel NVMe très rapides. Dépêchez-vous de commander !
Source: habr.com