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. Ceci évite aux utilisateurs de devoir se rappeler 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.
Le présent 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 BIND car tout changement sera écrasé 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 se réfère également sous le terme nom de domaine pleinement qualifié ou 'fully qualified domain name' (FQDN), 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 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 encore 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), c'est 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 |
Lorsque vous regardez comment un FQDN trouve l'adresse IP qui renvoie à un système particulier, lisez le nom de droite à gauche avec chaque niveau de la hiérarchie divisé par des points (.). Dans notre exemple, le 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 de l'espace de nom choisie.
Les zones sont définies sur des serveurs de noms qui font autorité par l'intermédiaire ; 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 sont l'endroit où des changements peuvent être apportés aux fichiers ; les serveurs de noms primaires secondaires (ou 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 de serveurs de noms :
maître — Stocke les enregistrements de zone originaux faisant autorité pour un certain espace de nom et répond aux questions d'autres serveurs de noms qui cherchent des réponses concernant cet espace de nom.
esclave — 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 noms des serveurs de noms maîtres.
caching-only — Offre des services de résolution nom vers IP mais ne fait pas autorité dans n'importe quelle zone. 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 — Fait suivre des requêtes pour 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 peut être d'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 peut également offrir seulement la transmission d'une résolution pour d'autres encore.
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 dans les endroits 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ères plus détaillée.