Institut Galilée L2 Info – S4 — Année 2017–2018

Administration Système
TP03 : Résolution de noms
Le but de ce TP est d’apprendre aux machines à se connaı̂tre par le nom plutôt que simplement par
leurs adresses IP. C’est-à-dire qu’on veut pouvoir faire ping m1 au lieu de devoir systématiquement faire
ping [Link]. Ceci est très utile car les noms de machines ont une logique “humaine” et sont donc
plus facile à retenir que les adresses IP.

1 Un Réseau simple
1.1 Mise en place initiale
Ouvrir un nouveau projet. Mettre deux ordinateurs et les connecter à l’aide d’un câble. Démarrer les
ordinateurs. Modifier les fichiers /etc/network/interfaces (cf TP02, partie 4) de manière à assigner
une adresse IP statique à chaque machine (prendre un netmask à [Link] pour toutes les machines
du TP). Activer les interfaces à l’aide de ifup. Vérifier que le réseau fonctionne à l’aide de ping.

1.2 Configuration logicielle

Tout d’abord, nous allons configurer statiquement les liens entre les noms de machines et leur adresse
IP.
Ces liens sont stockés dans le fichier /etc/hosts. Regarder la manuel de hosts. Le premier para-
graphe, ainsi que la ligne d’exemple qui suit immédiatement, explique le contenu du fichier. Chaque ligne
contient simplement une adresse IP suivie du nom de la machine correspondante.
Éditer le fichier /etc/hosts. Il contient déjà plusieurs lignes reliant des adresses IP à des noms.
En particulier, la dernière ligne doit faire le lien entre l’adresse de loopback ([Link]) et la machine
courante. Comme tout ce qui concerne lo, il ne faut jamais la modifier.
Rajouter une ligne au fichier pour indiquer l’adresse de la deuxième machine. Répéter l’opération sur
la deuxième machine. Vérifier en utilisant ping sur le nom des machines (et pas sur les adresses IP) que
ça fonctionne.
Ce système fonctionne comme un carnet d’adresses : chaque machine conserve la liste d’adresses de
toutes les autres machines. Le problème, c’est que si une machine change d’adresse, il faut répercuter ce
changement dans tous les carnets d’adresses. Ce qui peut être long et pénible dans le cas de gros réseaux
comme celui de la fac avec des centaines de machines. . .

2 DNS direct
Le DNS (Domain Name System) direct permet de transformer automatiquement un nom de machine
en adresse IP. Ce système fonctionne plutôt comme un annuaire (en ligne). Seul l’annuaire (le serveur
DNS) connaı̂t les adresses de tout le monde. Les autres machines (clients DNS) ne connaissent que
l’adresse de l’annuaire. Quand on a besoin de connaı̂tre l’adresse de quelqu’un d’autre, on consulte
l’annuaire, ce qui est un peu plus long que de consulter son carnet d’adresses, mais permet de découvrir
des nouvelles adresses. Quand quelqu’un déménage, il suffit de changer son adresse dans l’annuaire et on
n’a pas besoin de modifier tous les carnets d’adresses individuels.
Nous allons mettre en place un système avec 3 machines qui cette fois ci ne seront plus similaires.
L’une d’elles servira de serveur DNS et fournira aux autres, appelées clients DNS le service de résolution
des noms.
Nous n’aborderons pas le DNS inversé qui permet de transformer les adresses IP en nom de machine.
Attention ! La structure du DNS pour un petit réseau local comme nous allons le faire est nécessairement
la même que celle qui soutient tout Internet et permet, en permanence, de connaı̂tre l’adresse de tous
les ordinateurs au monde ! Il s’agit donc, comme on peut l’imaginer, de quelque chose de relativement
complexe et il convient de bien faire attention aux différentes étapes du processus.

1
 2.1 Mise en place matérielle
Ouvrir un nouveau projet. Y mettre 3 machines. Une sera appelée
serveur, les deux autres m1 et m2 (par exemple). Rajouter un hub.
Connecter les machines au hub.
Tout démarrer.

2.2 Adresses et nom de domaine

Modifier les fichiers /etc/network/interfaces pour assigner à chaque
machine une adresse IP statique. Afin de conserver ici la dissymétrie du
réseau, le serveur aura l’adresse [Link] et les machines [Link] et
[Link] Mettre les netmask à [Link]
Activer les cartes réseaux (à l’aide de ifup) et vérifier à l’aide de ping que le réseau fonctionne.
Il faut maintenant choisir un nom de domaine pour l’ensemble du réseau. Le nom de domaine est
ce qui est rajouté après le nom de la machine pour obtenir le “nom internet” complet. Par exemple,
la machine dont le nom est www (nom traditionnel des serveurs web. . . ) et dont le nom de domaine est
[Link] a pour nom internet complet [Link]. De même, la machine dont le nom est www et
le nom de domaine est [Link] a pour nom internet complet [Link] Bien que
ces deux machines aient le même nom (www), elles n’appartiennent pas au même domaine et il s’agit donc
bien de deux machines différentes.
Il faut donc un nom de domaine pour le réseau que nous sommes en train de construire. Par exemple,
[Link].
Le nom de domaine de chaque machine est indiqué dans le fichier /etc/[Link], ainsi que
l’adresse du serveur DNS. Ça tombe bien, il nous faut modifier ces deux informations !
Regarder le manuel de [Link] Après les deux premiers paragraphes, le manuel décrit un certain
nombre d’options de configurations. La première est nameserver, suivi d’une adresse IP, qui correspond
au serveur de nom, c’est-à-dire au serveur DNS. La deuxième option est domain suivi du nom du domaine
local. Seules ces deux options nous intéressent pour l’instant.
Éditer le fichier [Link] Ajouter deux lignes, une pour chacune des options vue précédemment,
indiquant le nom de domaine ([Link]) et l’adresse IP du serveur DNS ([Link]). Répéter cette
opération pour chacune des trois machines.

2.3 Serveur DNS : créer un nouveau domaine

Il faut maintenant indiquer au serveur DNS qu’il a un nouveau domaine à gérer et lui expliquer
comment le gérer. Le nom du programme qui gère le serveur DNS est bind (ou named, son ancien nom).
Les fichiers de configuration le concernant sont donc dans le répertoire /etc/bind/
Aller dans le répertoire /etc/bind/ En regarder le contenu. Les fichiers db.* permettent de gérer les
domaines correspondants (db est l’abréviation de DataBase, base de données). Les fichiers [Link].*
sont des fichiers de configuration de named (i.e. bind) et les deux autres fichiers ne nous intéressent pas.
Le principal fichier de configuration, qui contrôle et utilise les autres, est le fichier [Link] Re-
garder sans le modifier son contenu (par exemple avec less ou more). Les lignes commençant par //
sont des commentaires (comme en C). La première ligne “utile” commence par include : il s’agit tout
simplement d’aller lire le fichier correspondant. Viennent ensuite une série de blocs “zone”. À chaque
zone correspond (entre accolades), un type et un fichier de configuration. Enfin, la dernière ligne du fichier
inclut le fichier [Link] C’est ce fichier qui doit contenir toutes les modifications locales du
serveur DNS.
Sur le serveur, éditer le fichier [Link] (on pourra, en parallèle, visualiser sur une autre
machine le fichier [Link] afin de s’en inspirer. . . ) Il faut rajouter un bloc “zone” pour le nouveau
domaine.
En s’inspirant 1 des blocs “zone” du fichier [Link], rajouter un bloc dans [Link]
sur le serveur (uniquement). Le nom de la zone correspond au nom du domaine à gérer ([Link]). Le type
de la zone doit être master car le serveur est le “maı̂tre” de ce domaine et connaı̂t toutes les informations
1. Faire attention notamment aux guillemets, accolades, points-virgules.

2
le concernant. Le nom du fichier de configuration pour la zone est libre, mais autant prendre quelque
chose qui respecte les noms précédents, par exemple /etc/bind/[Link]
Remarque : dans le fichier [Link], les zones dont le nom finit par [Link] et commence
par un chiffre correspondent au DNS inversé (retrouver le nom d’une machine à partir d’une adresse
IP). Pour mettre en place un DNS inversé sur notre domaine, il aurait fallu créer une telle zone dans
[Link]. Le suffixe .arpa fait référence au nom du précurseur d’Internet : Arpanet.

2.4 Serveur DNS : gérer le nouveau domaine

Remarque : pour une description complète du contenu des fichiers de zone, on pourra consulter le ma-
nuel détaillé à l’adresse [Link]
Il nous faut donc maintenant créer le fichier /etc/bind/[Link] pour expliciter la gestion du
domaine. Pour ne pas partir de zéro, nous allons nous inspirer d’un des fichiers db.* existant.
Sur le serveur, faire une copie du fichier [Link], appelée [Link]
Éditer le fichier /etc/bind/[Link]
Dans ce fichier, le symbole de commentaire est le point-virgule (ça aurait été trop simple de conserver
le même partout. . . ) Tout ce qui se trouve dans une ligne après un ; est un commentaire et est ignoré.
Le fichier contient ensuite quatre “phrases” (la première s’étend sur plusieurs lignes) commençant par @
(la ligne commençant par TTL est sans importance pour nous).
Chaque phrase comporte plusieurs “champs” 2 (rangés en colonnes). Le premier champ indique le
nom de la machine concerné par la phrase (@ est un joker pour signifier “moi-même”). Le deuxième
champ indique à quelle famille 3 d’adresses la phrase correspond. En pratique, seule la famille IN (pour
InterNet) nous intéresse, elle correspond à la famille inet du fichier /etc/network/interfaces. Le
troisième champ indique un type de phrase. Trois types sont présent dans le fichier et ce sont les trois
seuls qui nous intéressent ici.

2.4.1 Start of Authority

Commençons par la phrase de type SOA. Il s’agit des initiales de “Start Of Authority”. Il faut une
et une seule phrase de type SOA par zone et ce doit être la première phrase rencontrée. La première
ligne de cette phrase contient deux informations que nous allons modifier. Les lignes suivantes sont des
valeurs (de temps de latence, . . . ) dont la signification est résumée à la fin de chaque ligne et que nous
ne toucherons pas (les valeurs par défaut sont correctes).
Sur la première ligne, après le SOA, il y a deux noms séparés par un espace. Le premier est le nom
de la machine qui fait serveur DNS. Il faut donc remplacer localhost par le nom complet du serveur,
c’est-à-dire [Link] Attention à conserver le point à la fin du nom de la machine !
Le deuxième nom correspond à une adresse mail dont le @ a été remplacé par un point. On indique ici
à qui doivent être envoyé les rapports d’erreur du serveur (root@localhost, devenu [Link]).
On peut encore envoyer les rapport à root et mettre comme adresse [Link] Attention
encore à laisser le point à la fin.

2.4.2 Adresses
Maintenant, nous pouvons modifier les phrases de type A et NS. Les phrases de type A sont les plus
simples, elles indiquent tout simplement à quelle adresse IP correspond une machine donnée (à l’intérieur
du domaine).
La phrase de type A qu’on trouve dans le fichier indique ainsi que la machine “@” (rappel : c’est un
joker pour désigner la machine sur laquelle se trouve le fichier) a pour adresse IP [Link] (rappel : il
s’agit toujours de l’adresse de “loopback” qui revient sur la machine elle-même).
Cette phrase est à supprimer, mais on peut la conserver un temps pour s’en inspirer pour rédiger les
remplaçantes.
Pour chacun des deux clients, il faut rajouter une phrase de type A. Cette phrase doit contenir 4
champs : le nom de la machine (sans le nom de domaine, on sait qu’on est ici en train de gérer le
domaine), la classe IN d’adresse, le type A de la phrase et l’adresse IP de la machine.
2. Le manuel les appelle “RR” pour Resource Record (enregistrement de ressources).
3. Le manuel les appelle classes.

3
 Par exemple :
m1 IN A [Link]
Rajouter les 2 lignes nécessaires pour gérer les 2 clients. Rajouter aussi une ligne complète pour le
serveur (de manière à ce qu’il connaisse son nom sans passer par le joker) :
serveur IN A [Link]
Supprimer, si ce n’est pas déjà fait, la phrase de type A qui était présente initialement dans le fichier.
Supprimer aussi la phrase de type AAAA.
La phrase de type NS indique. . . le serveur de noms 4 . Il suffit donc de remplacer le localhost par
le nom complet du serveur : [Link] Attention à bien conserver le point à la fin du nom du
serveur.

2.5 Et ça démarre !

Comme beaucoup de services, DNS est géré par un démon : un petit programme qui tourne en arrière
plan et attend les requêtes. Pour démarrer le serveur DNS, il faut donc démarrer le démon bind9 5 . Les
fichiers de lancement de démons se trouvent dans /etc/init.d/ (initialisation des démons). Ici, il doit
être appelé avec l’argument start (ou restart si le démon est déjà lancé) :
/etc/init.d/bind9 start
Un message s’affiche pour indiquer que le démon se lance. Une fois fini, essayer depuis le serveur de
faire un ping sur m1 en utilisant directement le nom de machine (pas l’adresse IP). Essayer de même
de faire un ping de m1 vers m2. Pas besoin de redémarrer les machines puisque le fichier [Link]
contient le nécessaire.
Remarque : le mécanisme pour assurer le lancement automatique de bind est légèrement hors des
bornes de ce TP. Aussi, nous nous contenterons pour l’instant de lancer manuellement le script (avec la
commande indiquée ci-dessus) à chaque démarrage du serveur.

3 Sous-réseau et DNS secondaire

Arrêter toutes les machines. Rajouter 3 nouvelles machines au projet, de noms serveurbis, n1 et n2.
Rajouter un deuxième hub et connecter les trois nouvelles machines dessus (ne pas connecter les hubs
entre eux pour l’instant !)
Démarrer toutes les machines. Configurer les 3 nouvelles machines avec les adresses [Link],
[Link] et [Link] (penser à prendre le netmask [Link]). Placer toutes les nouvelles machines
dans le domaine [Link] et configurer un serveur DNS sur serveurbis pour gérer ce domaine.
Démarrer le serveur DNS et vérifier qu’il fonctionne correctement (à l’aide de ping).
Arrêter toutes les machines. Rajouter un câble entre les deux hub. Redémarrer toutes les machines.
Se connecter sur les serveurs et lancer les démons bind.

3.1 Sous-réseau
Depuis m1, vérifier à l’aide d’un ping directement sur l’adresse IP [Link] que les deux sous réseaux
sont bien connectés (Y a-t-il le bon type de câble entre les hubs ?)
Attention si ça ne marche pas, il est possible que ça vienne d’un netmask trop restrictif. Vérifier qu’ils
sont bien tous fixés à [Link]
Vérifier que depuis m1, il est impossible de pinger n1 par son nom. En effet, le serveur DNS de m1
est serveur qui ne connaı̂t pas les machines du domaine [Link]

3.2 Relais DNS

Pour résoudre ce problème, on pourrait recréer, sur serveur, une zone DNS pour gérer le domaine
[Link] (avec le fichier de zone correspondant). Cette solution n’est guère praticable car elle obligerait
à multiplier les information du DNS et ne serait, au final, guère plus efficace que de mettre les adresses
4. Non, on ne se mord pas complètement la queue, cette phrase est utile dans le cas où il y a des serveurs secondaires
qui relaient l’information mais ont besoin de connaı̂tre le serveur principal.
5. 9 est le numéro de version.

4
“en dur” dans le fichier hosts (en particulier quand les adresses IP changent et que la base de donnée
DNS doit alors être mise à jour. . . sur tous les serveurs. . . )
À la place, on va indiquer à serveur que toute requête DNS pour une machine du domaine [Link]
doit être retransmise à serveurbis
Éditer le fichier /etc/bind/[Link] de serveur Rajouter à la fin une nouvelle zone
pour le domaine [Link] Pour cette zone là, serveur n’est pas le maı̂tre, il se contentera de retrans-
mettre les requête à un autre serveur. La zone doit donc être de type forward (et non master comme
précédemment).
Comme la zone est juste une retransmission, il faut maintenant donner l’adresse du serveur à qui on
retransmet les requêtes. Elle est introduite par le mot clé forwarders (attention au pluriel). Comme il
peut y avoir plusieurs serveurs à qui on retransmet les requêtes, leurs adresses (même si ici il n’y en a
qu’une), sont données entre accolades et non entre guillemets, avec un point-virgule après chaque adresse.
Rajouter l’adresse de serveurbis comme redirection.
La nouvelle zone doit maintenant contenir les information suivantes :
— Une déclaration de zone, avec le nom du domaine entre guillemets (comme pour la zone [Link]),
puis une accolade ouvrante pour marquer le début des paramètres de la zone.
— Un type pour la zone, ici forward, terminé par un point-virgule pour marquer la fin du paramètre
type
— Une liste (réduite à un élément) d’adresses de redirection. La liste doit être entre accolades, chaque
adresse suivie d’un point-virgule, et la liste est introduite parle mot clé forwarders et terminée
par un point-virgule (après l’accolade fermante de fin de liste).
— Une accolade fermante pour finir les paramètres, suivie d’un point-virgule (comme pour la zone
[Link]).
Une fois ces modifications effectuées, il faut recharger les paramètres de bind en lançant la commande
/etc/init.d/bind9 reload
Après, on devrait pouvoir, depuis serveur, m1 ou m2, faire un ping sur une des machines de l’autre
sous-réseau en utilisant le nom et pas seulement l’adresse IP.
En utilisant le nom complet, bien sûr, puisque la machine n’est pas dans le même sous-réseau (on fait
un ping sur [Link], car l’ordinateur ne peut pas deviner tout seul si on faisait ping www vers
quel serveur web doit se diriger le ping ([Link] ou [Link] ?))

3.3 Zone de recherche

On peut vouloir autoriser les machines des deux sous-réseaux à se parler en s’appelant par leur petit
nom, sans avoir besoin d’utiliser leur nom complet. Pour cela, il faut rajouter dans le fichier [Link]
une directive indiquant les domaines dans lesquels on doit chercher à compléter le nom de machine en
un nom complet (par défaut, le domaine dans lequel se trouve la machine est toujours pris en compte).
Sur m1, rajouter dans le fichier /etc/[Link] une ligne :
search [Link]
La machine cherche maintenant à compléter les noms non seulement dans le domaine [Link] (son
domaine propre) mais aussi dans [Link] Essayer de faire, toujours depuis m1, un ping n2.

4 Ce qu’il faut retenir

Vous devez connaı̂tre
— les fichier /etc/hosts et /etc/[Link] ;
— le concept de DNS et l’asymétrie serveur/client.
Vous devez connaı̂tre l’existence :
— des fichiers de zones (/etc/bind/[Link]) en ayant une idée globale de leur contenu ;
— du répertoire /etc/init.d et de la manière de (re)lancer des services avec les programmes qui
s’y trouvent.