gluke - Fotolia
Ce qu’il faut savoir sur le DNS
Le système des noms de domaine est une pierre angulaire d’Internet. Mais pour beaucoup d’administrateurs, au-delà de la correspondance directe entre noms d’hôtes et adresses IP, les détails du DNS restent assez flous.
Le système DNS est un service essentiel d’Internet que l’on tient souvent pour acquis. Preuve s’il en est, la bataille rangée qu’a déclenchée la demande d’activation d’une fonction standard du système DNS. J’ai découvert à cette occasion que pour beaucoup d’administrateurs, au-delà de la correspondance directe entre noms d’hôtes et adresses IP, les détails du DNS étaient assez flous.
Ce guide, conçu pour clarifier ce qu’est le DNS, s’adresse à l’administrateur d’entreprise qui doit déployer un nouveau service ou veut simplement en savoir davantage.
Description du processus de résolution de noms
Quand un appareil client se connecte à un service Internet quel qu’il soit, la toute première étape est de lancer une recherche DNS. Certains services, en particulier sur les réseaux internes, utilisent une adresse IP inscrite en dur dans le code. Certes, cette approche facilite leur fonctionnement, mais ces services sont moins flexibles ; le système DNS apporte une couche d’abstraction vraiment utile entre les applications et les hôtes physiques. En l’occurrence, même si la traduction des adresses réseau et des adresses de port peut vous tirer d’affaire, vous risquez de tomber de Charybde en Scylla.
Les hôtes Internet doivent être référencés par leur nom de domaine complet (ou FQDN, Fully Qualified Domain Name), composé du nom de l’hôte et du nom du domaine associé, par exemple whatis.techtarget.com.
Le nom d’hôte www est courant pour les serveurs Web, mais pour savoir dans quel domaine se trouve le serveur, nous avons besoin du FQDN. Si une URL ne contient pas de nom de domaine, le client part de l’hypothèse que la cible se trouve sur le réseau local, alors que ce n’est probablement pas le cas.
Lorsque les utilisateurs saisissent une URL distante dans leur navigateur, par exemple www.foo.com, plusieurs choses se produisent.
D’abord, le cache du système de résolution DNS est consulté. Cette fonction relève généralement du système d’exploitation, mais certaines applications clientes, notamment certains navigateurs mobiles, ont des procédures propres.
Ensuite, le fichier de l’hôte est consulté. Ce simple fichier texte, qui figure généralement dans le répertoire /etc, définit les correspondances entre adresses IP et noms d’hôte. Si le client ne trouve aucune correspondance dans le cache ni dans le fichier de l’hôte, il va chercher sa réponse ailleurs.
Pour que le client puisse envoyer une demande, sa configuration doit inclure au moins un serveur DNS. Dans les environnements d’entreprise, il s’agit d’un serveur local, alors que pour les connexions Internet mobiles ou aux particuliers, ce sont les FAI qui fournissent ce service.
Avancer à rebours pour trouver la bonne adresse
A l’inverse des adresses IP qui vont du général au particulier en partant de la gauche, les noms de domaine se lisent de droite à gauche. Le système DNS remonte du domaine de premier niveau vers le parent, puis vers les éventuels domaines enfants jusqu’à trouver l’adresse IP de l’hôte.
Si le serveur DNS ne trouve aucune correspondance en cache, la demande est transférée vers un des nombreux serveurs proxy de cache possibles.
En bout de course, la demande peut arriver jusqu’aux serveurs DNS racines mondiaux (« . ») qui, à leur tour, pointent vers les serveurs de domaines de premier niveau. Ces derniers contrôlent les grands domaines tels que .com, .org et .fr. Eux-mêmes pointent ensuite vers les domaines enfants (dans notre exemple, foo.com).
L’illustration ci-dessous montre l’itinéraire d’une demande depuis un client jusqu’à l’adresse, en passant par les serveurs racines et par les domaines de premier niveau et parents.
Seules les réponses reçues des serveurs DNS configurés sont pertinentes, car le client n’a aucun lien avec les autres serveurs. Et pour écarter l’hypothèse d’un problème côté serveur, rien de plus simple vu le grand nombre de serveurs publics : il suffit d’en changer !
Finalement (généralement en moins d’une seconde), le client reçoit du serveur DNS l’une des nombreuses réponses trouvées.
Si cette réponse inclut une adresse IP, le client ouvre alors un socket TCP vers cette destination. Mais c’est rarement aussi simple. Dans un monde de réseaux de distribution de contenu et de sites Web affiliés, une simple URL mène très peu souvent à une seule adresse IP en réponse.
