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.
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�:
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.
