Home Index Search Links About Us
[LinuxFocus Image]
[Navegation Bar]
B Nouveautés  Archives 

Introduction au DNS

par Andreas J Gundacker

Cet article est destiné à toute personne intéressée par les réseaux mondiaux d'ordinateurs, comme Internet et le World Wide Web (WWW). Il s'adresse à ceux qui désirent en savoir plus sur leurs fonctionnalités. 
Si vous vous êtes déjà interrogé sur ce qui se passe  lorsque vous entrez le nom d'un serveur dans votre navigateur, cet article vous aidera à comprendre de façon simple les mécanismes mis en oeuvre.  

Cet article est initialement paru dans Linux Magazine.
Publié avec l'autorisation de l'auteur
 
L'article est divisé en cinq parties : 

La première explique brièvement ce que signifie Internet et comment il est apparu. 
La seconde vous aidera à comprendre certaines expressions techniques. 
La troisième est dédiée aux protocoles les plus importants d'Internet : TCP et IP. 
La quatrième décrit les fonctionnalités du DNS. 
La dernière partie est une description pratique de la mise en place d'un service de nom de domaine (DNS) pour un réseau local avec une passerelle, et la façon dont l'auteur l'a réalisé avec Linux. Ainsi, ce document est à la fois une introduction pour les novices et une référence pratique pour les connaisseurs.  

1 ARPANET, l'origine du World Wide Web
2 Quelques expressions techniques  
3 TCP/IP 
   3.1 IP (Internet Protocol) 
   3.2 TCP (Transmission Control Protocol) 
4  Le Système de Nom de Domaine (DNS) 
   4.1 Présentation du système 
   4.2 De l'utilité du DNS

5  Installation d'un Système de Nom de Domaine

   5.1 Fichiers de base de données
   5.2 Les enregistrements
   5.3 L'ensemble des fichiers pour notre
domaine fictif
    5.4 Abréviations
  5.5  La bibliothèque du Résolveur
   5.6  Testez votre configuration avec nslookup 

   
(1) ARPANET, l'origine du World Wide Web 

Le terme "Internet" représente l'interconnexion de réseaux d'ordinateurs issu du projet ARPANET, lancé en 1969 par l'agence américaine DARPA (Defense Advanced Research Project Agency). Quand ARPANET est sorti du stade expérimental, les protocoles de base de TCP/IP étaient développés et choisis comme norme par l'armée. Toutes les autres institutions constituant ARPANET durent adopter les nouveaux protocoles. Pour faciliter le basculement, la DARPA désigna la société Bolt, Beranek & Newman (BBN) pour intégrer TCP/IP au système Berkeley-UNIX (BSD). C'est ainsi qu'UNIX et TCP/IP furent intimement liés. 

En 1983, ARPANET fut divisé en MILNET, une partie du réseau de Défense DDN (Defense Data Network) ; l'autre partie devint un nouvel ARPANET, plus petit. L'ensemble MILNET et ARPANET contrôlait l'INTERNET. ARPANET disparût en 1990 ouvrant la porte à l'Internet, qui relie un grand nombre de réseaux autour du globe. 

 

(2) Quelques expressions techniques 

Supposez que vous êtes assis devant un ordinateur connecté au réseau local (LAN) du département de mathématique de l'université (Figure 1). 

Le LAN de mathématique est relié par le backbone (noeud principal) au LAN du département de physique situé dans un autre batiment. Vous souhaitez envoyer des données à un ami du département de physique. Il faut d'abord que chacun des ordinateurs soit identifié par un nom unique sur le réseau de l'université (de même pour tous les ordinateurs sur Internet). Nous supposerons que votre ordinateur s'appelle Einstein et celui de votre ami Edison. Pour que deux ordinateurs situés sur deux réseaux physiquement indépendants puissent communiquer, ils ont chacun besoin d'une passerelle (gateway). La passerelle est un ordinateur capable de réunir deux réseaux physiquement indépendants. Nous avons donc besoin ici de deux passerelles - une pour le LAN de mathématique, l'autre pour celui de physique. Nous appellerons respectivement "math" et "phys" les passerelles de mathématique et physique. 

Figure 1: Cheminement d'un datagramme d'Einstein à Edison 

Comme les applications d'Einstein (rlogin, telnet, ftp, etc.) ne peuvent envoyer des données (des paquets de données) directement à Edison, qui est situé sur un réseau différent, ce sont les passerelles qui sont responsables du transport des paquets à la bonne destination. En d'autres termes, la passerelle "math" envoie des paquets la passerelle "phys ", qui a la même fonction sur le LAN de physique. Le transfert se réalise à travers le backbone de l'université, et "phys" délivre finalement les données à Edison. Ce schéma de transmission de données à un hôte distant (ordinateur connecté au réseau) est appelé routage et les données ou paquets datagrammes

(3) TCP/IP 

(3.1) IP  

Les datagrammes, plus petites unités de transmission de données, sont échangés selon un protocole - le Protocole Internet (IP), qui est complètement indépendant du matériel. Ainsi, le principal avantage d'IP est d'unir des réseaux physiquement séparés en un réseau apparamment homogène. 

Les fonctions principales d'IP: 

  • Definir les datagrammes: pour envoyer un fichier à travers le réseau, on le divise en petites parties, des blocs de données appelés paquets. 
  • Etablir l'adresse Internet: IP inclue cette information dans l'entête, avec sa propre identification. 
  • Router les datagrammes aux ordinateurs distants: si un datagramme est envoyé à un ordinateur qui n'est pas présent physiquement sur le même reseau, il est transmis à une passerelle pour parvenir à la destination. 
Par contre, IP n'assure pas le contrôle de la transmission (dialogue ou handshake); en d'autres termes IP transporte les paquets d'un ordinateur à l'autre, sans contrôler si tous les paquets sont reçus dans le bon ordre. Nous reviendrons à ce problème plus avant. 

Nous avons maintenant une idée de la transmission (routage). Souvenez-vous que votre ordinateur porte le nom d'Einstein. Les ordinateurs connectés à un réseau sont baptisés car il est plus facile de se rappeler un nom qu'une séquence de nombres. 

IP utilise un schéma d'adressage indépendant du matériel. Chaque ordinateur est associé à un unique nombre à 32 bits : l'adresse IP (IP). L'adresse IP est exprimée sous la forme de 4 nombres séparés par des points. Einstein pourrait par exemple avoir l'adresse matérielle 0x952C0C02, et l'adresse IP 149.176.12.7

Il faut comprendre que chaque ordinateur a trois adresses distinctes : 

  • le nom d'hôte: Einstein,
  • l'adresse IP: 149.176.12.7,
  • et l'adresse matérielle, qui peut être une carte Ethernet d'identificateur unique 0x952C0C02.
L'adresse de la carte Ethernet correspond à un port du système d'exploitation; il s'agit généralement de eth0-n sous Linux. Les ports séries par exemple au nom cua0-n ou ttyS0-n. Pour être précis, le nom Einstein correspond à l'interface matérielle et non à la machine elle-même. 

Nous savons maintenant que le protocole Internet (IP) transmet les données entre ordinateurs sous la forme de datagrammes. Chaque datagramme est transmis à l'adresse destination indiquée dans l'entete du datagramme, sur Internet ou d'autres réseaux locaux. L'adresse destination doit être une adresse IP standard sur 32 bits, elle est suffisante pour identifier sans équivoque un ordinateur du réseau. 

Une addresse IP est constitué de deux parties : 
 

  • l'adresse d'un réseau,
  • l'adresse d'un hôte (ordinateur) de ce réseau.
Le nombre d'adresses d'hôtes dépend de la taille du réseau. Afin d'obtenir une bonne adaptation aux différentes situations, plusieurs classes de réseaux ont été créées qui définissent les séparations des adresses IP. 
 
 
Classe A:   La classe A englobe les réseaux de 1.0.0.0 à 127.0.0.0. Le numéro de ce type de réseau correspond au premier octet. Les 24 bits suivants définissent les hôtes, soit plus de 16 millions d'ordinateurs pour chaque réseau de la classe A. 
Classe B:   Pour la classe B les réseaux vont de 128.0.0.0 à 191.255.0.0. Le numéro de réseau est alors composé des deux premiers octets. Cela permet 16.320 réseaux de 65.024 ordinateurs. 
Classe C:   La classe C est constituée par les réseaux de 192.0.0.0 à 223.255.255.0. Le numéro de réseau est alors donné par les trois premiers octets, ce qui autorise plus de 2 millions de réseaux de 254 hôtes. 
Classes D, E and F:   Les adresses de la plage 224.0.0.0 à 225.0.0.0 sont experimentales, ou sont réservées pour une utilisation future et ne définissent aucun réseau.
Reprenons notre exemple. On constate qu'Einsten, dont l'adresse IP est 149.176.12.7, appartient au réseau de classe B 149.176.0.0, dont il est l'hôte 12.7. Il faut aussi noter que l'adresse d'hôte ne peut comporter ni 0 ni 255, réservés à une utilisation particulière. l'adresse d'hôte qui ne comporte que des 0 identifie le réseau (149.176.0.0). Le nombre 255 représente l'adresse de diffusion (broadcast), ce qui signifie que tous les ordinateurs du réseau 149.176.0.0 recevront les données envoyées à l'adresse 149.176.255.255. 

Deux autres adresses sont réservées : 0.0.0.0 appelée route par défaut (default route), et 127.0.0.0 l'adresse de bouclage (loopback address). La route par défaut intervient dans le routage des datagrammes par IP (cf. maquillage). 

Pour le moment, le plus important est le réseau 127.0.0.0, réservé pour le traffic IP sur la machine elle-même. L'adresse IP 127.0.0.1 fait habituellement référence à l'interface de votre ordinateur appelée interface de bouclage, qui fonctionne en circuit fermé. Tout paquet envoyé à cette adresse est immédiatement retournée à l'expéditeur. Ainsi, le bouclage permet de réaliser des essais sans obligatoirement utiliser le réseau "réel". 
"Ping localhost" or "ping 127.0.0.1" est régulièrement utilisé sous UNIX pour vérifier que TCP/IP est correctement installé et configuré. 

L'adresse IP dont vous disposerez finalement est attribuée par un organisme appelé NIC (Network Information Center). La meilleure solution consiste à demander à votre fournisseur d'accès Internet de réserver une adresse IP. Si vous êtes certain que votre réseau ne sera jamais connecté à Internet, vous pouvez choisir les adresses IP librement. Mais afin de s'assurer qu'aucun paquet ne trouvera de chemin vers Internet, il est préférable d'utiliser des adresses IP valides uniquement dans un réseau privé, et non valides sur les systèmes connectés à Internet. 

Les adresses réservées aux réseaux privés sont: 

  • Classe A: 10.0.0.0
  • Classe B: 172.16.0.0 to 172.31.0.0
  • Classe C: 192.168.0.0
Il est néanmoins possible d'installer une passerelle vers Internet. En d'autres termes, l'adresse externe est connue d'Internet ; vos hotes ne sont pas visibles depuis Internet, par contre, ils pourront accéder au WWW (World Wide Web). 

 

(3.2) Protocole de contrôle de Transmission TCP (Transmission Control Protocol) 

Il a été signalé précédemment qu'IP ne fournit pas de contrôle de la transmission; TCP est responsable de cette partie. TCP est un protocole de flux de données, fiable et orienté connexion

  • On parle de flux de données, parce que TCP considère les données comme une entité unique et non comme une suite de paquets indépendants.
  • Il est fiable car il vérifie l'arrivée de tous les datagrammes. Si l'un est perdu, l'expéditeur reçoit l'information correspondante du destinataire; les paquets perdus sont réexpédiés jusqu'à ce qu'ils aient tous été reçus. 
  • Orienté connexion signifie que TCP établit une voie logique entre les deux ordinateurs; avant l'envoi de données, TCP transmet des informations de contrôle (dialogue ou handshake) entre l'expéditeur et le destinataire, afin d'initialiser la communication entre les deux hôtes. 
TCP prend ainsi soin du bon ordonnancement des données. 

 

(4) Le système de nom de domaine (DNS) 

(4.1) Présentation du système 

Le système de nom de domaine (DNS, Domain Name System) est essentiellement une base de données répartie décrivant les ordinateurs qui composent une partie d'un réseau. Cela permet localement de contrôler aisément tous les morceaux de la base données, ce qui conduit à la disponibilité de la base de données complète de n'importe quel point du réseau, selon un schéma client- serveur

Le Serveur de Noms est le programme serveur du mécanisme client-serveur de DNS. Les Serveurs de Noms disposent de l'information concernant une partie de la base de données, et la rendent disponible aux clients, appelés Résolveurs. Très souvent, les Résolveurs sont constitués de routines qui créent et envoient des requêtes au Serveur de Nom à travers le réseau. 

La base de données DNS est représentée à la figure 2. La structure est celle d'un arbre inversé, avec la racine vers le haut. Le nom de la racine est NULL, mais on l'écrit usuellement comme un point ("."). Chaque noeud de l'arbre représente à la fois une partie de la base de données globale, ainsi qu'un domaine du DNS. Chaque domaine peut être divisé en sous domaines, enfants du noeud parent. 

Figure 2: La base de données DNS 

Chaque domaine est repèré relativement à son domaine parent. Le domaine dispose aussi d'un nom de domaine, qui identifie sa position dans la base de données, un peu comme le répertoire racine précise sa place dans le système de fichiers d'un ordinateur. 

Dans le système DNS, le nom de domaine complet est une suite de repères débutant au domaine et s'étendant jusqu'à la racine, les repères étant séparés par des points "." (par exemple: einstein.mathematics.ac.edu), permettant une administration indépendante de chacun des domaines. Chaque organisation peut diviser ses domaines en plusieurs sous domaines, dont l'administration peut être réalisée par d'autres organisations. 

Par exemple, le Network Information Center administre le domaine "edu" (éducation) mais délègue son autorité pour le sous domaine "ac.edu" (académique) à l'université, qui autorise le département de physique à administrer le domaine suivant : "mathematics.ac.edu" (Figure 3). 

 
Figure 3: Gestion des sous domaines 

Enfin, il faut signaler qu'un domaine peut contenir des sous domaines aussi bien que des hôtes. Chaque hôte sur un réseau a un nom de domaine qui contient des informations sur l'hôte, telles que son adresse IP ou le routage du courrier, etc. Un hôte peut aussi avoir un ou plusieurs alias qui sont simplement des références au nom de domaine canonique. Un exemple: si votre femme s'appelle Marie Elisabeth, il peut arriver de l'appeler parfois Marie et Elisabeth d'autres fois. Bien que vous utilisiez des noms différents, vous faites référence à une personne unique. 

Les organisations de domaine sont libres de choisir les noms à l'intérieur de leur domaine. En effet, le nom importe peu puisqu'il sera complèté par un nom de domaine qui est unique: ainsi il est certain qu'il n'apparaîtra jamais de conflit de nom. Par exemple, deux hôtes appelés einstein peuvent coexister dans le réseau de l'université. Les données envoyées de einstein.physics.ac.edu arriveront à einstein.mathematics.ac.edu, car ils appartiennent à deux sous domaines différents. 

 

(4.2) Pourquoi DNS est-il nécessaire? 

Pour résoudre les noms de domaine et les adresses IP, et afin de localiser les machines des réseaux distants. Comme indiqué précédemment, il est plus simple de mémoriser des noms que des nombres, surtout lorsqu'on considère le nombre d'adresses sur Internet. 

Les ordinateurs, au contraire, utilisent naturellement des nombres telles les adresses IP. Lorsque vous entrez sur Internet en spécifiant une adresse comme, par exemple, http://www.altavista.com, votre navigateur envoie une requête au Serveur de Domaine de votre fournisseur d'accès, qui essaie de déterminer l'adresse IP correspondante. Si votre fournisseur n'est pas l'autorité pour cette zone, il transmet la requête au domaine autorité, jusqu'à ce qu'elle arrive au domaine indiqué. (La figure 4 détaille une recherche avec l'adresse "einstein.mathematics.ac.edu") 

Figure 4: Résolution de einstein.mathematics.ac.edu sur Internet

Cela signifie que chaque serveur de domaine dispose de toutes les informations relatives à la zone qu'il contrôle, et aussi des informations de base sur les autres zones. Quand une requête est envoyée en dehors de la zone d'autorité, le serveur sait au minimum où chercher. Cela signifie que la requête peut avoir à transiter par plusieurs serveurs de domaine avant d'atteindre la destination finale. 

même si vous connaissez l'adresse IP de destination, il faut consulter d'autres serveurs de domaine si votre ordinateur n'est pas dans la même zone. Il est ainsi clair que le Système de Nom de Domaine ne peut être centralisé en une seule base de données. Il serait trop long de trouver un serveur parmis des millions, et la queue serait longue pour répondre aux milliers de demandes de recherche arrivant simultanément du monde entier. En outre, il serait inefficace d'appeler un serveur distant pour communiquer avec un hôte dans la même zone. 

Nous avons parlé jusqu'à présent de la translation de noms en adresses. Mais comment déterminer le nom d'une machine dont l'adresse est connue ! Le domaine "in-addr.arpa" (Figure 5) a été créé pour résoudre ce problème. 

On l'appelle domaine inverse et la résolution des adresses IP en noms de domaine se nomme table inverse (translation inverse). Le nom de domaine inverse est créé en inversant les nombres de l'adresse IP, et ajoutant in-addr.arpa à la fin. 

Par exemple : rappelez-vous l'adresse IP d'Einstein au département de mathématique, "149.176.12.7", son nom de domaine est "einstein.mathematics.ac.edu". 

Le domaine "mathematics.ac.edu" aurait donc pour nom de domaine inverse: "176.149.in-addr.arpa", et de même la machine einstein.mathematics.ac.edu devient "7.12.176.149.in-addr.arpa". 

Figure 5: La table inverse 

 

(5) Installation d'un Serveur de Noms de Domaine (DNS) pour un réseau local (LAN) avec passerelle sous Linux avec BIND (Berkeley Internet Name Daemon).  

La suite suppose que vous savez installer et configurer les cartes réseaux sous Linux. Les commandes "ifconfig" et "ping localhost" permettent de vérifier la configuration réseau de chaque ordinateur. Nous allons maintenant connecter les ordinateurs avec DNS en utilisant BIND. Il faut au préalable avoir installé l'ensemble BIND, qui comprend "named" (prononcer name-d, le démon serveur) sur l'ordinateur acceuillant le serveur de domaine. Nous allons installer un domaine ficif, que vous pourrez réutiliser pour votre réseau en changeant simplement le nom des machines et les adresses IP. 

 
Figure 6: Le réseau de Alcomat Distribution 

Notre réseau est installé dans la société "Alcomat Distribution", distributeur spécialisé dans la bière et les alcools. Le nom de domaine "alcomat.com" a été attribué par le NIC à la société. Alcomat Distribution dispose de deux réseaux Ethernet avec les adresses en classe C 192.249.249 et 192.253.253. (Figure 6). 

La table des hôtes (fichier /etc/hosts en général) comporte les informations suivantes: 
 
 
/etc/hosts 
127.0.0.1       localhost

# Machines du sous réseau alcool

192.249.249.2   whisky.alcomat.com              whisky 

192.249.249.3   brandy.alcomat.com              brandy

192.249.249.4   vodka.alcomat.com               vodka

        .........

# Machines du sous réseau bière

192.253.253.2   mahou.alcomat.com               mahou

192.253.253.3   augustiner.alcomat.com          augustiner

192.253.253.4   polar.alcomat.com               polar

        ..........

# Passerelle entre les réseaux Ethernet

192.249.249.1   tubo.alcomat.com tubo   tu       tub249

192.253.253.1   tubo.alcomat.com tubo   tu       tub253
 

(5.1) Fichiers de base de données 

La première étape consiste à traduire la table des hôtes en données DNS. DNS est constitué de plusieurs fichiers: l'un donne la correspondance entre les noms d'hôtes et les adresses IP. D'autres transforment les adresses IP en nom d'hôtes. Comme nous l'avons indiqué, il s'agit de la translation inverse, et chaque sous réseau doit disposer de son propre fichier pour la réaliser. 

J'ai appelé named.hosts le fichier transformant les noms en adresses; named.249 et named.253 sont les fichiers pour les deux sous réseaux de la société. Ces fichiers peuvent porter n'importe quel nom. Ils constituent les fichiers de base de données du DNS. 

Il existe en outre deux autres fichiers plus ou moins équivalents pour tous les serveurs: named.cache et named.local

Afin de retrouver les différents fichiers nécessaires, le Serveur de Noms dispose d'un fichier de configuration – pour BIND, il s'agit généralement de /etc/named.boot. Les fichiers de base sont spécifiques à DNS. Le fichier de configuration est lui-même spécifique à l'implémentation du DNS –nous nous limitons à la description de BIND. 

 

(5.2) Enregistrements de référence 

La majorité des enregistrements de ces fichiers sont appelés enregistrements DNS de référence. Ils doivent être donnés dans l'ordre suivant: 

  • Enregistrement SOA: Désigne l'autorité pour le domaine,
  • Enregistrement NS: Indique le Serveur de Noms pour ce domaine.
Les enregistrements suivants donnent les inforamtions sur les hôtes du domaine: 
  • A: translation nom --> adresse,
  • PTR: translation adresse --> nom (translation inverse),
  • CNAME: nom canonique (nom officiel de l'hôte),
  • TXT: information libre (texte),
  • RP: personne responsable.
Commentaires: Comme toujours, l'utilisation judicieuse des commentaires et des sauts de ligne facilite la lecture des fichiers DNS. Les commentaires commencent par un point-virgule et prennent fin avec la ligne. Les Serveurs de Noms ignorent les commentaires et lignes blanches. 

Enregistrement SOA: 
Le premier enregistrement de chaque fichier est l'Autorité Primaire (SOA, Start Of Authority). Cette ligne indique que ce Serveur de Noms est la source primaire d'information sur les hôtes de ce domaine. Notre Serveur de Noms, "augustiner", est autorité sur le domaine "alcomat.com" à cause de l'enregistrement SOA. L'enregistrement SOA est requis pour les fichiers named.hosts, named.249 et named.253. Nous ajouterons l'enregistrement SOA dans le fichier "named.hosts". 
 
 
Enregistrement SOA
alcomat.com.   IN SOA augustiner.alcomat.com.  jean.mahou.alcomat.com. (
                                  1          ; Série pour mise à jour
                                  10800      ; Mise à jour 3 heures
                                  3600       ; Nouvelle tentative après 1 heure
                                  604800     ; Expire après 1 semaine
                                  86400 )    ; Minimum TTL 1 semaine
Le nom "alcomat.com" doit être dans la première colonne. Le point à la fin des noms est très important! S'il n'était pas présent, le domaine "alcomat.com" serait automatiquement ajouté, ce qui n'aurait plus aucune signification. Nous y reviendrons au sujet des abréviations

"IN" signifie Internet. D'autres classes existent, mais aucune n'est couramment utilisée. 

 

Le premier nom après SOA, augustiner.alcomat.com, est celui du Serveur de Noms. On trouve ensuite l'adresse E-mail , jean.mahou.alcomat.com du responsable du Serveur de Noms (en remplacant le premier point "." par "@"). BIND fournit aussi l'enregistrement de type RP (Responsible Person) pour cette fonctionalité. 

Les parenthèses permettent de développer l'enregistrement SOA sur plusieurs lignes. La plupart des lignes entre les parenthèses sont des informations pour les Serveurs de Nom secondaires, que nous n'utilisons pas dans notre réseau fictif, et qui pourrait être le sujet d'un prochain article. 

Les fichiers "named.249" and "named.253" contiennent des enregistrements SOA identiques. Remarquons que dans ces fichiers, le premier nom de l'enregistrement SOA de alcomat.com est remplacé par le nom correspondant du domaine in-addr.arpa: 249.249.in-addr.arpa et 253.253.in-addr.arpa. 

Enregistrement NS: 
La ligne suivante dans chaque fichier de base de données est l'enregistrement NS (Name Server). Les enregistrements de notre domaine sont: 
 
 
Enregistrement NS
alcomat.com.      IN NS     augustiner.alcomat.com. 
alcomat.com.      IN NS     tubo.alcomat.com. 
Ces enregistrements indiquent que deux Serveurs de Noms existent pour le domaine "alcomat.com". Les Serveurs de Noms sont installés sur les hôtes "augustiner" et "tubo". Les hôtes qui comme "tubo" disposent de plus d'une interface réseau (dans notre exemple deux cartes Ethernet) sont d'excellents choix pour être Serveur de Noms. D'abord parce qu'ils sont accessibles directement par les machines des deux réseaux, et souvent ils servent de routeurs. Enfin, ils sont rarement hors service, car ils sont activement surveillés. 

Comme pour l'enregistrement SOA, nous ajouterons les enregistrements NS aux fichiers named.249 et named.253

Enregistrements d'adresse et d'alias
Il reste à indiquer les correspondances adresses --> noms d'hôtes. Il faut ajouter les enregistrements suivants au fichier "named.hosts". 

 
 
A record
;
; Adresses des hôtes
;

localhost.alcomat.com.   IN A      127.0.0.1
mahou.alcomat.com.       IN A      192.253.253.2
augustiner.alcomat.com.  IN A      192.253.253.3
polar.alcomat.com.       IN A      192.253.253.4

;
; hôtes avec adresses multiples
;

tubo.alcomat.com.        IN A      192.253.253.1
tubo.alcomat.com.        IN A      192.249.249.1

;
; Alias
;

edel.alcomat.com.        IN CNAME  augustiner.alcomat.com.
pol.alcomat.com.         IN CNAME  polar.alcomat.com.
tu.alcomat.com.          IN CNAME  tubo.alcomat.com.
tub249.alcomat.com.      IN A      192.249.249.1
tub253.alcomat.com.      IN A      192.253.253.1
Les deux premiers blocs sont très explicites. le "A" indique une adresse. Chaque ligne associe une adresse à un nom d'hôte. "tubo", la passerelle de notre réseau, dispose de deux adresses, et donc son nom apparaît sur deux lignes du fichier. 

Le troisième bloc est la table des alias. Pour les trois premiers alias, nous créons un enregistrement CNAME (nom canonique, nom d'hôte complet). Pour les deux alias suivants, nous créerons des enregistrements d'adresse. 

Quand un Serveur de Noms reçoit une requête et trouve un enregistrement CNAME, il remplace le nom par le nom primaire, et recommence sa recherche. Par exemple, si le Serveur de Noms cherche "tu", il trouve l'enregistrement CNAME indiquant le nom "tubo", et renvoie les adresses 192.249.249.1 et 192.253.253.1. 

Les deux dernières lignes résolvent le problème lié aux interfaces multiples. Notre passerelle, "tubo" dispose de deux cartes Ethernet; supposons que l'on souhaite tester l'une des deux interfaces. La solution habituelle consiste à exécuter "ping" sur l'interface à tester. Si on exécute "ping tubo", le Serveur de Noms renvoie les deux adresses. Les alias "tub249" et "tub253" permettent de sélectionner chacune des interfaces. Pour tester l'interface 192.249.249.1, il suffit d'exécuter "ping tub249", qui réfère à une unique interface. De même, pour "tub253". 

On peut en déduire une règle générale
 
Quand un hôte a plus d'une interface, il faut créer un alias pour chaque adresse de l'hôte, et un enregitrement "A" pour chaque alias.
Il en résulte aussi qu'il faut proscrire les noms d'hôtes tels "tub249" et "tub253", réservés à l'administration du système. 

 

Enregistrements PTR 
Nous allons maintenant créer les correspondances: adresses --> noms d'hôtes. Le fichier "named.249" contient la table de correspondance pour le sous-réseau 192.249.49. Les enregistrements de ce fichier sont de type PTR (pointeur). Il faut un enregistrement (ligne) par hôte. (Rappelons que le DNS fournit des adresses à partir des noms d'hôtes). Les adresses sont inversées, puis "in-addr.arpa" est ajouté. 

Voici les enregistrements PTR pour le sous-réseau 192.249.249:
 
 
Enregistrements PTR
1.249.249.192.in-addr.arpa.     IN PTR     tubo.alcomat.com.
2.249.249.192.in-addr.arpa.     IN PTR     whisky.alcomat.com.
3.249.249.192.in-addr.arpa.     IN PTR     brandy.alcomat.com.
4.249.249.192.in-addr.arpa.     IN PTR     vodka.alcomat.com.
 
Rappelons que "tubo" a deux adresses puisqu'il dispose de deux interfaces. Néanmoins, une seule apparaît dans le fichier "named.249". En effet, ce fichier renseigne uniquement sur le sous-réseau 192.249.249, et "tubo" ne dispose que d'une interface d'adresse 192.249.249.1 sur ce réseau. Le fichier "named.253" est équivalent. 

 

(5.3) L'ensemble des fichiers de notre domaine fictif 

La table des hôtes du domaine alcomat.com 
 
named.hosts
alcomat.com.   IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
;
; Nos Serveurs de noms
;

alcomat.com.             IN NS     augustiner.alcomat.com. 
alcomat.com.             IN NS     tubo.alcomat.com. 

;
; Adresses des hôtes
;

localhost.alcomat.com.   IN A      127.0.0.1
mahou.alcomat.com.       IN A      192.253.253.2
augustiner.alcomat.com.  IN A      192.253.253.3
polar.alcomat.com.       IN A      192.253.253.4
whisky.alcomat.com.      IN A      192.249.249.2
brandy.alcomat.com.      IN A      192.249.249.3
vodka.alcomat.com.       IN A      192.249.249.4

;
; hôtes avec adresses multiples
;

tubo.alcomat.com.        IN A      192.253.253.1
tubo.alcomat.com.        IN A      192.249.249.1

;
; Alias
;

edel.alcomat.com.        IN CNAME  augustiner.alcomat.com.
pol.alcomat.com.         IN CNAME  polar.alcomat.com.
tu.alcomat.com.          IN CNAME  tubo.alcomat.com.
tub249.alcomat.com.      IN A      192.249.249.1
tub253.alcomat.com.      IN A      192.253.253.1
 

Les fichiers de correspondance adresse --> nom d'hôte named.249 et named.253 
 
named.249
249.249.192.in-addr.arpa. IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
;
; Serveurs de nom
;
249.249.192.in-addr.arpa.         IN NS      augustiner.alcomat.com. 
249.249.192.in-addr.arpa.         IN NS      tubo.alcomat.com. 

;
; Table de translation inverse
;
1.249.249.192.in-addr.arpa.       IN PTR     tubo.alcomat.com.
2.249.249.192.in-addr.arpa.       IN PTR     whisky.alcomat.com.
3.249.249.192.in-addr.arpa.       IN PTR     brandy.alcomat.com.
4.249.249.192.in-addr.arpa.       IN PTR     vodka.alcomat.com.
 
 
named.253
253.253.192.in-addr.arpa. IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
;
; Name Servers
;
253.253.192.in-addr.arpa.         IN NS      augustiner.alcomat.com. 
253.253.192.in-addr.arpa.         IN NS      tubo.alcomat.com. 

;
; Address to name map
;
1.253.253.192.in-addr.arpa.       IN PTR     tubo.alcomat.com.
2.253.253.192.in-addr.arpa.       IN PTR     mahou.alcomat.com.
3.253.253.192.in-addr.arpa.       IN PTR     augustiner.alcomat.com.
4.253.253.192.in-addr.arpa.       IN PTR     polar.alcomat.com.
 

L'adresse de boucle 

Il faut au Serveur de Noms un fichier supplémentaire pour le "réseau de boucle": named.local. Cette adresse est utilisée par les machines pour des échanges avec elles-même. Le réseau de boucle est (pratiquement) toujours 127.0.0 et l'adresse IP 127.0.0.1. 
 
named.local
0.0.127.in-addr.arpa.     IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
;
; Name Servers
;
0.0.127.in-addr.arpa.         IN NS      augustiner.alcomat.com. 
0.0.127.in-addr.arpa.         IN NS      tubo.alcomat.com. 

;
; Address to name map
;
0.0.127.in-addr.arpa.         IN PTR     localhost.
 

Le fichier named.cache 

Ce fichier contient les adresses et noms de tous les Serveurs de Noms racine d'Internet. Si vous ne prévoyez pas de connexion de votre réseau à Internet, il est inutile. 
Bien que la distribution BIND dispose généralement de ce fichier (named.root ou named.cache), il est conseillé de télécharger via "ftp" en anonyme la dernière mise à jour de ce fichier depuis ftp.ts.internic.net(198.41.0.5). Comme ce fichier est commun à pratiquement tous les Serveurs de Noms et est installé automatiquement par BIND, nous ne l'expliquerons pas. Il faut simplement connaitre le nom qu'il porte dans votre version de BIND. 

Le fichier de démarrage: named.boot 

Finalement, il nous manque le fichier permettant d'unifier la base de données. En d'autres termes, le Serveur de Noms a besoin d'un fichier qui lui indique où sont situés les fichiers de base de données. 
BIND lit le fichier /etc/named.boot. Dans notre exemple, les fichiers de base de données sont dans le répertoire /usr/local/named. Ces fichiers peuvent être situés dans un autre répertoire, mais il est recommandé de ne pas les placer dans le système de fichiers racine à cause du manque de place. 
 
named.boot
directory       /usr/local/named
primary    alcomat.com                named.hosts
primary    249.249.192.in-addr.arpa   named.249
primary    253.253.192-in-addr.arpa   named.253
primary    0.0.127.in-addr.arpa       named.local

cache      .                          named.cache
Une fois tous ces fichiers installés, il reste à activer le démon "named" au démarrage de la machine. 

 

(5.4) Abréviations 

Jusqu'à présent, nous avons créés des fichiers très détaillés pour faciliter la compréhension. Néanmoins, il existe de nombreuses abréviations couramment utilisées.  

L'origine 
La deuxième colonne du fichier de démarrage "named.boot" indique toujours un domaine. Ce domaine est la clé de l'abréviation la plus utile, et il indique l'origine de toute l'information pour le fichier correspondant 
L'origine est ajoutée à tous les noms du fichier qui ne se terminent pas par un point ! (par exemple, "mahou.alcomat.com" deviendrait "mahou.alcomat.com.alcomat.com"). L'origine est différente pour chacun des fichiers de la base de données.  

L'adresse de "mahou" dans named.hosts:
mahou.alcomat.com.      IN A    192.253.253.2

aurait pu être écrite:
mahou                   IN A    192.253.253.2
Dans le fichier named.249 l'adresse: 
2.249.249.192.in-addr.arpa.     IN PTR  whisky.alcomat.com.
est équivalente à:
2                               IN PTR  whisky.alcomat.com.
puisque 249.249.192.in-addr.arpa est l'origine. 
La notation @ 
Si le nom de domaine est le même que l'origine, il peut être déterminé par "@". Cela apparaît souvent avec l'enregistrement SOA: 
@          IN SOA augustiner.alcomat.com.  juan.mahou.alcomat.com. (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
Répétition des noms précédents 
Si la première colonne d'un enregistrement est un espace ou une tabulation, le nom de l'enregistrement précédent est utilisé. Le travail est ainsi grandement facilité quand plusieurs enregistrements font référence à un même nom: 
tubo                    IN A      192.253.253.1
                        IN A      192.249.249.1
Voici maintenant le fichier "named.hosts" sous sa forme abrègée. Un bon exercice consisterait à réécrire les autres fichiers en utilisant les abréviations;-)) 
 
named.hosts (abrègé)
@   IN SOA      augustiner      juan.mahou (
                                  1          ; Serial for updates
                                  10800      ; Refresh after 3 hours
                                  3600       ; Retry after 1 hours
                                  604800     ; Expire after 1 week
                                  86400 )    ; Minimum TTL of 1 week
;
; Notre Serveur de noms (le nom @ est inclus)
;

                            IN NS     augustiner.alcomat.com
                            IN NS     tubo.alcomat.com. 
; Dans ce fichier seul, le Nom de Domaine peut être éliminé.
(alcomat.com);
 des Serveurs de Noms, parce que named.hosts à la même origine!

;
; Adresses des hôtes
;

localhost                   IN A      127.0.0.1
mahou                       IN A      192.253.253.2
augustiner                  IN A      192.253.253.3
polar                       IN A      192.253.253.4
whisky                      IN A      192.249.249.2
brandy                      IN A      192.249.249.3
vodka                       IN A      192.249.249.4

tubo                        IN A      192.253.253.1
                            IN A      192.249.249.1

;
; hôtes avec adresses multiples
;

tub249                      IN A      192.249.249.1
tub253                      IN A      192.253.253.1

;
; Alias
;

edel                        IN CNAME  augustiner
pol                         IN CNAME  polar
tu                          IN CNAME  tubo
 

(5.5) La bibliothèque de résolution (Resolve)  

La contre-partie du Serveur de Noms est la bibliothèque de Résolution, constituée d'un ensemble de fonctions de la bibliothèque "C" standard sous Linux. Les routines les plus importantes sont: 

  • gethostbyname, qui renvoie toutes les adresses IP d'un hôte et 
  • gethostbyaddr, qui renvoie le nom primaire de l'hôte ayant l'adresse IP donnée.
Le fichier le plus important est host.conf, qui contrôle la bibliothèque de résolution (encore appelée résolveur). Il se situe dans le répertire /etc et détermine en particulier quels sont les services requis par le résolveur, et dans quels ordres ces services seront demandés. 
Pour notre domaine fictif, nous utiliserons seulement deux options: order et multi
  • Order détermine l'ordre des services consultés 
  • Multi signale qu'un hôte peut disposer de plusieurs adresses (fait uniquement référence au fichier /etc/hosts. Les arguments possibles sont on et off.
Dans l'exemple suivant, le fichier /etc/hosts indique au résolveur d'utiliser d'abord DNS, puis ensuite le fichier /etc/hosts. 
 
/etc/host.conf
# /etc/host.conf
# Utilisation de named puis la table d'hôtes:/etc/hosts
order   bind hosts
# Autorisation d'adresses multiples (uniquement pour /etc/hosts)
multi   on
 

Puisque notre résolveur utilise DNS, nous devons lui indiquer quel Serveur de Noms consulter. Le fichier resolv.conf offre cette fonctionnalité. 
L'option la plus importante dans "resolv.conf" est nameserver, qui indique les Serveurs de Noms à consulter. Un maximum de trois Serveurs de Noms peut être indiqué. L'ordre de recherche correspondant à l'ordre dans le fichier, il est conseillé d'indiquer prioritairement les Serveurs de Noms les plus fiables. 
Il existe deux options supplémentaires - domain et search - qui indique un nom de domaine automatiquement ajouté quand le résolveur ne trouve pas l'adresse. Cela signifie dans notre exemple que "ftp mahou" est automatiquement transformé en "ftp mahou.alcomat.com". Ainsi, on n'est pas obligé de taper le nom complet. Cette option ne permet de spécifier qu'un unique nom de domaine, alors que search en accepte plusieurs. L'inconvénient est alors que la recherche dans une liste de nom de domaine est plus longue. 
 
/etc/resolv.conf
# /etc/resolv.conf
# Domaine Alcomato Distribution
domain       alcomat.com
#
# Le Serveur de Noms
# Si nécessaire, ajouter l'adresse de votre fournisseur 
# d'accès Internet
nameserver   192.253.253.1
 

(5.6) Tests avec nslookup 

Avant d'utiliser l'utilitaire "nslookup", qui utilise BIND, nous allons vérifier que "syslog" n'indique aucune erreur. Si vous avez configuré le démarrage afin que "named" démarre automatiquement avec le système, et qu'un message de "named" apparaît, il est actif. Si vous préférez démarrer "named" manuellement, lancez la commande suivante (seul "root" peut le faire): 

# /etc/named -b /etc/named.boot 

  • La commande:

  • # grep daemon /etc/syslog.conf  

    doit renvoyer une ligne équivalente à 
    *.err;kern.debug;daemon,auth.notice /var/adm/messages or /var/log/messages 
    cela indique, selon votre distribution Linux que les messages de syslog se trouvent en /var/adm/messages ou /var/log/messages file. 

  • Avec la commande

  • # grep named /var/adm/messages (ou /var/log/messages) 

    un message équivalent au suivant devrait apparaître, par exemple 
    Feb 12 21:16:48 tubo named [3221]: starting (or restarted)

Si une erreur survient, le message correspondant apparaît, par exemple 
Feb 12 21:16:48 tubo named [3221]: named hosts Line 15: database format error (192.249.249.3), indiquant le fichier concerné, et les lignes responsables de l'erreur. 

Après correction de l'erreur, la commande: 
# kill -HUP 'cat /etc/named.pid' 
permettra de relire les fichiers de base de données. 

 

Tests avec nslookup 

L'utilitaire "nslookup" donne accès à tout enregistrement de n'importe quel Serveur de Noms. Nous nous limiterons ici à quelques tests élémentaires. 

Recherches locales: 

  • Recherche d'un hôte local par son nom:
  • # nslookup vodka 
    Server: tubo.alcomat.com 
    Address: 192.253.253.1 

    Name: vodka.alcomat.com 
    Address: 192.245.245.4

 
  • Recherche d'un hôte local par son adresse:
  • # nslookup 192.245.245.2 
    Server: tubo.alcomat.com 
    Address: 192.253.253.1 

    Name: whisky.alcomat.com 
    Address; 192.245.245.2

 Si les deux tests précédents fonctionnent comme indiqué, votre Serveur de Noms est correctement installé pour votre domaine. 

Recherche d'hôtes distants: 
Si votre réseau dispose d'un accès à Internet, il est recommandé d'utiliser "nslookup" pour rechercher un hôte distant. 

  • Recherche d'un hôte distant par son nom:
  • # nslookup ftp.uu.net 
    Server: tubo.alcomat.com 
    Address: 192.253.253.1 

    Name: ftp.uu.net 
    Address: 192.48.96.9

 
  • Recherche d'un hôte distant par son adresse:
  • # nslookup 192.48.96.9 
    Server: tubo.alcomat.com 
    Address: 192.253.253.1 

    Name: ftp.uu.net 
    Address: 192.48.96.9

 Ces nouveaux tests, s'ils sont concluants,indique que votre Serveur de Noms peut contacter les Serveurs de Noms racine (fichier: named.cache) et obtenir de leur part les informations sur les hôtes distants. 

Traduit par Jean-Denis Girard
 
Pour plus de renseignements
  • Administration de réseaux TCP/IP: Craig Hunt; O´Reilley; 1992 
  • DNS et BIND: Paul Albitz & Cricket Liu; O´Reilley; 1997 
  • Le Guide LINUX de l'Administrateur Réseau: Olaf Kirch; O´Reilley; 1995
  • Web Project: Jon Udell, BYTE, Décembre 1997
© 1998 Andreas J Gundacker 
Ce site web est maintenu par Miguel A Sepulveda