Principe de fonctionnement détaillé du service DNS

Principe de fonctionnement détaillé du service DNS

Le service DNS signifiant Domain Name Services est né de la volonté de faciliter et de standardiser le processus d’identification des ressources connectées aux réseaux informatiques tels que l’Internet. Les machines ne sachant communiquer qu’à travers l’échange d’adresses IP difficiles à mémoriser pour l’homme, le DNS agit comme un annuaire téléphonique en fournissant la correspondance entre le nom de la machine et son adresse IP. Ainsi, lorsque l’on veut se connecter à un ordinateur dont on connaît le nom d’hôte, on interroge un serveur DNS qui nous renvoie l’adresse IP correspondant à ce nom.

Le DNS est un modèle réparti hiérarchisé, sa mise en œuvre requiert plusieurs serveurs qui prennent en charge individuellement la traduction de parties complémentaires de l’espace des noms afin de rendre plus souple le traitement des sollicitations. Ces parties appelées zones sont en fait des domaines de noms dont l’administration est définie et attribuée à un ou plusieurs serveurs.

Le domaine source d’où découlent les domaines de noms est appelé domaine Racine. Le domaine Racine est géré par les 13 serveurs DNS nommés « <x>.root-servers.net », où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN et WIDE). Afin d’assurer le bon maintien du service, ces serveurs sont en réalité redondés, soit localement, soit de manière répartie. Dans ce dernier cas, la technique de routage Anycast est utilisée afin d’associer l’adresse IP d’un serveur racine à plusieurs machines éloignées géographiquement permettant de répartir la charge des requêtes en toute transparence. Par exemple, le serveur racine « c.root-servers.org » est géré par la société Cogent et est en réalité composé de 6 serveurs répartis sur la planète. Pour plus d’information sur les serveurs roots vous pouvez consulter le site http://root-servers.org/

Les domaines adjacents au domaine racine sont les domaines dits de premier niveau ou TLD (Top Level Domain). Ils définissent la nature des organisations et leur provenance géographique. Le TLD ‘com’, le plus répandu, est géré par la société Vérisign sur 13 serveurs DNS. L’AFNIC gère actuellement 3 TLD : ‘fr’, ‘re’ et ‘tf’. La liste des 295 TLD existants est connue de tous les serveurs racines.

Enfin, les domaines de second niveau (SLD) décrivent plus précisément leur nom ou leur titre. Au niveau des domaines de second niveau, des milliers d’autres serveurs sont sollicités pour répondre aux besoins de traduction en adresse IP.

Le niveau terminal (le plus éloigné de la racine) désigne le nom d’hôte de la machine. Ainsi, une machine sur Internet est facilement repérable grâce à son nom d’hôte et à la chaîne d’appartenance à laquelle elle est reliée. La concaténation de la racine, du TLD, du SLD, des sous-domaines et du nom d’hôte séparés par un point est appelée nom FQDN (Fully Qualified Domain Name). La taille limite d’un FQDN est de 255 caractères. Par exemple : la machine qui sert de serveur mail dans l’entreprise Oktey s’appelle mail au sein d’Oktey et « mail.oktey.fr. » sur Internet.

L’ICANN justifie la limitation du nombre des serveurs racines à 13 par un argument technique : utiliser plus de 13 serveurs racines entraînerait des réponses à certaines requêtes DNS de plus de 512 octets. Or le protocole applicatif DNS fonctionne au-dessus du protocole de transport UDP limité à 512 octets de données. La généralisation de l’utilisation de TCP au lieu d’UDP, utilisé pour la synchronisation entre serveurs DNS, entrainerait une surcharge des serveurs DNS.

Pour bien comprendre le mécanisme présenté, la figure suivante décrit le principe d’une requête DNS. Dans l’exemple, l’utilisateur symbolisé en haut à gauche, souhaite accéder au serveur web présent sur la machine : « mail.oktey.fr ». Nous n’analyserons que le trafic DNS dans cet exemple et considérons que le serveur DNS local, n’a pas l’information requise en cache (en mémoire), sans quoi ce dernier répond directement à la demande.

Les commandes utilisées pour requêter le service DNS sont ‘nslookup’ sous Windows et ‘dig’ ou ‘host’ sous Linux. A défaut de connaitre l’IP de la machine contactée via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans « /etc/resolv.conf » (ou la configuration réseau sous Windows) pour effectuer ses requêtes. Pour chacune des étapes, nous allons détailler les commandes sous Linux de la forme : #commande et l’équivalent sous Windows avec le formalisme : >commande. Les réponses seront produites pour les commandes sous Windows, pour éviter d’alourdir l’article inutilement.

1) Le poste de l’utilisateur est configuré pour utiliser le resolver qui orientera sa requête vers le « Serveur DNS local », correspondant généralement à l’IP du serveur DNS de l’entreprise.

# dig mail.oktey.com

> nslookup
> mail.oktey.com

Si le serveur DNS local, possède la réponse en cache, il répondra immédiatement le résultat, sinon il se chargera de poursuivre en interrogeant successivement tous les serveurs DNS, les phases décrites ci-dessous : (2) Racine, (3) DNS de FR, puis (4) DNS de oktey.fr.

2) Le serveur DNS local n’a pas la connaissance sur l’IP affecté au serveur « mail.oktey.fr ». Il doit donc retrouver l’information auprès des serveurs de « oktey.fr. ». Pour cela, il va d’abord contacter les serveurs racine pour savoir qui gère « fr ». La liste des serveurs racine est connue de tous les serveurs DNS, c’est la seule information configurée en dur sur les serveurs DNS.

Pour avoir la liste des serveurs racines :

# dig . NS