Anycast, une nouvelle technique de gestion d'un parc de serveur de noms

Stephane Bortzmeyer

	Note
	Cet article a été publié à l'origine dans DNS New Pro.

Pour tous les gérants de domaine, le placement des serveurs de noms est un casse-tête. Si on gère un TLD (Top-Level Domain), tout changement, même mineur, nécessite d'affronter la très lente bureaucratie IANA. On devient conservateur, en hésitant à ajouter des serveurs, même lorsque c'est nécessaire.

Si on gère la racine, le problème est encore plus aigü : l'intensité du trafic sur les serveurs de noms de la racine (dans les 6 000 requêtes par seconde en temps normal mais beaucoup plus si une attaque est en cours) est telle qu'il faudrait multiplier leur nombre. L'ICANN limite ce nombre à 13 (pour des raisons qui ne sont pas purement techniques).

Enfin, que l'on gère la racine ou bien un TLD, on doit souvent se demander si un endroit un peu reculé du réseau ne nécessiterait pas un serveur de noms du domaine, même si le trafic y est faible et que ce serveur ne serait normalement pas "rentable".

À tous ces problèmes, l'anycast fournit des éléments de réponse. C'est une technique permettant de placer plusieurs répliques d'un même serveur, répondant à la même adresse IP, en différents endroits. Je passe sur la technique, en notant juste que le protocole BGP (Border Gateway Protocol), utilisé par les opérateurs Internet, permet d'annoncer le même préfixe de réseau en plusieurs endroits, fournissant ainsi une méthode d'anycast immédiatement opérationnelle.

Comme toutes les répliques ont la même adresse IP, aucun changement n'est nécessaire dans les bases du domaine supérieur (la racine, si on gère un TLD) lorsqu'on ajoute ou retire une réplique.

Par contre, toutes les répliques doivent être identiques (doivent servir le même contenu), si on ne veut pas perturber sérieusement les utilisateurs : elles sont donc gérées par le même organisme.

À l'heure actuelle, cinq serveurs de noms de la racine, C, F, I, J et K sont ainsi anycastés, prouvant que la technologie fonctionne. Il est piquant que l'ICANN, qui répète "ad nauseam" son intérêt pour "la stabilité de l'Internet" ne se soit jamais manifesté à ce sujet.

Par contre, peu de TLD ont des serveurs anycastés pour l'instant. Le seul cas dont je sois sûr est le Mexique, parmi ceux qui gèrent eux-même leurs serveurs. Ceux qui sous-traitent à UltraDNS (".org", ".info", le Honduras, etc) bénéficient également de l'anycast.

Du point de vue politique, l'anycast permet :

de réduire les inégalités géographiques bien connues (seulement deux serveurs en Europe et un en Asie mais ce n'est plus vrai avec l' anycast). Cela ne change pas le contrôle des serveurs (il est toujours exact de dire que seuls deux serveurs sont contrôlés depuis l'Europe) mais cela relativise le problème. Avec des arguments techniques peu convaincants, l'ICANN a toujours refusé d'augmenter le nombre de serveurs de noms pour corriger les inégalités citées ci-dessus. Avec l'anycast, plus besoin de leur autorisation.
Pour un ccTLD, s'affranchir partiellement de l'ICANN et de son inefficacité à assurer la fonction IANA. Le NIC peut ainsi gérer son ensemble de serveurs de noms (en ajouter, en retirer) sans même prévenir l'ICANN.