Chapitre 14. Berkeley Internet Name Domain (BIND)

De nos jours, l'Internet et presque tous les réseaux locaux dépendent d'un Service de Nom de Domaine (Domain Name Service, DNS) efficace et fiable, qui est utilisé pour associer les noms de systèmes aux adresses IP et vice-versa.

Dans le but de faciliter le DNS sur votre réseau, un serveur de noms est nécessaire pour traduire ces noms en adresses IP nécessaires à leur connexion. De plus, un serveur de noms peut effectuer à rebours la traduction dans le nom du système, ce que l'on appelle souvent un reverse lookup, ou résolution inversée.

Le présent chapitre décrit BIND, la structure de ses fichiers de configuration et la façon dont il peut être administré localement ou à distance.

Vous trouverez les instructions de configuration de BIND à l'aide de l'outil BIND Configuration Tool avec interface graphique dans le Guide de personnalisation Red Hat Linux officiel. Si vous utilisez l'outil BIND Configuration Tool, pensez à ne pas éditer manuellement vos fichiers de configuration BIND car les changements manuels seront écrasés par l'outil BIND Configuration Tool.

Introduction au DNS et à BIND

Les systèmes utilisant les réseaux IP doivent connaître l'adresse IP d'un ordinateur distante afin de s'y connecter. Toutefois, la plupart des utilisateurs préfèrent utiliser des noms d'ordinateur, comme un nom d'hôte ou un fully qualified domain name (FQDN), pour spécifier un système au moment de la connexion. De plus, de nombreux programmes utilisent des noms de domaine dans leurs fichiers de configuration quand ils font référence à un système distant. Ils permettent ainsi de changer des adresses IP sans devoir modifier le nom du système (entre autres raisons). Le service qui rend cette opération plus facile est appelé DNS. Il est normalement mis en oeuvre par des serveurs centralisés qui font autorité pour quelques domaines, et se réfèrent à d'autres serveurs DNS pour les informations qu'ils ne possèdent pas encore.

Le DNS est rendu possible par l'utilisation de démons de serveurs de noms qui effectuent une traduction IP/nom. Une application client demande des informations au serveur de noms, en s'y connectant généralement sur le port de serveur 53. Le serveur de noms va tenter 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 cachées sur ce nom suite à une requête antérieure. Si le serveur de nom 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 root nameservers, ou serveurs de noms racines, afin de déterminer quels serveurs de noms font autorité pour le FQDN en question. Il effectuera ensuite une requête auprès des serveurs de noms qui font autorité pour déterminer l'adresse IP du nom. 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.

Zones

Sur Internet, le FQDN d'un hôte peut être structuré en sections qui sont ensuite organisées hiérarchiquement, comme un arbre avec un tronc principal, des branches primaires, des branches secondaires, etc. Prenons par exemple le FQDN suivant :

bill.sales.domain.com

Figure 14-1. Un exemple de FQDN (fully qualified domain name)

Lorsque vous regardez un FQDN pour trouver l'adresse IP qui concerne un système particulier, lisez le nom de droite à gauche, chaque niveau de la hiérarchie étant distingué par un point (.). Dans notre exemple, le com définit le domaine de niveau supérieur pour ce FQDN. Le nom de domain est un sous-domaine de com et sales un sous-domaine de domain. Le nom le plus à gauche dans un FQDN est le nom d'hôte, qui identifie une machine particulière.

A l'exception du nom de domaine, chaque section s'appelle zone, ce qui définit un espace de nom particulier (namespace). Un namespace, ou espace de nom, contrôle le nom des sous-domaines à sa gauche. 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 nom autorisé par l'intermédiaire; de fichiers de zone, qui décrivent l'espace de nom de cette zone, les serveurs de mail qui doivent être utilisés pour un domaine ou sous-domaine particulier, et bien plus encore. Les fichiers de zone sont stockés dans des serveurs de noms maîtres (qu'on appelle aussi des serveurs de noms primaires), sur lesquels les fichiers peuvent être modifiés, et des serveurs de noms esclaves (qu'on appelle aussi des serveurs de noms secondaires), qui reçoivent leurs fichiers de zone des serveurs de noms maîtres. 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.

Types de serveurs de noms

Il existe quatre types de configuration de serveurs de nom :

  • Maître — Stocke les enregistrements de zone originaux importants 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 aussi 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 par l'intermédiaire d'une zone de transfert,dans laquelle l'esclave envoie au maître une requête dite NOTIFY pour une certaine zone. Le maître répond en fournissant les informations, si l'esclave est autorisé à recevoir le transfert.

  • Caching-only — Offre des services de résolution nom vers IP mais ne fonctionne pas dans n'importe quelle zone. Les réponses pour toutes les résolutions sont en général placées en cache dans une base de données stockée en mémoire pour une période établie, le plus souvent spécifiée par l'enregistrement de zone importé, ce qui permet d'obtenir une résolution plus rapide pour d'autres clients DNS après la première résolution.

  • Forwarding — 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 plus de ces types. Par exemple, un serveur de noms peut être maître pour certaines zones, esclave pour d'autres, et n'offrir que la transmission d'une résolution.

BIND en tant que serveur de noms

Red Hat Linux contient BIND, est un serveur de noms Open Source puissant et très populaire. BIND utilise le démon named pour fournir ses services de résolution de noms. Toutes les informations de configuration pour BIND sont stockées dans le fichier /etc/named.conf et ses fichiers de zone se trouvent dans le dossier /var/named. La structure et les options de ces différents types de fichiers peut être consultée dans la la section intitulée Fichiers de configuration BIND.

La version 9 de BIND contient un utilitaire appelé rndc qui permet d'administrer le démon named en cours. Vous trouverez des informations supplémentaires concernant rndc dans la la section intitulée Utiliser rndc.