Dans cette série d'articles sur l'hébergement, nous allons tenter de répondre aux interrogations que se posent éventuellement les webmasters ou les responsables de site quant aux manipulations à effectuer lors d'un changement d'hébergeur ou quant à la gestion de son ou ses nom(s) de domaines.

Nous commençerons par une présentation du système des noms de domaine.

Le Domain Name System a été mis en place pour identifier de manière plus simples les différents sites web: il s'agit d'un système de "traduction" des adresses IP, adresses attribuées de manière unique à chaque machine connectée à l'Internet (Les adresses IP sont en quelque sorte l'analogue des numéros de téléphone).

L'opération de traduction est appelée la "résolution du nom (de domaine)" et doit être parfaitement maîtrisée (de même qu'un numéro de téléphone doit bien aboutir à l'établissement de la bonne communication). C'est le rôle de l'ICANN que d'assurer le bon déroulement de la résolution des noms.

Quand un internaute tape un nom de domaine dans son navigateur (le client), celui-ci va envoyer une requête à un serveur de noms local (serveur DNS local) pour lui demander de trouver la bonne adresse IP (qui identifie parfaitement le nom de domaine demandé).

Si le serveur local ne trouve pas l'adresse IP en son sein, il va adresser lui-même une requête à un serveur de noms racine (serveur DNS root), qui va lui renvoyer l'adresse IP du serveur de nom desservant le TLD demandé (.com par exemple).
En pratique cela n'est pas tout à fait vrai, voici pourquoi:

- il existe 13 serveurs racines dans le monde, administrés et coordonnés par l'ICANN, et contenant les adresses IP des serveurs de noms (appelés "TLD registries", eux mêmes administrés et coordonnées par des organismes différents: InterNIC pour les domaines en .com, .org, .net; organisations nationales, telles l'AFNIC en France, pour les ccTLD comme .fr) desservant les différents TLDs;

- si toutes les requêtes (des centaines de milliards par jour!) étaient adressées directement aux serveurs racines, les performances chuteraient considérablement;

- aussi, il existe des centaines de DNR (Domain Names Resolvers) qui copient régulièrement les informations des serveurs racines, et sont utilisés pour traiter les requêtes théoriquement adressées aux serveurs racines (les DNR sont distribués pour servir au mieux les différents fournisseurs d'accès et réseaux instutionnels dans le monde).

Donc, le serveur DNS local ayant reçu l'adresse IP du TLD registry concerné (par exemple .com), va alors contacter ce dernier (en lui envoyant une requête), qui va lui répondre avec l'adresse IP du serveur de nom desservant le domaine "de niveau inférieur" demandé (par exemple supporttechnique.com).

Le DNS local va envoyer une nouvelle requête à ce dernier serveur de noms, qui va lui renvoyer l'adresse IP du nom de domaine entier (par exemple www.supporttechnique.com, ou ticket.supporttechnique.com): la résolution de noms est effectuée.

Tout cela est bien compliqué ? Oui, mais terriblement efficace, et permettant d'assurer l'intégrité du système entier des noms de domaines.

Une fois un nom de domaine déposé auprès d'un registrar (et les démarches effectuées auprès de l'organisme national concerné dans le cas d'un nom de domaine dont le suffixe est un ccTLD), on peut vouloir transférer l'enregistrement vers un autre registrar. Nous verrons dans un prochain article comment se déroule la procédure.

Plus fréquemment, on voudra changer d'hébergeur, et il faudra transférer non plus l'enregistrement du nom de domaine mais les destinations des requêtes vers ce nom de domaine. Nous allons clarifier ce point.

Si l'on possède un nom de domaine, on figure en tant que contact administratif de ce nom de domaine déposé auprès du registrar. A ce titre, il nous est possible de modifier les "DNS" faisant autorité sur ce domaine.

Par "DNS", on entend ici par abus de langage (Domain Name Server au lieu de Domain Name System) les informations faisant état de l'adresse IP et du nom d'hôte (qui n'est rien d'autre qu'un nom de domaine préfixé) du serveur de nom primaire, et les informations faisant état de l'adresse IP et du nom d'hôte du serveur de nom secondaire. La différence entre les deux est la suivante: le serveur secondaire tient lieu de "roue de secours" si, par exemple, le serveur primaire tombe en panne.

Lors d'un changement d'hébergeur avec transfert de nom de domaine (non un transfert d'enregistrement mais un transfert DNS), il faudra modifier ces "DNS" pour que les requêtes portant sur le nom de domaine que l'on possède pointent vers le serveur de noms correspondant. Cette modification sera répercutée ensuite sur les serveurs de noms de domaine "de niveau supérieur" (TLDs). Un certain laps de temps s'écoule (24-48H en général) avant que tous les serveurs DNS de la planète aient bien pris en compte la modification: cela est compréhensible une fois que l'on sait par quelle méthode itérative la résolution de noms s'effectue.

Un prochain article se penchera plus en avant sur les registrars et la base whois, afin de mieux comprendre comment sont enregistrés les noms de domaines. Par ailleurs, il nous reste à explorer la configuration d'un serveur DNS, et à préciser notamment la notion de "domaine virtuel". Enfin, nous aborderons des cas pratiques pour souligner comment l'hébergement peut influer grandement sur les performances de votre site, et pourquoi il est nécessaire de bien connaître et maîtriser les procédures de gestion de son nom de domaine lorsque le service n'est pas à la hauteur des attentes.

 Haut de page