De l'importance de l'hébergement...
Première partie: Comprendre le système des DNS
Comment fonctionne le système de traduction des adresses IP en noms de domaines? Quels organismes sont concernés? Connaître les réponses à ces questions est un préalable à la bonne gestion de son hébergement.
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çons par une présentation
du système des noms de domaine.
Dépôt d'un nom de domaine
Le dépôt d'un nom de domaine (par exemple "journaldunet.com",
mais bien sûr celui-ci est déjà pris...) s'effectue
auprès d'un "bureau d'enregistrement" ("registrar"
en anglais), organisme intermédiaire entre les demandeurs
(ou titulaires) de noms de domaine, et l'ICANN
(Internet Corporation for Assigned Names and Numbers), société
à but non lucratif responsable de l'allocation des adresses IP
dans le monde via le système des noms de domaine.
Il existe une centaine de registrars agréés par l'ICANN.
Citons par exemple Gandi,
ou CORE, ce
dernier étant par ailleurs une association de registrars.
Bien sûr, tout n'est pas si simple, car il est très
différent de vouloir déposer un nom de domaine en
.com, .net, .org (ou .biz, .info...) et de vouloir déposer
un nom de domaine en .fr par exemple.
Avant d'aller plus loin, penchons-nous plus précisément
sur l'organisation des noms de domaines dans le monde.
Les différents types de domaines
Le Domain Name System (DNS)
est un répertoire distribué s'appuyant sur une
structure de noms hiérachisée. Le sommet de la
hiérachie est le domaine dit "racine" (administré
par l'ICANN), d'où partent des branches qui sont les domaines
dit "de niveau supérieur" soit, en anglais, les
Top Level Domains (TLDs). Des exemples de TLDs
sont .com, .org, .net, .fr, etc.
On distingue les gTLDs (generic Top Level Domains:
les .com, .org, .net, .biz, .info...) et les ccTLDs (country
code Top Level Domains: les suffixes nationaux que sont .fr,
.ca, .nl, .es, .it...).
Des TLDs partent de nouvelles branches qui sont les domaines dit
"de niveau inférieur" (journaldunet.com par exemple).
Résolution de noms
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 journaldunet.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.journaldunet.com, ou developpeurs.journaldunet.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.
Changement de registrar et changement d'hébergeur
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.
[Jérôme
Morlon 08
Décembre 2001 , JDNet]
|