DNS : La résolution de noms sur l'Internet

La résolution DNS (Domain Name System) permet de retrouver l'adresse IP d'un serveur à partir d'un nom de domaine. Description du fonctionnement global du système DNS, des différentes résolutions, et des types d'enregistrements.

Le DNS, qu'est-ce que c'est ?

Le système de gestion de noms est une énorme architecture hiérarchisée qui permet de gérer les noms de domaine sur internet, qui sont bien plus faciles à retenir que des adresses IP.

Par exemple, ils permettent d'associer www.google.com aux adresses 209.85.229.104, 209.85.229.99 et 209.85.229.147.

L'architecture

L'architecture est divisée en zones, chaque zone étant gérée par un ou plusieurs serveurs.

La zone de plus haut niveau est la zone racine (root), désignée par le point final « . ». Cette racine est divisée en plusieurs zones appelées top-level domains (domaines de plus haut niveau). Concrètement, il s'agit de com, org, net, fr, us, be, it, info, etc.

On représente généralement l'architecture par ce schéma:

On voit que ce qui est en bas du schéma se retrouve à gauche d'une adresse. Par exemple, sur le schéma dans l'adresse www.yahoo.com, on a une machine appelée www.yahoo.com qui appartient au domaine yahoo.com, qui est un sous-domaine de la zone com, qui elle même est un sous-domaine de la zone racine (le "point").

Un domaine est le nom plus commun d'une zone. (et un sous-domaine est plus joli à prononcer qu'une sous-zone)

C'est ça, au détail près qu'un serveur peut gérer plusieurs zones, mais nous partirons du principe qu'on a un serveur (ou plus) par zone.
Chaque serveur gère sa zone, mais pas les zones situées au dessous. La gestion de ces zones est déléguée à d'autres serveurs.

Le fonctionnement global

On voit sur ce schéma qu'il y a une zone nommée arpa. Il s'agit de la zone inverse (reverse). Jusqu'ici, ce qui a été décrit est une association 1 nom une ou plusieurs IP (directe). La zone reverse permet de faire l'association inverse, c'est à dire 1 IP un ou plusieurs noms. C'est très important, car tout résultat donnée par une résolution directe sera vérifié par une résolution inverse.
Pour que l'association nom <=> IP fonctionne correctement, il faut donc que les associations directe et inverse fonctionnent.

Exactement, toute association directe correspond à une association inverse.

Pas perdu(e) ? Allez, on continue !

Le dialogue client/serveur

Eh oui, le protocole DNS est, comme beaucoup d'autres protocoles, basé sur une architecture matérielle client/serveur.

Le principe de base est simple: quand vous tapez par exemple www.google.fr dans la barre d'adresses de votre navigateur, votre PC (qui est donc client ici) va demander à un serveur DNS de lui donner une adresse correspondant au nom www.google.fr.

C'est ce que l'on appelle une requête récursive. Le PC client pose la question à un serveur, et le serveur renvoie la réponse finale au PC client.

Bien entendu, si je parle de requêtes récursives, c'est qu'il en existe d'autres, appelées requêtes itératives. Je viens de dire que le serveur qui reçoit la requête de la part du client lui renvoie la réponse finale. C'est grâce aux requêtes récursives qu'il va y arriver.

Le principe des requêtes itératives est légèrement pus complexe que celui des requêtes récursives. Ici, le serveur, pour trouver la réponse finale, va aller récupérer la réponse progressivement en descendant toute la hiérarchie (Cf schéma plus haut) petit à petit.

Je m'explique: Vous pouvez simuler ces échanges en tapant les commandes indiquées ci-dessous dans un terminal Linux.

Première étape

Le client demande l'adresse IP de www.google.com à un serveur, généralement le serveur DNS de son fournisseur d'accès (FAI).

dig www.google.com

Vous obtenez ici la réponse finale. C'est normal, vu que le serveur de votre FAI est configuré pour aller vous la chercher.

Deuxième étape

Le serveur du FAI commence par poser la question aux serveurs racine (ceux qui gèrent la zone point). Ces serveurs sont au nombre de 13 : a.root-servers.net, b.root-servers.net, ... m.root-servers.net.

Un de ces 13 serveurs est choisi au hasard (et également en fonction de la situation géographique pour diminuer le temps de réponse), pour permettre la répartition de la charge. Imaginez le monde entier qui demande un nom en même temps, s'il n'y avait qu'un serveur, il ne tiendrait pas le coup !

Nous choisirons pour l'exemple le serveur a.root-servers.net.

dig www.google.com @a.root-servers.net

Ces serveurs sont en place depuis de nombreuses années, et ne changent pas d'adresse IP. La liste de ces serveurs et de leurs adresses IP est donc intégrée à chaque serveur DNS, c'est la clef de voûte du système de noms.

Troisième étape

Le serveur racine reçoit la demande et répond avec les connaissances dont il dispose. Comme chaque serveur ne gère que sa zone, il renvoie la première partie: Je sais que la zone .com est gérée par le serveur a.gtld-servers.com.

Le serveur racine ne va pas chercher la réponse finale, contrairement au serveur du FAI, il répond ce qu'il connaît, et laisse le serveur du FAI se débrouiller pour aller chercher la suite !

Non, mais cette zone "appartient" indirectement à la zone racine (puisqu'elle appartient à la zone com qui appartient à la racine), les serveurs racine peuvent donc donner leurs adresses IP, puisqu'ils les connaissent.

Quatrième étape

Le serveur du FAI va donc ensuite aller demander au serveur a.gtld-servers.com l'adresse de www.google.com. Ces serveurs sont également au nombre de 13, et le choix est fait au hasard et en fonction de la localisation comme pour les serveurs racine.

dig www.google.com @a.gtld-servers.com

Cinquième étape

Comme il ne connaît pas la réponse, a.gtld-servers.com va répondre à partir de ce qu'il connaît, comme à la troisième étape: Je sais que la zone google.com est gérée par les serveurs ns1.google.com, ns2.google.com, ns3.google.com et ns4.google.com.

Sixième étape

Le serveur du FAI pose alors la question à un des 4 serveurs DNS de google.com.

dig www.google.com @ns1.google.com

Septième étape

Cette fois, le serveur connaît la réponse finale ! En effet, www.google.com appartient à la zone google.com.

Huitième étape

Maintenant qu'il a obtenu la réponse finale, le serveur du FAI peut la renvoyer au client.

Les requêtes

Pour en revenir à nos deux types de requêtes, on a une requête récursive lors de la première étape, alors que les étapes 2, 4 et 6 sont des requêtes itératives.

Dans le cas d'une requête récursive, le client attend la réponse exacte à la question qu'il a posée, alors que dans le cas d'une requête récursive, le client (ici c'est le serveur du FAI qui est client lors des requêtes itératives) attend juste un indice pour pouvoir progresser vers la réponse finale.

Non, il ne les connaît pas. De base, un serveur DNS tel que ceux des FAI ne connaît que les 13 serveurs racine. Mais c'est le serveur racine qui a donné l'adresse IP du serveur a.gtld-servers.com, il la connaît et a le droit de la donner, car a.gtld-servers.com appartient indirectement à la zone racine. C'est ce que l'on appelle un glue record dans le jargon, je détaillerai ça un peu plus tard.

Les enregistrements DNS

Les associations connues par un serveur DNS sont appelées enregistrements de données (Resource Record) et sont regroupées en plusieurs types, qui sont au nombre de 5:

• Le champ de type A: C'est le plus simple, il associe un nom à une adresse IP. Comme plusieurs adresses IP peuvent être associées au même nom, il peut y avoir plusieurs champs A pour un même nom.


• Le champ de type NS: Il permet de déléguer la gestion d'un sous-domaine à un autre serveur. Exemple: les réponses des serveurs racine et gtld-servers.com sont des réponses de type NS, elles donnent uniquement l'adresse du serveur qui gère la zone suivante.


• Le champ de type CNAME: Il permet simplement de définir un second nom (Canonical NAME). On voit par exemple à l'étape 6 que www.google.com est un CNAME de www.l.google.com


• Le champ de type MX: Il précise l'adresse (ou le nom) du serveur mail de la zone. Pour exemple, tapez:
  

  dig google.com MX



• Le champ de type PTR: Il est utilisé uniquement pour la résolution inverse, il permet d'associer une IP à un nom. C'est le champ inverse du champ A.


• Le champ de type HINFO: Un champ HINFO précise des informations sur l'hôte, comme le matériel, l'OS, etc. Il est généralement déconseillé de le renseigner, pour éviter de donner des informations sur le serveur.


• Le champ SOA: Il définit l'autorité sur la zone (Start Of Authority) décrit quel est le serveur de noms qui a autorité sur la zone (serveur maître, voir ci-dessous), et l'adresse du contact technique de la zone.

Serveur maître, serveur esclave

Je viens de vous parler de serveur maître, mais qu'est-ce que c'est ?

Comme je l'ai déjà dit, une même zone peut être gérée par plusieurs serveurs. Dans ce cas, un de ces serveurs est déclaré comme maître de la zone (master), et les autres comme esclaves (slaves).

Cela permet de mettre à jour automatiquement tous les serveurs esclaves dès qu'on modifie le maître. Cela réduit le nombre de serveurs à gérer, vu qu'on en a plus qu'un seul pour la zone. Les autres sont des copies automatiques.

La résolution inverse

La résolution inverse est, comme son nom l'indique, l'inverse de celle détaillée jusqu'ici. Elle permet donc de trouver le ou les noms associés à une adresse IP. Elle est utilisée automatiquement lors de la résolution directe pour vérifier la concordance des adresse des serveurs DNS de la zone demandée.

Par ju2cho7 , Le 03 Novembre 2010 à 17h16
Ce tutoriel est la propriété d'Aidoweb et ne peut en aucun cas être copié.

Retour à Internet & Réseaux

Commentaires sur cet article

quel est l'interet de l'installation du DNS

Tres bien expliqué. Simple.
dig www.google.com @a.root-servers.net est interrogeable directement? (par nous, j'entend)

En tout cas. Merci

merci de votre information