La théorie.
Chaque machine (imprimante, serveur, etc...) reliée à un réseau se voit attribuer un nom. Ce nom est unique dans le domaine auquel il appartient. Ainsi, pour les domaines « domaine1.com et domaine2.com », on peut avoir deux machines portant des noms similaires ou différents. Par exemple, mail.domaine1.com et mail.domaine2.com pointant sur deux adresses IP différentes.
On peut comparer cette adresse à un numéro de téléphone ou une adresse postale : Pour trouver un domicile de façon certaine, on commence par chercher le pays, puis la ville, puis la rue et en dernier le numéro. Ici avec le DNS c’est presque pareil : le pays est nom de domaine de NIVEAU HAUT. Ils sont bien connus de tous : .com .fr ? . Le nom de sous domaine peut-être assimilé au nom de la ville.
Comme un nom d’hôte complet est ordonné de façon logique, du plus précis au plus vague, le plus simple pour hiérarchiser la recherche est de le faire sur chaque partie du nom. Chaque serveur ne connaît que les noms de ses « fils » (le serveur pour .com sait comment atteindre www.titi.com mais pas www.toto.fr ), et renvoie à la racine les requêtes qu ?il ne sait pas résoudre. Celle tour, tente de résoudre une adresse IP en nom en renvoyant l’adresse du serveur pouvant répondre à cette question.
Donc, la hiérarchie DNS est divisée en zones. Une zone représente un domaine (fr, org, com, toto.com). Une zone parente peut déléguer une zone « fille » à un ou plusieurs serveurs de noms, et chaque zone est gérée par un serveur maître et éventuellement plusieurs serveurs secondaires dont le contenu est recopié à partir du serveur maître.
Conversion de nom en adresse IP.
Prenons un cas pratique : résolution du nom suivant : « toto.titi.tata.com »
– La machine cherchant à atteindre cet hôte contacte l’un des serveurs de noms par défaut (3 au maximum) ;
– Si le serveur de noms par défaut n’arrive pas à résoudre le nom, il contacte les serveurs de noms racine. Il faut donc que tous serveurs de noms aient au moins la liste de tous les serveurs de noms de la racine, ainsi que leurs adresses IP associées. Parmi les serveurs de noms à la racine, le premier à répondre reconnaît l’adresse comme valide, et renvoie l’adresse IP du serveur de noms capable de mieux répondre : celui de la zone .com (donc des noms de type xxxxx.com).
– Le DNS local interroge alors le DNS de la zone « .com ». Si ce serveur de noms n’est pas capable de résoudre « toto.titi.tata.com », il renvoie la liste des serveurs de noms de la zone « tata.com ».
– A son tour, un serveur de noms de la zone « tata.com » reconnaît le suffixe « tatat.com », le serveur de noms de zone « titi.tata.com », qui connaît l’adresse IP de « toto.titi.tata.com »
Il y aura eu donc au maximum 3 interrogations pour les 3 serveurs de noms par défaut, 1 pour celui de la zone racine (zone « . »), 1 pour celui de la zone .com, 1 pour celui de la zone tata.com, et 1 pour la zone titi.tata.com, soit 7 serveurs de noms interrogés. Chacun de ces serveurs de noms ne renvoie à chaque fois que l’adresse du DNS la plus apte à répondre.
De plus chaque serveur DNS garde en mémoire les dernières requêtes. Ainsi, si un nom est souvent demandé, il a toute les chances de figurer dans la mémoire du serveur qui n’aura pas besoin d’interroger les autres serveurs : la réponse sera directe.
L’avantage de cette méthode est qu’au lieu d ?avoir un serveur indexant toutes les machines du web, il y a des milliers de machines indexant un petit bout d’Internet, en l’occurrence leur sous domaine. Cela répartit les informations et les charges sur des milliers de machines. Il est donc nécessaire de configurer son propre serveur de DNS pour son réseau, si on veut que les noms des machines de son propre domaine soient résolus par d ?autres hôtes.
Conversion d’adresse IP en nom
Il est parfois utile de pouvoir résoudre un nom en adresse IP. Par exemple, en cas de connexion de la part d ?un hôte distant sur une machine, le nom de la machine distante est recherché dans un fichier tel que « /etc/host.equiv » pour une éventuelle connexion automatique. Or, au moment de la demande de connexion, la machine distante n’envoie que son adresse IP. Il faut donc résoudre cette adresse IP en nom, (cela permet au passage de vérifier que l’adresse IP est valide, et non pas détournée par un pirate).
Pour pouvoir résoudre une adresse IP en nom, un pseudo domaine a été mis en place : le domaine « in-addr.arpa »
En fait l’hôte www.titi.com, l’adresse 147.25.56.3.in-addr.arpa est un pointeur vers les vrais « Resource Record » de www.titi.com.
RSS 2.0