commentaires des lecteurs
230
avec 104 affiches participantes, y compris l'auteur de l'histoire
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Le navigateur Chromium - open source, parent en amont de Google Chrome et du nouveau Microsoft Edge - fait l'objet d'une sérieuse attention négative pour une fonctionnalité bien intentionnée qui vérifie si le FAI d'un utilisateur « détourne » des résultats de domaine inexistants.
Les
Détecteur de redirection intranet
, qui rend statistiquement peu probable l'existence de fausses requêtes pour des "domaines" aléatoires, est responsable d'environ la moitié du trafic total reçu par les serveurs DNS racine du monde. L'ingénieur Verisign Matt Thomas a écrit un long blog APNIC
Publier
exposer le problème et définir sa portée.
Comment fonctionne normalement la résolution DNS
Agrandir
/
Ces serveurs sont l'autorité finale qui doit être consultée pour résoudre .com, .net, et ainsi de suite—et pour vous dire que 'frglxrtmpuf' n'est pas un vrai TLD.
Jim Salter
DNS, ou Domain Name System, est la façon dont les ordinateurs traduisent des noms de domaine relativement mémorables comme arstechnica.com en adresses IP beaucoup moins mémorables, comme 3.128.236.93. Sans DNS, Internet ne pourrait pas exister sous une forme utilisable par l'homme, ce qui signifie qu'une charge inutile sur son infrastructure de haut niveau est un réel problème.
Le chargement d'une seule page Web moderne peut nécessiter un nombre vertigineux de recherches DNS. Lorsque nous avons analysé la page d'accueil d'ESPN, nous avons compté 93 noms de domaine distincts, de a.espncdn.com à z.motads.com, qui devaient être exécutés pour charger complètement la page !
Afin de maintenir la charge gérable pour un système de recherche qui doit desservir le monde entier, DNS est conçu comme une hiérarchie à plusieurs étages. 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 l'autorité ultime pour chaque domaine en dessous. Un cran au dessus
celles
sont les serveurs racine réels,
a.root-servers.net
par
m.root-servers.net
.
A quelle fréquence ceci se passe-t-il?
Un très petit pourcentage des requêtes DNS mondiales atteint en fait les serveurs racines, en raison de la hiérarchie de mise en cache à plusieurs niveaux de l'infrastructure DNS. La plupart des gens obtiendront leurs informations de résolution DNS directement auprès de leur FAI. Lorsque leur appareil doit savoir comment atteindre
arstechnica.com
, la requête va d'abord à ce serveur DNS géré par le FAI local. Si le serveur DNS local ne connaît pas la réponse, il transmettra la requête à ses propres « transitaires », le cas échéant.
Si ni le serveur DNS local du FAI ni aucun "transitaire" défini dans sa configuration n'a la réponse mise en cache, la requête finit par remonter directement aux serveurs faisant autorité pour le domaine
dessus
celui que vous essayez de résoudre - pour
arstechnica.com
, cela signifierait interroger les serveurs faisant autorité pour
com
lui-même, à
gtld-servers.net
.
Publicité
Les
serveurs-gtld
le système interrogé répond avec une liste de serveurs de noms faisant autorité pour le
arstechnica.com
domaine, ainsi qu'au moins un enregistrement « colle » contenant l'adresse IP d'un tel serveur de noms. Désormais, les réponses remontent le long de la chaîne - chaque transitaire transmet ces réponses au serveur qui l'a interrogé jusqu'à ce que la réponse atteigne enfin à la fois le serveur du FAI local et l'ordinateur de l'utilisateur - et tous le long de la ligne cachent cette réponse pour éviter de déranger inutilement des systèmes "en amont".
Pour la grande majorité de ces requêtes, les enregistrements NS pour
arstechnica.com
sera déjà mis en cache sur l'un de ces serveurs de transfert, de sorte que les serveurs racine n'ont pas besoin d'être dérangés. Jusqu'à présent, cependant, nous parlons d'une sorte d'URL plus familière, qui correspond à un site Web normal. Les requêtes de Chrome ont atteint un niveau supérieur
cette
, au réel
serveurs-racines.net
grappes elles-mêmes.
Chromium et le test de détournement de NXDomain
Agrandir
/
"Est-ce que ce serveur DNS est avec moi ?" les sondes représentent environ la moitié de tout le trafic atteignant le cluster de serveur racine DNS de Verisign.
Matthieu Thomas
Le navigateur Chromium, projet parent de Google Chrome, du nouveau Microsoft Edge et d'innombrables autres navigateurs moins connus, veut offrir aux utilisateurs la simplicité d'une recherche à une seule case, parfois appelée "Omnibox". En d'autres termes, vous saisissez à la fois les URL réelles et les requêtes des moteurs de recherche dans la même zone de texte en haut de votre navigateur. Pour aller encore plus loin dans la facilité d'utilisation, cela ne vous oblige pas à taper le
http://
ou
https://
partie de l'URL, non plus.
Aussi pratique que cela puisse être, cette approche nécessite que le navigateur comprenne ce qui doit être traité comme une URL et ce qui doit être traité comme une requête de recherche. Pour la plupart, c'est assez évident : tout ce qui contient des espaces ne sera pas une URL, par exemple. Mais cela devient délicat lorsque l'on considère les intranets, des réseaux privés, qui peuvent utiliser des TLD tout aussi privés qui se résolvent en sites Web réels.
Si un utilisateur sur l'intranet d'une entreprise tape « marketing » et que l'intranet de cette entreprise possède un site Web interne du même nom, Chromium affiche une barre d'informations demandant à l'utilisateur s'il a l'intention de rechercher « marketing » ou de naviguer vers
https://marketing
. Jusqu'à présent, tout va bien, mais de nombreux FAI et fournisseurs de Wi-Fi partagés détournent chaque URL mal saisie, redirigeant l'utilisateur vers une page de destination chargée d'annonces.
Générer au hasard
Les auteurs de Chromium ne voulaient pas avoir à voir les barres d'informations "Voulez-vous dire" sur chaque recherche d'un seul mot dans ces environnements communs, ils ont donc mis en place un test : au démarrage ou au changement de réseau, Chromium émet des recherches DNS pour trois sept générés au hasard. "domaines" de premier niveau à 15 caractères. Si deux de ces requêtes reviennent avec la même adresse IP, Chromium suppose que le réseau local détourne le
NXDOMAIN
erreurs qu'il devrait recevoir - il traite donc toutes les entrées à un seul mot comme des tentatives de recherche jusqu'à nouvel ordre.
Publicité
Malheureusement, sur les réseaux qui
ne sont pas
détournant les résultats des requêtes DNS, ces trois recherches ont tendance à se propager jusqu'aux serveurs de noms racine : le serveur local ne sait pas comment résoudre
qwajuixk
, il renvoie donc cette requête à son transitaire, qui lui rend la pareille, jusqu'à ce que finalement
a.root-servers.net
ou l'un de ses frères et sœurs doit dire "Désolé, ce n'est pas un domaine."
Puisqu'il y a environ 1,67*10^21 faux noms de domaine possibles de sept à 15 caractères, pour la plupart
tous
une de ces sondes émise sur un réseau honnête dérange finalement un serveur racine. Cela fait un énorme
demi
la charge totale sur les serveurs DNS racine, si l'on se fie aux statistiques de la part de Verisign du
serveurs-racines.net
groupes.
L'histoire se répète
Ce n'est pas la première fois qu'un projet bien intentionné
inondé
ou presque inondé une ressource publique d'un trafic inutile - nous nous sommes immédiatement rappelé la longue et triste histoire du serveur NTP (Network Time Protocol) de D-Link et Poul-Henning Kamp, du milieu des années 2000.
En 2005, Poul-Henning Kamp, un développeur FreeBSD, qui dirigeait également le seul serveur de protocole de temps réseau Stratum 1 du Danemark, a reçu une énorme facture de bande passante inattendue. Pour faire court, les développeurs de D-Link ont codé en dur les adresses de serveur NTP Stratum 1, y compris celles de Kamp, dans le micrologiciel de la gamme de commutateurs, de routeurs et de points d'accès de l'entreprise. Cela a immédiatement multiplié par neuf l'utilisation de la bande passante du serveur de Kamp, obligeant le Danish Internet Exchange à modifier sa facture de « Gratuit » à « Ce sera 9 000 $ par an, s'il vous plaît ».
Le problème n'était pas qu'il y avait trop de routeurs D-Link, c'était qu'ils « sautaient la chaîne de commandement ». Tout comme le DNS, NTP est conçu pour fonctionner de manière hiérarchique : les serveurs Stratum 0 alimentent les serveurs Stratum 1, qui alimentent les serveurs Stratum 2, et sur toute la ligne. Un simple routeur domestique, commutateur ou point d'accès comme ceux dans lesquels D-Link avait codé en dur ces serveurs NTP devrait interroger un serveur Stratum 2 ou Stratum 3.
Le projet Chromium, vraisemblablement avec les meilleures intentions à l'esprit, a traduit le problème NTP en un problème DNS en chargeant les serveurs racine d'Internet de requêtes qu'ils ne devraient jamais avoir à traiter.
Résolution en vue
Il y a un ouvert
bogue
dans le projet Chromium demandant que le détecteur de redirection intranet soit désactivé par défaut pour résoudre ce problème. Pour être juste envers le projet Chromium, le bogue a en fait été ouvert
avant
Matt Thomas de Verisign a tracé un cercle rouge géant autour du problème dans son blog APNIC
Publier
. Le bug a été ouvert en juin mais a langui jusqu'au poste de Thomas ; depuis le poste de Thomas, il a reçu une attention quotidienne.
Espérons que le problème sera bientôt résolu et que les serveurs DNS racine du monde n'auront plus besoin de répondre à environ 60 milliards de fausses requêtes chaque jour.
Image de la liste par
Matthieu Thomas
