- La colocalisation des serveurs racine est fréquente mais généralement faible, ∼70% des points d’observation ayant constaté la colocalisation d’au moins deux serveurs.
- Si la majeure partie du trafic reste locale, de nombreuses demandes sont acheminées vers des répliques distantes. Les fournisseurs en amont et les politiques de routage individuelles jouent un rôle majeur à cet égard.
- La diversification de l’infrastructure de dernier saut sur certains sites peut améliorer la redondance.
Le système de noms de domaine (DNS) est une énorme base de données hiérarchisée et distribuée. Au sommet de cette hiérarchie, la zone racine, desservie par les serveurs racine, fournit le point de départ (logique) de toutes les résolutions de noms. Comme la plupart des applications Internet reposent sur le DNS, la résilience de ces serveurs racine est essentielle au fonctionnement de l’Internet.
Lisez : Le système des noms de domaine Internet expliqué aux non-initiés
Heureusement, le système de serveur racine (RSS) est un excellent exemple de système résilient. Cette résilience est obtenue grâce à des mesures de diversité et de redondance, telles que :
- 13 serveurs racine (identifiés par les lettres ‘a’ à ‘m’) gérés par 12 organisations indépendantes.
- Chaque serveur racine possède des répliques réparties géographiquement. Au total, le RSS contient plus de 1 900 instances de serveur.
- Ces instances utilisent des logiciels différents.
Avant d’examiner plus en détail la résilience du RSS, il est essentiel de comprendre comment mesurer un tel système distribué.
Configuration des mesures
Les serveurs racine utilisent l’IP Anycast pour diriger les clients vers les instances de serveur. Par exemple, un client japonais peut être dirigé vers une instance de serveur à Tokyo, tandis qu’un client européen peut se retrouver à Amsterdam, même si les deux clients ont communiqué la même adresse IP.
Cela signifie également que le comportement observé peut changer en fonction de la situation géographique ou topologique du client. Nous avons besoin de clients (ou de points d’observation) dans des réseaux du monde entier pour saisir ces différences.
Dans le cadre d’une étude récente, mes collègues et moi-même de l’Institut Max Planck d’informatique, du Deutsche Commercial Internet Exchange (DE-CIX) et de BENOCS GmbH avons utilisé 675 points d’observation du NLNOG RING dans 523 réseaux et 62 pays (figure 1).
Avec plus de 1 900 instances de serveurs, il peut être difficile de trouver de nouveaux lieux de déploiement. Il est généralement intéressant de se déployer dans des endroits disposant d’une bonne connectivité (locale), tels que les centres de données ou les points d’échange Internet (IXP). Cependant, la réutilisation de la même infrastructure de dernier saut peut réduire la redondance d’une configuration anycast.
En collectant des traceroutes depuis nos points d’observation vers les 13 serveurs racine différents, nous pouvons quantifier la réutilisation de l’infrastructure du dernier saut. Si deux itinéraires à partir d’un point d’observation partagent l’avant-dernier saut (le dernier saut étant le serveur racine lui-même), il est probable que ces serveurs racine soient situés au même endroit. Nous définissons alors la “redondance réduite” comme le nombre total d’avant-derniers sauts moins le nombre unique.
Notre étude a révélé qu’une certaine colocalisation est courante, 70 % des points d’observation ayant constaté la colocalisation d’au moins deux serveurs. À certains points d’observation, par exemple en Océanie (figure 2), nous avons observé une redondance réduite significative (n=6) pour IPv6.
Cependant, une “redondance réduite” n’est pas nécessairement meilleure. Par exemple, en Afrique, nous avons constaté que le trafic est acheminé hors du continent (ce qui augmente le nombre de chemins uniques), même si des répliques locales, telles que l.root, sont disponibles. Cela souligne le rôle et l’importance des fournisseurs en amont lorsqu’il s’agit de la résilience des RSS.
Maintenir le trafic au niveau local
Comme nous l’avons vu, le trafic “à redondance réduite” de l’Afrique est parfois acheminé hors du continent.
Toutefois, le maintien du trafic au niveau local peut améliorer la résilience et constitue un objectif explicite de l’Internet Society.
Il est à noter que les performances brutes (en termes de RTT) ne sont pas une préoccupation majeure pour les serveurs racine, car leurs réponses sont généralement mises en cache dans les résolveurs locaux.
En utilisant des requêtes spéciales et une carte publique des sites de serveurs, nous pouvons demander à un serveur de nous donner un identifiant d’instance réel et calculer la distance entre le point d’observation de la requête et la réplique du serveur qui répond.
La figure 3 montre la différence de distance entre l’instance globale la plus proche géographiquement et celle vers laquelle chaque requête adressée à b.root a été acheminée. 78 % des requêtes sont acheminées vers la réplique globale la plus proche et atterrissent sur la diagonale.
Nous avons également observé un groupe de demandes qui parcourent 5 000 à 10 000 kilomètres supplémentaires. Ces demandes proviennent de points d’observation situés en Europe et sont acheminées vers l’Amérique du Nord. Là encore, nous constatons que ces effets sont souvent dus aux décisions d’acheminement des fournisseurs en amont.
En savoir plus
Si vous avez trouvé cela intéressant, consultez notre article, dans lequel nous fournissons une analyse plus approfondie, examinons un changement d’adresse IP dans le RSS et évaluons le mécanisme de transfert de zone dans le contexte du nouvel enregistrement ZONEMD.
Florian Steurer est doctorant à l’Institut Max Planck d’informatique. Ses recherches portent sur la mesure du DNS et de la résilience.
Photo par Bas van Schaik VIA Wikimedia Commons
