Chapitre 12. Berkeley Internet Name Domain (BIND)
Sur la plupart des réseaux modernes, y compris l'Internet, les utilisateurs localisent les autres ordinateurs au moyen du nom. Ainsi les utilisateurs n'ont pas à se souvenir de l'adresse réseau numérique des ressources réseau. La manière la plus efficace de configurer un réseau afin de permettre des connexions à base de nom consiste à établir un Service de Nom de Domaine (ou DNS, de l'anglais Domain Name Service) ou un serveur de noms qui permet d'associer des noms d'hôte d'un réseau à des adresses numériques et vice-versa.
Ce chapitre examine le serveur de noms inclus dans Red Hat Enterprise Linux, le serveur DNS Berkeley Internet Name Domain (BIND), et met l'accent tout particulièrement sur la structure de ses fichiers de configuration et sur la manière de l'administrer aussi bien localement qu'à distance.
Pour obtenir des instructions sur la configuration de BIND à l'aide de l'application graphique Outil de configuration du service de noms de domaines (redhat-config-bind), reportez-vous au chapitre intitulé Configuration de BIND du Guide d'administration système de Red Hat Enterprise Linux.
 | Avertissement |
|---|---|
Si vous utilisez l'Outil de configuration du service de noms de domaines, ne modifiez manuellement aucun des fichiers de configuration de BIND car tous les changements seront annulés lors d'une utilisation postérieure de l'Outil de configuration du service de noms de domaines. |
12.1. Introduction au DNS
Lorsque les hôtes d'un réseau se connectent entre eux au moyen d'un nom d'hôte, auquel on fait réfèrence également sous le terme nom de domaine pleinement qualifié ou FQDN de l'anglais fully qualified domain name, le DNS est utilisé pour associer les noms des différents ordinateurs à l'adresse IP de l'hôte.
L'utilisation du DNS et du FQDN offre aux administrateurs système de nombreux avantages et leur permet, en outre, de changer facilement l'adresse IP d'un hôte sans avoir d'impact sur les requêtes basées sur le nom qui sont envoyées à cet ordinateur. Inversement, les administrateurs peuvent décider des machines qui traiteront une requête basée sur le nom.
Le service DNS est normalement mis en oeuvre grâce à des serveurs centralisés qui font autorité pour certains domaines et se réfèrent à d'autres serveurs DNS pour d'autres domaines.
Lorsqu'un hôte client demande des informations au serveur de noms, il se connecte généralement sur le port 53. Le serveur de noms tente alors de résoudre le FQDN d'après sa bibliothèque de solutions qui peut contenir des informations importantes sur l'hôte demandé ou des données mise en cache suite à une requête antérieure. Si le serveur de noms ne possède pas déjà la réponse dans sa bibliothèque de solutions, il se tourne vers d'autres serveurs de noms, appelés serveurs de noms root (ou serveurs de noms racines), afin de déterminer les serveurs de noms faisant autorité pour le FQDN en question. Grâce à ces informations, il effectuera ensuite une requête auprès des serveurs de noms faisant autorité pour déterminer l'adresse IP de l'hôte en question. S'il effectue une opération dans le sens inverse (reverse lookup), la même procédure qui est utilisée, si ce n'est que la requête est présentée avec une adresse IP inconnue au lieu d'un nom.
12.1.1. Zones de serveurs de noms
Sur Internet, le FQDN d'un hôte peut être structuré en sections. Celles-ci sont ensuite organisées hiérarchiquement, comme un arbre, avec un tronc principal, des branches primaires, des branches secondaires, et ainsi de suite. Prenons, par exemple, le FQDN suivant :
bob.sales.example.com |
Lors de l'analyse de la manière selon laquelle un FQDN trouve l'adresse IP qui renvoie à un système particulier, lisez le nom de droite à gauche, chaque niveau de la hiérarchie étant séparé par des points (.). Dans notre exemple, l'élément com définit le domaine de niveau supérieur pour ce FQDN. Le nom example est un sous-domaine de com alors que sales est un sous-domaine de example. Le nom le plus à gauche bob identifie le nom d'hôte d'une machine particulière.
À l'exception du nom de domaine, chaque section s'appelle une zone et définit un espace de nom particulier. Un espace de nom contrôle l'attribution des noms des sous-domaines à sa gauche. Alors que cet exemple ne contient que deux sous-domaines, un FQDN doit contenir au moins un sous-domaine mais peut en inclure beaucoup plus, selon l'organisation choisie pour l'espace de nom.
Les zones sont définies sur des serveurs de noms qui font autorité par l'intermédiaire de fichiers de zone, décrivant entre autres, l'espace de nom de cette zone, les serveurs de courrier qui doivent être utilisés pour un domaine ou sous-domaine particulier. Les fichiers de zone sont stockés sur des serveurs de noms primaires (aussi appelés serveurs de noms maîtres), qui font vraiment autorité et constituent l'endroit où des changements peuvent être apportés aux fichiers ; les serveurs de noms secondaires (aussi appelés serveurs de noms esclaves) quant à eux reçoivent leurs fichiers de zone des serveurs de noms primaires. Tout serveur de noms peut être simultanément maître ou esclave pour différentes zones et peut aussi être considéré comme faisant autorité pour de multiples zones. Tout cela dépend de la configuration du serveur de noms.
12.1.2. Types de serveurs de noms
Il existe quatre types de configuration possibles pour les serveurs de noms primaires :
maître — (master) Stocke les enregistrements de zone originaux faisant autorité pour un espace de nom particulier et répond aux questions d'autres serveurs de noms qui cherchent des réponses quant à cet espace de nom.
esclave — (slave) Répond aux requêtes d'autres serveurs de noms concernant les espaces de nom pour lesquels il est considéré comme faisant autorité. Les serveurs de noms esclaves reçoivent leurs informations d'espace de nom des serveurs de noms maîtres.
cache-seulement — (cacing-only) Offre des services de résolution de nom vers IP mais ne fait pas autorité pour quelque zone que ce soit. Les réponses pour toutes les résolutions sont placées en cache dans une base de données stockée en mémoire pour une période établie qui est spécifiée par l'enregistrement de zone importé.
retransmission — (forwarding) Fait suivre des requêtes de résolution à une liste spécifique de serveurs de noms. Si aucun des serveurs de noms spécifiés ne peut effectuer la résolution, le processus s'arrête et la résolution a échoué.
Un serveur de noms appartenir à un ou plusieurs de ces types. Par exemple, un serveur de noms peut être non seulement maître pour certaines zones, esclave pour d'autres mais il peut également offrir seulement la transmission d'une résolution pour d'autres zones.
12.1.3. BIND en tant que serveur de noms
Le serveur de noms BIND fournit ses services de résolution de noms à l'aide du démon /usr/sbin/named. BIND contient également un utilitaire d'administration appelé /usr/sbin/rndc. De plus amples informations sur rndc sont disponibles dans la Section 12.4.
BIND stocke ses fichiers de configuration aux emplacements suivants :
le fichier /etc/named.conf — Le fichier de configuration du démon named.
le répertoire /var/named/ — Le répertoire de travail de named qui stocke les fichiers de zone, de statistiques et les fichiers de cache.
Les sections suivantes examinent les fichiers de configuration de manière plus détaillée.