Ce document a été fait par Aurore Stevenin et Guillaume Fausten, étudiants en DESS CRI à l'UFR de REIMS (année universitaire 98/99).


Installation des ervices NFS et DNS dans un réseau Linux.

Résumé.


Le projet du module d'Administration Réseau a consisté à mettre en place un réseau de machines Linux, Unix et Windows, ainsi que divers services et protocoles.

Dans ce document, nous présentons la mise en place des services NFS et DNS. D'une part, nous présentons les bases de ces deux protocoles. D'autre part, nous listons les réglages nécessaires au bon fonctionnement de notre réseau.

Mots-clés : NFS, DNS, Administration Réseau.


Table des matières.
  1. Installation de NFS.
    1. L'objectif de NFS.
    2. Le cadre de travail.
      1. Notre réseau.
      2. Avant toute chose.
    3. Installation du serveur NFS.
      1. Le portmap.
      2. Le fichier /etc/exports.
      3. Le serveur est prêt.
    4. Installation d'un client NFS.
      1. Le fichier /etc/fstab.
      2. Les fichiers /etc/fstab dans notre réseau.
    5. Les commande utiles.
      1. showmount.
      2. mount.
      3. umount.
  2. L'installation du DNS.
    1. Introduction.
      1. L'espace du nom de domaine.
      2. Les serveurs de noms.
      3. Les Résolveurs.
    2. La configuration de la librairie du résolveur.
      1. Le fichier /etc/host.conf.
      2. Le contenu de notre fichier /etc/host.conf.
      3. Le fichier /etc/resolv.conf.
      4. Le contenu du fichier /etc/resolv.conf.
    3. Le démon Named.
      1. Le fichier /etc/named.boot.
      2. Le contenu de notre fichier /etc/named.boot.
      3. Les fichiers de bases de données et les enregistrements de ressources.
      4. Le fichier named.hosts.
      5. Le fichier named.rev.
      6. Le fichier named.ca.
    4. Comment éviter les problèmes?
    5. Conclusion.


    Table des figures.

    1. La topologie de notre réseau.
    2. La hiérarchie de DNS.


    1. Installation de NFS.


      1. L'objectif de NFS.


        2. Les réseaux informatiques actuels sont souvent constitués de machines et surtout de systèmes d'exploitation hétérogènes, qu'il s'agisse de Windows 95/98, Windows NT, MacOS, UNIX, ou encore Linux.

        Pour autant, les utilisateurs veulent pouvoir mettre en place un partage de données entre toutes leurs machines.

        C'est pour ce faire qu'a été mis au point le système de fichier \textbf{NFS} : une machine peut partager de façon transparente, n'importe quel répertoire de sa propre arborescence, autorisant ainsi toute autre machine a travailler sur ce répertoire via le réseau, comme si ce répertoire se trouvait sur son propre disque dur.

        C'est Sun qui a commencé le developpement de NFS au début des années 80.

        Le but de ce document est de présenter pas à pas les étapes pour la mise en place de serveurs et de clients NFS.

      2. Le cadre de travail.


        1. Notre réseau.


          2. Nous allons tout d'abord vous présenter la topologie du réseau que nous avons mis en place :



          La topologie de notre réseau.

          Ce réseau est consitué de trois PC avec Linux comme système d'exploitation, et d'une station HP sous Unix. Ces quatre postes sont reliés par un bus Ethernet.

          Concernant les PC, nous avons installé une distribution RedHat 5.1 de Linux. Pour la station HP, il s'agit de hpux.

          Dans ce document, nous allons d'une part, expliquer les divers réglages possibles de NFS, tout en exposant les réglages nécessaires et suffisants pour notre réseau.

          Les réglages que nous présentons ne sont valables que pour notre réseau, mais peuvent être étendus à d'autres topologies, sous réserve de quelques modifications.

          Pour l'installation des postes, nous avons fixé des adresses IP pour chacun des postes, et ce de façon arbitraire. Notre réseau étant indépendant, nous ne risquions pas d'obtenir des conflits d'adresses IP. Dans le cas où le réseau est relié à d'autres réseaux, voire à Internet, il faut obtenir des adresses IP valides.

        2. Avant toute chose


          3. La première chose à faire, avant de passer à tout autre réglages, c'est de s'assurer du bon fonctionnement du réseau.

          Pour cela, nous utilisons la commande ping.

          Par exemple, sur le pc1, la commande ping 193.50.208.4, permet de s'assurer que le poste pc4 est bien reconnu sur le réseau.

          Si la commande ping ne fonctionne pas, plusieurs explications sont possibles :
          • le poste initiateur de la commande \texttt{ping} ne peut pas atteindre le réseau (la carte est défaillante, ou n'est pas reconnue par le système d'exploitation)
          • le poste que l'on souhaite contacté n'est pas actif (mêmes raisons que ci-dessus)
          • les adresses IP n'ont pas été bien fixées...

          La mise en place du réseau sort de notre sujet, et nous estimerons maintenant que le réseau est pleinement opérationnel.

      3. Installation du serveur NFS.


        1. Le portmap.


          2. Avant toute chose, le HOWTO de Linux conseille de vérifier que le portmap est correctement lancé au démarrage des machines serveurs.

          Pour lancer manuellement le portmap, vous devez d'abord localiser le programme inet, et lui passer le paramètre start.

          Sous Linux, la commande est alors la suivante :
          /etc/rc.d/init.d/inet start

        2. Le fichier /etc/exports.


          3. Un poste est considéré comme serveur NFS s'il partage une partie de son arboresence avec les autres machines du réseau. Nous allons voir comment un poste peut partager (exporter) un répertoire.

          Editez le fichier /etc/exports. C'est ce fichier qui contient la liste des répertoires partageables.

          Ce fichier contient des lignes, chacune d'elle correspondant à la syntaxe :
          /chemin options

          Le premier champ représente le chemin du répertoire de la machine serveur que vous souhaitez partager. Les options permettent de définir les droits de lecture/écriture sur le répertoire.

          Le format des options diffèrent entre Linux et hpux.

           Les options répondent au format:

          host(option1[,option2...])

          host désigne la machine à laquelle s'applique les options.

          rw les droits de lecture/écriture sont donnés

          root_squash si l'utilisateur courant de \texttt{host} est le \texttt{root}, sa demande de montage sera refusée

          no_root_squash contraire de root_squash, autorisant les clients root

          link_relative les liens symboliques seront interprétés par le client

          Lors des réglages, le fichier /etc/exports sera souvent modifié. Il n'est pas nécessaire de rebooter la machine après chaque modification. Il suffit de faire appel à la commande exportfs.

          Ce script est en général dans /usr/sbin. Si votre machine ne dispose pas de ce script, installez ce script :
          killall -HUP /usr/sbin/rpc.mountd
          killall -HUP /usr/sbin/rpc.nfsd
          echo "Système de fichier ré-exporté"

        3. Le serveur est prêt


          4. Avant de décrire la démarche pour le client NFS, il faut s'assurer que le serveur est opérationnel. Pour celà, nous allons vérifier que nfsd et mountd sont bien lancés.

          La commande rpcinfo -p permet de s'assurer du bon fonctionnement des démons (voir le HOWTO...).

          Dans le réseau que nous avons utilisé, le poste pc1 est le serveur NFS. Voici son fichier /etc/exports :

          /home/pc2 pc2(rw,no_root_squash,link_relative)
          /home/pc4 pc4(rw,no_root_squash,link_relative)
          /home/hp hp(rw,no_root_squash,link_relative)
          /pub (rw,no_root_squash,link_relative)

          Les trois premières lignes exportent les répertoires de chaque utilisateur, en autorisant uniquement leur "propriétaire" à y accéder.

          La dernière ligne partage le répertoire /pub, autorisant l'accès à toutes les machines du réseau.

          Remarque : pour exploiter votre réseau, il faudra par la suite que le serveur soit démarré en premier (avant les clients).

      4. Installation d'un client NFS.


        5. Maintenant que le serveur NFS a déclaré les répertoires qu'il met à disposition des autres machines du réseau, il faut paramétrer ces dernières afin de "monter" les répertoires partagés.

        1. Le fichier /etc/fstab.


          2. C'est dans le fichier /etc/fstab que Linux examine, afin de connaître les points de montage. Ces points de montage sont par exemple le CD-Rom, les disques durs, mais également, les volumes NFS.

          Pour qu'une machine devienne client NFS, il faut donc modifier ce fichier /etc/fstab.

          Dans notre réseau, nous voulons par exemple que le pc2 monte le répertoire que le serveur pc1 met à sa disposition.

          Pour celà, nous ajoutons la ligne suivante à /etc/fstab :
          pc1:/home/pc2 /far_home nfs exec,rw,bg,suid,dev,soft

          Le premier champ de la ligne indique la source pour le point de montage. Ici, il s'agit du répertoire /home/pc2, situé sur la machine pc1.

          Le deuxième champ représente le point de montage lui-même, c'est-à-dire le chemin sous lequel sera monté le répertoire distant. Pour simuler un environnement client-serveur sur notre réseau, nous avons modifier les fichiers .bash_profile de chaque machine de la façon suivante :

          ...
          HOME=/far_home
          cd ~
          cat welcome.txt
          ...

          De cette façon, dès qu'un utilisateur se connecte sur pc2 par exemple, le répertoire distant est automatique monté, et son répertoire HOME devient ce même répertoire distant.

          Le troisième champ indique le type du répertoire à monter. Ici, il s'agit bien sûr d'un répertoire NFS.

           Le dernier champ contient les options concernant le point de montage. Nous détaillons ci-dessous les options possibles (voir man nfs) :

          rsize représente la taile en octets des paquets lus sur le serveur NFS

          wsize est la taille en octets des paquets écrits sur le serveur NFS

          timeo est le délai de retransmission des paquets RPC

          retry est le nombre de tentatives maximum pour un montage en arrière plan

          bg force le montage en arrière-plan, si le premier montage n'a pas été réussi

          soft précise qu'en cas d'erreur, le programme appelant reçoit un message d'erreur

          hard une erreur provoque un message "server not responding" et ressaye à l'infini la commande

          intr comme l'option hard, mais peut être interrompue

        2. Les fichiers /etc/fstab dans notre réseau.


          3. Pour notre réseau, voici les lignes que nous avons ajouté dans les fichiers fstab des différents postes :


          • Sur le poste pc2 :

            • pc1:/home/pc2 /far_home nfs exec,rw,bg,suid,dev,soft
            pc1:/home/pub /pub nfs exec,rw,bg,suid,dev,soft

          • Sur le poste pc4 :

            • pc1:/home/pc4 /far_home nfs exec,rw,bg,suid,dev,soft
            pc1:/home/pub /pub nfs exec,rw,bg,suid,dev,soft

          • Sur le poste hp :

            • pc1:/home/hp /far_home nfs exec,rw,bg,suid,dev,soft
            pc1:/home/pub /pub nfs exec,rw,bg,suid,dev,soft


      5. Les commandes utiles.


        6. Cette section présente les différentes fonctions dont vous pouvez avoir besoin lors de l'installation et de vos expérimentations. Pensez tout de même à consulter les manuels de votre distribution.

        1. showmount.


          2. Sur le serveur NFS, cette commande permet d'obtenir des informations sur les répertoires exportés.

          Si vous ne lui passez aucune option, la commande showmount affiche la liste des machines ayant monté des répertoires à partir de votre machine.

          L'option -a affiche les couples machines/répertoires montés.

          L'option -d affiche la liste des répertoires exportés qui ont été montés (sans se préoccuper par quelles machines).

          L'option -e affiche la liste des répertoires exportés, sans se soucier du montage.

        2. mount.


          3. Si vous désirez effectuer un montage manuel, vous utiliserez la commande mount.

        3. umount.


          4. Pour "démonter" un point de montage, vous devez utiliser la commande umount. Par exemple, si le poste pc4 ne souhaite plus utiliser le répertoire /pub, il peut le démonter grâce à la commande :

          umount /pub

          Tout simplement !

          Il existe bien sûr des options à la commande umount, comme vous le verrez dans le manuel.

    2. L'installation du DNS.


      1. Introduction.


        2. DNS est un système de service de noms. Un service de noms, permet à une application ou à un utilisateur de trouver, en donnant un nom, des informations associées à ce nom. Par exemple, c'est grâce à un tel annuaire qu'un utilisateur, souhaitant se connecter à une machine peut taper son nom au lieu de son adresse. La traduction de nom en adresse est faite par le DNS.

        DNS procure donc un mécanisme de conversion d'adresses IP en noms mnémoniques qui représentent les hôtes, les réseaux... Il fait ceci en divisant Internet en différents groupes logiques. Chacun de ces groupes a autorité sur ses propres ordinateurs et autres informations.

        Un nom identifie un objet (ordinateur, réseau, personne, service...) et est censé être indépendant de la localisation physique de l'objet. Une adresse par contre, indique une localisation géographique. Elle n'identifie pas un objet, et bien qu'utilisée en interne par le logiciel, ne devrait pas avoir à être connue des utilisateurs. Les noms portent souvent des informations de localisation plus ou moins précises et les adresses nécessitent parfois un long processus de résolution.

        Comme DNS est un sujet compliqué, il possède son propre ensemble de termes spécialisés. C'est pourquoi, nous allons donner une définition pour chacun d'entre eux :

        Domaine (domain) - Entité logique ou organisation qui représente une partie d'un réseau. Par exemple, unc.edu est le nom du domaine primaire de l'Université de Caroline du Nord à Chapel Hill.

        Un domaine est un noeud non-terminal de l'arborescence (cf. Figure 1) On parle parfois de domaines uniquement pour ceux qui sont en contact avec la racine et de sous-domaines pour les autres. On peut parler aussi de domaine de premier niveau, deuxième niveau...

        Nom de domaine (domain name) - Partie du nom de l'hôte qui représente le domaine qui contient l'hôte. Leur syntaxe est maintenant bien connue : les noms sont composés de plusieurs champs, séparés par des points. Le champ le plus à droite est le plus général et le champ le plus à gauche le plus particulier. Les domaines supérieurs apparaissant à droite sont de deux catégories. Ils peuvent être géographiques : le champ est alors un code à deux lettres identifiant le pays selon la norme ISO 3166 (fr étant la France, de étant l'Allemagne...). Ces domaines peuvent être aussi institutionnels : ils ont alors trois lettres (com pour entreprises privées, edu pour éducation...) Par exemple, dans l'adresse sunsite.unc.edu, le nom de domaine est unc.edu.

        Le système de noms DNS est une arborescence : juste en dessous de la racine, se trouvent les domaines supérieurs comme nous pouvons le voir sur la figure 1.



        La hiérarchie de DNS.


        Du fait de ce nommage hiérarchique, un nom simple n'a aucune raison d'être unique. Seuls les noms développés sont uniques ce qui permet aux administrateurs d'ajouter un ordinateur à leur réseau sans prévenir les autorités centrales.

        Zone - C'est une partie contigüe de l'arborescence pour laquelle un serveur a autorité. Tant que cette contigüité est respectée, l'administrateur a une grande liberté pour le découpage des zones. Il cherche en général à les faire correspondre à des réalités administratives et techniques. Le découpage en zones est donc un moyen de répartir l'autorité et les responsabilités. Il y a un chef de zone, mais il n'y a pas de chef du DNS. Le DNS est donc un système partitionné. Chaque zone a un ensemble de serveurs faisant autorité, et sur lesquels les informations sont physiquement dupliquées.

        Hôte (host) - Un ordinateur sur un réseau.

        Noeud (node) - Un ordinateur sur un réseau.

        Le serveur de nom (name server) - Un ordinateur qui procure les services DNS pour attribuer les noms DNS aux adresses IP.

        Résoudre (resolve) - Action de transcrire un nom DNS vers son adresse correspondante.

        Résolveur (resolver) - Un programme ou une routine qui extrait l'information DNS du serveur de nom.

        Résolution inverse (Reverse resolution) - Associer une adresse IP donnée à son nom DNS.

        Spoof - Action d'apparaître sur le réseau comme ayant une adresse IP ou un nom de domaine différent.

        A l'origine, quand Internet a été créé, le nombre d'hôtes sur le Net était très petit. Il était pratiquement simple de maintenir l'attribution des adresses/noms. Chaque hôte avait simplement une liste complète de tous les noms d'hôte et adresses dans une file locale. Comme la croissance d'Internet a accéléré, ce système est devenu rapidement lourd. Quand un nouvel hôte était ajouté, il était nécessaire de mettre à jour chaque file d'hôte sur chaque ordinateur. En plus, parce que chaque nouvel ordinateur résultait à une nouvelle ligne dans chaque fichier hôte, la taille des fichiers d'hôte commença à augmenter vers une très grande taille . Il a donc fallu trouver une nouvelle solution : DNS.

        DNS peut être divisé conceptuellement en 3 parties : l'espace du nom de domaine, les serveurs de noms et les résolveurs.

        1. L'espace du nom de domaine.


          2. Spécification dans une structure arborescente qui identifie un ensemble d'hôtes et procure une information sur eux. Conceptuellement, chaque noeud dans l'arbre a une base de données d'information sur les hôtes sous son autorité. Les requêtes essaient d'extraire l'information appropriée de cette base de données. En simples termes, c'est juste le listing de tous les types d'information, noms, adresses IP..., qui sont nécessaires pour la consultation dans le système DNS.

        2. Les serveurs de noms.


          3. Les programmes qui organisent et maintiennent les données situées dans l'espace du nom de domaine sont connus comme \textbf{serveurs de noms}. Chaque serveur de nom a une information complète sur un sous-ensemble de l'espace du nom de domaine et a caché l'information sur d'autres parties. Un serveur de nom a une information complète sur cette zone d'autorité. Cette information est divisée en zones qui peuvent être divisées en serveurs de noms différents pour procurer un service redondant pour une zone.

        3. Les Résolveurs.


          4.
      2. La configuration de la librairie du résolveur.


        3. La première étape dans l'utilisation de DNS est de configurer la librairie du résolveur sur l'ordinateur. Il faut configurer le résolveur local.

        1. Le fichier /etc/host.conf.


          2. Les librairies du résolveur local sont configurées via un fichier appelé host.conf qui est localisé dans le répertoire /etc. Ce fichier dit au résolveur quels services utiliser et dans quel ordre. Ce fichier est tout simplement un fichier ASCII qui liste les options du résolveur, une par ligne. Les champs dans ce fichier peuvent être séparés par des blancs ou des tabulations. Le caractère # indique un début de commentaire. Différentes options peuvent être spécifiées dans le fichier host.conf : order, alert, nospoof, trim, multi.

          order Spécifie dans quel ordre les différents mécanismes de résolution de nom sont triés. Les services de résolution spécifiés sont triés dans l'ordre listé. Les mécanismes de résolution de nom sont triés par les hôtes (essaient de résoudre le nom en regardant dans le fichier local /etc/host), bind (demande un serveur de noms DNS pour résoudre le nom) et NIS (utilise le protocole NIS pour essayer de résoudre le nom d'hôte).

          alert Prend OFF ou ON comme argument.

          nospoof Si la résolution inverse est utilisée, on fait correspondre un nom d'hôte à une adresse spécifiée.

          trim Prend un nom de domaine comme argument. trim enlève un nom de domaine avant d'exécuter une consultation de /etc/hosts sur le nom. Ceci permet de poser dans la base le nom d'hôte dans /etc/hosts sans spécifier le nom de domaine.

          multi Prend OFF ou ON comme argument. Il est utilisé pour déterminer si un hôte est permis d'avoir plus d'une adresse IP dans /etc/hosts.multi. Aucun effet sur des requêtes NIS ou DNS.

        2. Le contenu de notre fichier /etc/host.conf.


          3. order hosts, bind
          multi ON

          Note : C'est une bonne idée de spécifier le fichier local \texttt{/etc/hosts} dans la recherche de résolution. Si pour plusieurs raisons les serveurs de nom devraient être indisponibles, on peut encore résoudre les noms pour des hôtes qui sont listés dans la file locale d'hôtes. Il faut toujours garder une liste de tous les hôtes locaux dans /etc/hosts sur chacun des ordinateurs locaux. Les adresses IP multiples pour une seule machine est à éviter.

        3. Le fichier /etc/resolv.conf.


          4. Ce fichier contrôle la manière dont le résolveur utilise le DNS pour résoudre les noms d'hôtes. Il spécifie les serveurs de noms DNS à contacter quand il faut résoudre un nom d'hôte et dans quel ordre les contacter. Ceci procure aussi le nom de domaine local et des indications quant à la manière à estimer le nom de domaine d'hôtes qui sont spécifiés sans un nom de domaine. Plusieurs options peuvent être données dans le fichier /etc/resolv.conf.

          domain Le nom du domaine local de cet hôte. S'il n'est pas donné, le résolveur essaie d'obtenir le nom du domaine local à partir d'un appel système getdomainname().

          nameserver Spécifie l'adresse IP d'un serveur de nom DNS à contacter pour la résolution de nom. Il est possible de lister les serveurs de noms en utilisant l'option nameserver plusieurs fois. Les serveurs de nom sont triés dans l'ordre de listage.

          search Donne une liste des domaines à essayer si aucun nom de domaine n'est spécifié. Si aucune option search n'est donnée, la liste des domaines est créée en utilisant le domaine local plus chaque domaine parent du domaine local.

        4. Le contenu du fichier /etc/resolv.conf.


          5. domain dess98
          nameserver 193.50.208.1
          nameserver 127.0.0.1

          Note - On a besoin de spécifier l'adresse IP du serveur de nom DNS comme un argument à nameserver. Si on spécifie le nom d'hôte, DNS ne sait pas quel hôte contacter pour consulter le nom d'hôte du serveur de noms.

      3. Le démon Named.


        4. C'est ici que la réelle magie commence. Maintenant que nous avons vu comment établir les bases de la configuration du résolveur et comment dire à son résolveur quels serveurs de nom à contacter. Dans cette section, nous allons apprendre les mécanismes d'établissement d'un serveur de nom.

        Le serveur de nom DNS sous Linux est procuré par le démon named. Ce démon est lancé au moment du boot et lit son information de configuration à partir de l'ensemble des fichiers de configuration. named s'exécute sous la machine qui est fermée. Quand named} a commencé et est initialisé avec son information de configuration, il écrit les PID dans le fichier ASCII /etc/named.pid. Il commence ensuite à lister les requêtes DNS sur le port du réseau par défaut spécifié dans /etc/services.

        1. Le fichier /etc/named.boot.


          2. Le premier fichier que named lit quand il commence est /etc/named.boot. C'est un très petit fichier mais il est la clé de tous les autres fichiers de configuration utilisés par named. Il contient les pointeurs sur les différents fichiers de configuration et sur les autres serveurs de noms. Dans le fichier named.boot, il peut y avoir différentes options qui sont listées ci-dessous.

          directory Répertoire où les fichiers DNS sont localisés. On peut spécifier des répertoires différents en utilisant l'option répertoire de manière répétitive. Il faut donner le chemin entier.

          Il existe plusieurs types de serveurs : primaires, secondaires et caches. Un serveur primaire existe à un seul exemplaire par zone. Un ou plusieurs serveur(s) secondaire(s) peuvent l'épauler. Ils possèdent une base de données sur disque et peuvent éventuellement redémarrer même lorsque le serveur primaire est absent ou injoignable. A intervalles réguliers, ils interrogent le primaire pour détecter la présence de nouvelles données qu'ils téléchargent. Un serveur cache ne possède pas de base de données sur disque. Il est entièrement dépendant d'un maître, mais il peut répondre aux requêtes des clients afin de ne pas surcharger le maître. C'est avantageux si les clients et le serveur cache sont sur un réseau un peu isolé et que le maître n'est accessible que par une ligne lente et/ou chère.

          primary Prend un nom de domaine et un nom de fichier comme arguments. L'option primary déclare named comme ayant autorité sur le domaine spécifié et oblige named à charger l'information de zone à partir du fichier spécifié.

          secondary Cette option dit à named d'agir comme un serveur secondaire pour le domaine spécifié. Il prend un nom de domaine, une liste d'adresse et un nom de fichier comme arguments. named essaie de transférer l'information de zone dans le fichier spécifié sur la ligne d'option. Si named est incapable de contacter aucun des hôtes, il essaie de retrouver l'information à partir du fichier de zone secondaire.

          cache Positionne l'information de cache pour named. Prend un nom de domaine et un nom de fichier comme arguments. Le nom de domaine est spécifié comme . . Le fichier contient un ensemble d'enregistrements, qui listent l'information sur le serveur de nom du root.

          forwarders Prend une liste de serveurs de noms comme arguments. Dit au serveur de nom local d'essayer de contacter les serveurs dans cette liste s'il est incapable de résoudre une adresse à partir de son information locale.

          slave Tourne le serveur de nom local vers un serveur esclave. Si l'option slave est donnée, le serveur local essaye de résoudre les noms DNS à travers des requêtes récursives. Il expédie simplement la requête à un des serveurs listés dans la ligne d'option forwarders.

          En plus de ces options, il en existe d'autres qui ne sont pas communément utilisées (consulter man resolv.conf).

        2. Le contenu de notre fichier /etc/named.boot.


          3. directory /var/named
          cache . named.ca
          primary dess98 named.hosts
          primary 0.0.127.in-addr.arpa named.local
          primary 208.50.193.in-addr.arpa named.rev


        3. Les fichiers de bases de données et les enregistrements de ressource.


          4. Toute information dans les différents fichiers de base de données named est stockée dans un format connu comme un enregistrement de ressource. Chaque enregistrement de ressource a un type qui lui est associé et qui donne la fonction de l 'enregistrement. Un enregistrement de ressource est la plus petite pièce d'information qui est utilisée par named.

          Les enregistrements de ressource utilisent une syntaxe générale qui est systématique dans tout type d'enregistrement de ressource. Pour ajouter à la confusion, cependant, plusieurs parties de l'enregistrement sont optionnelles dépendant du type de l'enregistrement et peuvent supposer une valeur par défaut si cela n'est pas spécifié. Le format de base de l'enregistrement de ressource est :
          [owner] [ttl] [class] type data

          Les champs sont séparés par des blancs ou des tabulations.

          owner Nom de l'hôte ou du domaine auquel l'enregistrement s'applique. Si aucun nom n'est donné, le nom de domaine de l'enregistrement de ressource précédent est utilisé.

          TTL Durée de vie. Ce champ dit combien de temps, en secondes, l'information de cet enregistrement est valide après qu'il ait été récupéré par le serveur DNS. Si aucune valeur TTL n'est donnée, le TTL minimum du dernier enregistrement SOA est utilisé.
          Chaque enregistrement de ressource a une classe et un type.

          class Spécifie une classe d'adresse de réseau. Elle permet d'identifier la famille de protocoles. Pour les réseaux TPC/IP, on utilise la valeur IN. Si la classe n'est pas donnée, celle de l'enregistrement de ressource précédent est utilisée.

          type Liste le type de l'enregistrement de ressource c'est-à-dire s'il s' agit de l'adresse d'une machine (A record), du serveur de noms d'un domaine (NS record), le modèle d'une machine (HINFO record), d'un délais de courrier électronique (MX record), d'un surnom (CNAME record) ou même d'un texte libre (TXT record). Cette valeur est requise.

          Le type A C'est un enregistrement d'adresse. Il associe un nom d'hôte à une adresse. Le champ données contient l'adresse en format décimal. Il peut y avoir seulement un enregistrement A pour un hôte donné, comme cet enregistrement est considéré information autoritaire.

          Le type CNAME Ce champ assoie un alias à un hôte avec son nom canonique, le nom spécifié dans l'enregistrement A pour cet hôte.

          Le type HINFO Donne de l'information sur un hôte. Le champ donné contient l'information sur le matériel et le logiciel pour un hôte particulier.

          Le type MX Enregistrement d'échange de courrier. Le champ données prend un entier suivi d'un nom d'hôte. Les enregistrements MX disent au transport de courrier d'envoyer le courrier à un autre système qui sait comment le délivrer à sa destination finale.

          Le type NS Il indique un serveur de nom pour chaque zone. le champ donné d'un enregistrement de ressource NS contient le nom DNS du serveur de nom. Il faut spécifier un enregistrement A.

          Le type PTR Fait correspondre des adresses à des noms. Le nom d'hôte doit être le nom d'hôte canonique.

          Le type SOA (Start of Authority) Dit au serveur de nom que tous les enregistrements de ressources qui suivent sont autoritaires pour ce domaine. Le champ donné est entouré par des parenthèses et est un champ multi-ligne. Le champ donné de l'enregistrement de ressource SOA contient les entrées suivantes :
          • origin : nom canonique du serveur de nom primaire pour ce domaine. Il est habituellement donné comme un nom de domaine absolu finissant par un ., ainsi il n'est pas modifié par le démon named.

          • contact : adresse e-mail de la personne qui est responsable de ce domaine. Comme le caractère @ a un sens spécial dans les enregistrements de ressource, il est remplacé par un .

          • serial : numéro de version du fichier d'information de zone, qui est donné par un entier. Il est utilisé par les serveurs de nom secondaire pour déterminer quand le fichier d'information de zone a changé. On devrait incrémenter ce numéro de un à chaque fois que l'on change le fichier d'information.

          • refresh : longueur de temps en secondes qu'un serveur secondaire devrait attendre avant d'essayer de contrôler l'enregistrement SOA du serveur de nom primaire. Les enregistrements SOA ne changent pas très souvent.

          • retry : temps en secondes qu'un serveur secondaire attend pour essayer de relancer une requête au serveur primaire si le serveur primaire n'est pas disponible. Sa valeur doit être de quelques minutes.

          • expire : temps en secondes pendant lequel le serveur secondaire attend avant de lancer l'information de zone s'il n'a pas été capable de contacter le serveur primaire. Cette valeur est très large (environ 30 jours).

          • minimum : la valeur par défaut est égale au ttl pour les enregistrements de ressource qui ne spécifient pas ttl.

          • data : spécifie les données associées à l'enregistrement de ressource. Cette valeur est requise. le format du champ de données dépend du contenu du champ type.


          Le DNS ne prévoit aucun contrôle de cohérence sur les informations, comme il en existe dans les bases de données. Par exemple, l'unicité du triplet {classe, type, clé} n'est pas garantie. Ainsi, en cas de changement d'adresse d'une machine, si on se contente de rajouter un A record indiquant la nouvelle adresse en oubliant de supprimer les enregistrements portant l'ancienne, les deux adresses sont coexister dans le DNS. Dans certains cas, le fait qu'une machine ait deux A records est volontaire (machine ayant deux interfaces réseau par exemple). Dans d'autres cas, c'est une erreur, mais le DNS ne le sait pas et restitue toutes les informations dont il dispose, sans s'inquiéter des contradictions entre elles.

        4. Le fichier named.hosts.


          5. Dans le fichier named.boot, on liste named.hosts comme étant le fichier qui contient l'information sur le domaine local. Ce fichier contient l'information autoritaire sur les hôtes dans notre zone d'autorité. Voici un exemple de contenu du fichier named.hosts :
          INNSdess98
          localhost.INA127.0.0.1
          pc1INA193.50.208.1
          pc2INA193.50.208.2
          pc4INA193.50.208.4
          pc3INA193.50.208.3
          hpINA193.50.208.5

          Les noms d'hôte dans les enregistrements de ressource qui se terminent par le caractère . ne sont pas traduits. Si le . n'est pas le dernier caractère dans le nom d'hôte, named suppose que le nom d'hôte que l'on donne, est relatif au nom de domaine d'origine adressé par @ et ajoute le nom de domaine au nom de l'hôte.

        5. Le fichier named.rev.


          6. Le fichier named.rev est très similaire au fichier named.hosts, exception faite qu'il travaille à l'inverse. Il fait correspondre des adresses à des noms d'hôte.

          @INSOApc1.dess98.(16; 86400; 3600000; 607800; )
          INNSpc1.dess98.
          1INPTRpc1.dess98.
          2INPTRpc2.dess98.
          3INPTRpc4.dess98.
          4INPTRpc3.dess98.
          5INPTRhp.dess98.

        6. Le fichier named.ca.


          7. L'opération de cache de named est très importante. Le fichier named.ca qui établit le cache est le fichier de configuration named le plus simple. Il liste juste les serveurs de nom root pour des domaines variés accompagnés de leurs adresses IP. Il contient un couple d'indicateurs de champ spécial qui dit à named quels sont les serveurs de root. On utilise l'utilitaire nslookup pour obtenir la liste complète courant des serveurs de nom root.

          Dans le travail que nous avons effectué, ce fichier est vide.

      4. Comment éviter les problèmes?


        5. DNS est un système très complexe. Il y a beaucoup de choses que l'on peut mal faire qui causent le mauvais comportement du système. Beaucoup des problèmes de l'installation de DNS semblent identiques mais peuvent venir de causes différentes. cependant, beaucoup de problèmes résultent des erreurs de syntaxe dans les fichiers de configuration.

        1. S'assurer que la spécification des noms d'hôte est correcte dans les fichiers de configuration DNS.
        2. Etre prudent avec les noms utilisés dans les enregistrements SOA et CNAME. S'il y a des erreurs, ces enregistrements de ressource peuvent rediriger des requêtes de nom d'hôte à des ordinateurs qui n'existent pas.
        3. S'assurer d'entrer les bonnes adresses IP pour les enregistrements A et que les fichiers named.rev et named.hosts sont cohérents l'un vis à vis de l'autre.
        4. Utiliser nslookup pour tester le serveur DNS.


      5. Conclusion.


        6. Le DNS étant très souple et très général, se prête bien aux extensions. L'une d'elles est le système Hésiod (qui a entraîné la création d'une nouvelle classe HS), qui sert aussi bien à récupérer les mots de passe d'utilisateur (distribution de la base de données des utilisateurs) que les numéros de services TCP/IP.

        Une autre possibilité d'extension consiste en l'ajout de types supplémentaires dans la classe IN.

        Le système d'annuaire "officiel" de l'OSI s'appelle X500. Il est plus riche que le DNS, mais n'a connu à ce jour que très peu de mises en oeuvre et encore moins de déploiements en vraie grandeur.

        Certains des concepts de base de X500 sont les mêmes que ceux du DNS : pas de tentative d'assurer une cohérence à tout instant, modèle hiérarchique des données et de l'organisation, notion de serveur faisant autorité... Cette ressemblance est parfois masquée par un vocabulaire radicalement différent. L'arborescence des noms se nomme DIT (Directory Information Tree) , le résolveur DUA (Directory User Agent) et le serveur DSA (Directory System Agent). Un concept proche de celui de zone existe sous le nom de DMD (Directory Management Domain).

        Le DNS a prouvé son efficacité et sa robustesse en étant l'un des principaux protocoles de haut niveau d'Internet, et l'un des plus indispensables. Des années d'exploitation quotidienne ont montré la validité des concepts sur lesquels il repose. Certaines de ses limites pourront être repoussées avec l'utilisation de nouvelles classes ou types. D'autres nécessiteront des systèmes différents, sans doute plus généraux, permettant la description de données plus riches, autorisant la collecte aussi bien que la diffusion d'informations et plus efficaces pour de grands volumes de données.