<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
     "dtd/xml/4.1.2/docbookx.dtd">
<article lang="fr">
<title><foreignphrase>Anycast</foreignphrase>, une nouvelle technique de gestion d'un parc de serveur de noms</title>
<articleinfo>
    <author>
    <firstname>Stephane</firstname><surname>Bortzmeyer</surname>
    </author>
  </articleinfo>
  <note><para>Cet article a été publié à l'origine dans <ulink
  url="http://www.dnsnewspro.com/">DNS New Pro</ulink>.</para>
  </note>

<para>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.</para>

<para>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).</para>

<para>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".</para>

<para>À tous ces problèmes, l'<foreignphrase>anycast</foreignphrase> 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 <ulink url="http://www.generic-nic.net/formation/routage-dyn/bgp/">BGP (Border
Gateway Protocol)</ulink>, 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'<foreignphrase>anycast</foreignphrase> immédiatement opérationnelle.</para>

<para>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.</para>

<para>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.</para>

<para>À l'heure actuelle, cinq serveurs de noms de la racine, C, F, I, J et
K sont ainsi <foreignphrase>anycastés</foreignphrase>, 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.</para>

<para>Par contre, peu de TLD ont des serveurs <foreignphrase>anycastés</foreignphrase> 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'<foreignphrase>anycast</foreignphrase>.</para>

<para>Du point de vue politique, l'<foreignphrase>anycast</foreignphrase> permet :

<itemizedlist>
<listitem><para>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'
<foreignphrase>anycast</foreignphrase>). 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'<foreignphrase>anycast</foreignphrase>, plus besoin de leur
autorisation.</para>
      </listitem>
<listitem><para>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.</para>
      </listitem>
    </itemizedlist>
</para>

</article>


