Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Guide de reference - Berkeley Internet Name Domain (BIND)

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.

AvertissementAvertissement
 

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire