Notions de base

Donc, notre fournisseur d'accès nous propose une ou plusieurs adresses de serveurs DNS récursifs, et notre système va les récupérer lors de sa configuration IP. Pour connaitre ces adresses, il faut savoir retrouver sa configuration. La façon de faire varie suivant le système d'exploitation utilisé.

Le clicodrome Windows propose quelques chemins plus ou moins détournés. Le plus simple étant sans doute d'utiliser la commande nslookup dans une invite de commandes :

C:\Documents and Settings\chris>nslookup
Serveur par défaut :  dns1.proxad.net
Address:  212.27.40.240

Nous sommes ici dans le cas d'une machine sous MS Windows, connectée à une FreeBox en mode pont ethernet (nous n'exploitons pas les fonctions de routage). Il est également possible de récupérer l'information avec la commande :

C:\Documents and Settings\chris>ipconfig /all

Configuration IP de Windows
        ...
Carte Ethernet Connexion au réseau local:
        ...
        Serveurs DNS . . . . . . . . . .  : 212.27.40.240
                                            212.27.40.241

Pour les distributions Debian GNU/Linux et dérivées, l'information se trouve généralement dans le fichier /etc/resolv.conf :

# cat /etc/resolv.conf
nameserver 212.27.40.240
nameserver 212.27.40.241

Windows XP propose la commande nslookup, qui permet d'effectuer une résolution manuellement. Exemple :

C:\Documents and Settings\caleca>nslookup irp.nain-t.net
Serveur par défaut :  dns1.proxad.net
Address:  212.27.40.240

Réponse ne faisant pas autorité :
Nom :    irp.nain-t.net
Address:  213.186.40.149

Ça fonctionne, et le Réponse ne faisant pas autorité est à se mettre sous le coude, nous comprendrons plus tard ce que cela veut dire.

Dans les systèmes GNU/Linux, la commande nslookup n'est plus maintenue. Les outils à retenir sont host et dig.

# host irp.nain-t.net
irp.nain-t.net has address 213.186.40.149

Quel que soit le service que nous utilisons sur un réseau, navigateur web, client de messagerie, IRC, dès lors que nous identifions le serveur interrogé par son nom, le système devra effectuer une résolution de ce nom, de manière à trouver l'adresse IP correspondante, et exploitera les services du serveur DNS, comme nous l'avons fait avec nslookup ou host.

Prenons un exemple un peu compliqué, comme www.education.gouv.fr ; en toute rigueur, il serait plus correct d'écrire www.education.gouv.fr. (avec un point final, subtile différence).

• la partie la plus à gauche représente toujours un hôte ;
• la partie la plus à droite représente toujours un domaine générique (TLD) ;
• entre les deux, les éventuels sous-domaines et le domaine déposé de l'entité concernée.

Ainsi, un serveur (un hôte), ici www appartiendrait à un sous-domaine (education) du domaine gouv, lui-même étant un élément du domaine générique fr (la réalité n'est hélas pas si simple, comme l'avenir va le montrer). Notons qu'il serait plus judicieux de parler d'un nœud ; en effet, un hôte peut disposer de plusieurs interfaces réseau et donc disposer de plusieurs adresses IP.

Nous avons donc une structure arborescente dont l'origine est le fameux point final, que l'on omet généralement, mais qui existe bel et bien et qui représente la racine de l'arbre. Nous pouvons d'ailleurs utiliser la commande host comme ceci :

$ host www.education.gouv.fr.
www.education.gouv.fr is an alias for front.webedu.men.aw.atosorigin.com.
front.webedu.men.aw.atosorigin.com has address 160.92.130.142

Tiens, voilà autre chose…

www.education.gouv.fr ne serait pas un « vrai nom », mais simplement un synonyme de front.webedu.men.aw.atosorigin.com ? Encore une remarque à se mettre sous le coude. En effet, DNS prévoit qu'un hôte (un nœud) puisse s'appeler de diverses manières, parfois très différentes comme c'est le cas ici. L'éclaircissement viendra sans doute dans la suite de ce chapitre.

Dans la suite de ce chapitre, nous allons voir d'un peu plus près comment un serveur DNS est structuré et comment l'architecture arborescente d'un FQDN est en fait l'image d'une arborescence de serveurs DNS spécialisés.

A priori, un serveur DNS récursif n'a par lui-même aucune réponse, du moins aucune réponse « qui fait autorité ». en revanche il sait exactement rechercher qui et dans quel ordre il faut interroger pour obtenir une réponse « qui fait autorité ». Comme en informatique, la paresse et la mémoire sont deux qualités fondamentales, notre serveur DNS récursif va conserver dans sa mémoire pendant « un certain temps » les résultats de recherche qu'il a obtenus et s'en servira en priorité, pour avoir moins de travail. Nous étudierons tout ceci plus loin, mais cette fonctionnalité explique déjà la réponse « ne faisant pas autorité » vue plus haut. En effet, lorsqu'un serveur DNS sert une réponse issue de son cache, il signale de cette manière qu'elle ne vient pas d'un serveur de référence.