12.3. Fichiers de zone
Les Fichiers de zone contiennent des informations sur un espace de nom particulier et sont stock�s dans le r�pertoire de travail named qui est par d�faut /var/named/. Chaque fichier de zone est nomm� selon les donn�es d'options de file dans la d�claration zone, et ce, g�n�ralement d'une mani�re qui se r�f�re au domaine en question et identifie le fichier comme contenant des donn�es de zone, telles que example.com.zone.
Chaque fichier de zone peut contenir des directives et des enregistrements de ressources. Les directives donnent au serveur de noms l'instruction d'effectuer une certaine t�che ou d'appliquer des param�tres sp�ciaux � la zone. Les enregistrements de ressources d�finissent les param�tres de la zone, assignant des identit�s aux h�tes individuels. Les directives sont facultatives, mais les enregistrements de ressources sont requis pour fournir un service de nom � une zone.
Toutes les directives et enregistrements de ressources doivent �tre sp�cifi�es sur des lignes individuelles.
Des commentaires peuvent �tre plac�s dans les fichiers de zone apr�s les caract�res points-virgules (;).
12.3.1. Directives des fichiers de zone
Les directives sont identifi�es par le symbole dollar ($) suivit du nom de la directive. Elles apparaissent g�n�ralement en haut du fichier de zone.
Les directives les plus couramment utilis�es sont les suivantes�:
$INCLUDE — Configure named de fa�on � ce qu'il inclue un autre fichier de zone dans ce fichier de zone � l'endroit o� la directive appara�t. Ce faisant, il est possible de stocker des configurations de zone suppl�mentaires � l'�cart du fichier de zone principal.
$ORIGIN — Attache le nom de domaine � des enregistrements non-qualifi�s, comme ceux qui sp�cifient seulement l'h�te et rien de plus.
Par exemple, un fichier de zone peut contenir la ligne suivante�:
Tous les noms utilis�s dans les enregistrement de ressources qui ne se terminent pas par un point (.) se verront ajouter example.com .
 | Remarque |
|---|
| | L'utilisation de la directive $ORIGIN n'est pas n�cessaire si l'on nomme la zone dans /etc/named.conf parce que le nom de la zone est utilis� par d�faut, comme la valeur de la directive $ORIGIN |
$TTL — R�gle la valeur par d�faut de Time to Live (TTL) (ou temps de vie) pour la zone. Cette valeur exprim�e en secondes, correspond � la dur�e pendant laquelle un enregistrement de ressources de zone est valide. Chaque enregistrement de ressources peut contenir sa propre valeur TTL, qui remplace alors cette directive.
L'aumentation de cette valeur permet aux serveurs de noms distants de mettre en cache ces informations de zone pendant plus longtemps, r�duisant ainsi nombre de requ�tes effectu�es au sujet de cette zone et rallongeant le temps n�cessaire pour la prolif�ration des changements apport�s aux enregistrements de ressources.
12.3.2. Enregistrements de ressources des fichiers de zone
Les enregistrements de ressources repr�sentent le premier composant d'un fichier de zone.
Il existe de nombreux types d'enregistrements de ressources des fichiers de zone. Ceux �num�r�s ci-dessous sont n�anmoins les plus fr�quemment utilis�s�:
A — Enregistrement d'adresse qui sp�cifie une adresse IP � assigner � un nom, comme dans l'exemple ci-dessous�:
Si la valeur <host> est omise, alors un enregistrement A renvoie � une adresse IP par d�faut pour la partie sup�rieure de l'espace de nom. Ce syst�me est la cible de toutes les requ�tes non-FQDN.
Examinons les exemples d'enregistrements A suivants pour le fichier de zone example.com�:
IN A 10.0.1.3
server1 IN A 10.0.1.5 |
Les requ�tes pour example.com sont dirig�es vers 10.0.1.3, alors que les requ�tes pour server1.example.com sont orient�es vers 10.0.1.5.
CNAME — Enregistrement de nom canonique mappant un nom � un autre. Ce type d'enregistrement est plus connu sous le nom d'enregistrement d'alias.
L'exemple suivant indique � named que toute requ�te envoy�e � <alias-name> devrait �tre dirig�e vers l'h�te, <real-name>. Les enregistrements CNAME sont g�n�ralement utilis�s pour pointer vers les services qui utilisent un proc�d� commun de nommage, comme par exemple, www pour les serveurs Web.
<alias-name> IN CNAME <real-name> |
Dans l'exemple suivant, un enregistrement A lie un nom d'h�te � une adresse IP alors qu'un enregistrement CNAME pointe le nom d'h�te www le fr�quemment utilis� vers l'adresse.
server1 IN A 10.0.1.5
www IN CNAME server1 |
MX — Enregistrement Mail eXchange, qui indique o� devrait aller le courrier envoy� � un nom d'espace particulier contr�l� par cette zone.
IN MX <preference-value> <email-server-name> |
Dans cet exemple, <preference-value> permet de classer num�riquement les serveurs de messagerie pour un espace de nom, en donnant une pr�f�rence � certains syst�mes de messagerie par rapport � d'autres. L'enregistrement de ressources MX dot� de la valeur <preference-value> la plus basse est pr�f�r� aux autres. Toutefois, de multiples serveurs de messagerie peuvent avoir la m�me valeur pour distribuer uniform�ment le trafic d'emails entre eux.
L'option <email-server-name> peut �tre un nom d'h�te ou un FQDN.
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com. |
Dans cet exemple, le premier serveur de messagerie mail.example.com est pr�f�r� au serveur de messagerie mail2.example.com lors de la r�ception des courriers �lectroniques destin�s au domaine example.com.
NS — Enregistrement de serveur de noms (NameServer) annon�ant les serveurs de noms faisant autorit� pour une zone particuli�re.
Ci-dessous figure un exemple d'enregistrement NS�:
L'�l�ment <nameserver-name> devrait correspondre � un FQDN.
Ensuite, deux serveurs de noms sont r�pertori�s comme faisant autorit� pour le domaine. Le fait que ces serveurs de noms soient esclaves ou que l'un d'eux soit ma�tre n'a pas d'importance�; ils sont tous les deux consid�r�s comme faisant autoris�.
IN NS dns1.example.com.
IN NS dns2.example.com. |
PTR — Enregistrement PoinTeR, con�u pour pointer vers une autre partie de l'espace de nom.
Les enregistrements PTR servent essentiellement � la r�solution inverse des noms, puisqu'ils renvoient les adresses IP vers un nom particulier. Consultez la Section 12.3.4 pour obtenir des exemples suppl�mentaires d'utilisation des enregistrements PTR.
SOA — Enregistrement de ressources Start Of Authority, proclame des informations importantes faisant autorit� sur un espace de nom pour le serveur de noms.
Situ� apr�s les directives, un enregistrement de ressources SOA est le premier enregistrement de ressources dans un fichier de zone.
L'exemple qui suit montre la structure de base d'un enregistrement de ressources SOA�:
@ IN SOA <primary-name-server> <hostmaster-email> (
<serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> ) |
Le symbole @ place la directive $ORIGIN (ou le nom de zone, si la directive $ORIGIN n'est pas d�termin�e) en tant qu'espace de nom d�fini par le pr�sent enregistrement de ressources SOA. Le nom d'h�te du serveur de noms primaire faisant autorit� pour ce domaine est utilis� pour le <primary-name-server> et l'adresse �lectronique de la personne � contacter � propos de cet espace de nom est remplac�e par <hostmaster-email>.
La directive <serial-number> est incr�ment�e lors de chaque modification du fichier de zone afin que named sache qu'il doit recharger cette zone. La valeur <time-to-refresh> indique � tout serveur esclave combien de temps il doit attendre avant de demander au serveur de noms ma�tre si des changements ont �t� effectu�s dans la zone. La valeur <serial-number> est utilis�e par le serveur esclave pour d�terminer s'il est en train d'utiliser des donn�es de zone p�rim�es et doit par cons�quent les rafra�chir.
La valeur <time-to-retry> pr�cise au serveur de noms esclave l'intervalle pendant lequel il doit attendre avant d'�mettre une autre requ�te de rafra�chissement, au cas o� le serveur de noms ma�tre ne r�pondrait pas. Si le serveur ma�tre n'a pas r�pondu � une requ�te de rafra�chissement avant que la dur�e indiqu�e dans <time-to-expire> ne se soit �coul�e, le serveur esclave cesse de r�pondre en tant qu'autorit� pour les requ�tes au sujet de cet espace de nom.
La valeur <minimum-TTL> demande que d'autres serveurs de noms mettent en cache les informations pour cette zone pendant au moins cette dur�e d�finie.
Lors de la configuration de BIND, toutes les dur�es sont exprim�es en secondes. Toutefois, il est �galemnt possible d'utiliser des abr�viations pour des unit�s de temps autres que des secondes, comme les minutes (M), les heures (H), les jours (D) et les semaines (W). Le Tableau 12-1 montre une dur�e exprim�e en secondes et la p�riode �quivalente dans un autre format.
| Secondes | Autres unit�s de temps |
|---|
| 60 | 1M |
| 1800 | 30M |
| 3600 | 1H |
| 10800 | 3H |
| 21600 | 6H |
| 43200 | 12H |
| 86400 | 1D |
| 259200 | 3D |
| 604800 | 1W |
| 31536000 | 365D |
Tableau 12-1. Les secondes compar�es � d'autres unit�s de temps
L'exemple suivant montre ce � quoi l'enregistrement d'une ressources SOA peut ressembler lorsqu'il est configur� avec des valeurs r�elles.
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day |
12.3.3. Exemples de fichiers de zone
Si on les observe individuellement, les directives et enregistrements de ressources peuvent �tre difficiles � comprendre. Cependant, tout devient beaucoup plus simple lorsqu'on peut les observer ensemble dans un seul fichier commun.
L'exemple suivant illustre un fichier de zone tr�s �l�mentaire.
$ORIGIN example.com.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS dns1.example.com.
IN NS dns2.example.com.
IN MX 10 mail.example.com.
IN MX 20 mail2.example.com.
IN A 10.0.1.5
server1 IN A 10.0.1.5
server2 IN A 10.0.1.7
dns1 IN A 10.0.1.2
dns2 IN A 10.0.1.3
ftp IN CNAME server1
mail IN CNAME server1
mail2 IN CNAME server2
www IN CNAME server2 |
Dans cet exemple sont utilis�es des directives et des valeurs SOA standard. Les serveurs de noms faisant autorit� seront dns1.example.com et dns2.example.com, qui ont des enregistrements A les liant respectivement � 10.0.1.2 et � 10.0.1.3.
Les serveurs de messagerie configur�s par les enregistrements MX pointent vers les serveurs server1 et server2 au moyen des enregistrements CNAME. Puisque les noms des serveurs server1 et server2 ne finissent pas par un point (.), le domaine $ORIGIN est attach�, rallongeant le nom en server1.example.com et server2.example.com. Gr�ce aux enregistrements de ressources A associ�s, leurs adresses IP peuvent �tre d�termin�es.
Les services FTP et Web services, disponibles aux noms ftp.example.com et www.example.com standard, sont point�s vers les serveurs appropri�s en utilisant les enregistrements CNAME.
12.3.4. Fichiers de r�solution de noms inverse
Un fichier de zone de r�solution de nom inverse est utilis� pour traduire une adresse IP dans un espace de nom particulier en un FQDN. Il ressemble beaucoup � un fichier de zone standard, sauf que les enregistrements de ressources PTR servent � lier les adresses IP au nom d'un domaine pleinement qualifi�.
Un enregistrement PTR ressemble � l'extrait ci-dessous�:
<last-IP-digit> IN PTR <FQDN-of-system> |
L'�l�ment <last-IP-digit> fait r�f�rence au dernier chiffre d'une adresse IP qui pointe vers le FQDN d'un syst�me particulier.
Dans l'exemple suivant, les adresses IP allant de 10.0.1.20 � 10.0.1.25 pointent vers les FQDN correspondants.
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@ IN SOA dns1.example.com. hostmaster.example.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS dns1.example.com.
IN NS dns2.example.com.
20 IN PTR alice.example.com.
21 IN PTR betty.example.com.
22 IN PTR charlie.example.com.
23 IN PTR doug.example.com.
24 IN PTR ernest.example.com.
25 IN PTR fanny.example.com. |
Ce fichier de zone serait mis en service avec une d�claration zone dans le fichier named.conf similaire � l'extrait suivant�:
zone "1.0.10.in-addr.arpa" IN {
type master;
file "example.com.rr.zone";
allow-update { none; };
}; |
Il existe peu de diff�rences entre cet exemple et une d�claration zone standard, sauf pour ce qui est de la mani�re de nommer l'h�te. Notez qu'une zone de r�solution de noms inverse n�cessite que les trois premiers blocs de l'adresse IP soient invers�s, puis suivis de l'entit� .in-addr.arpa. Ce faisant, il est possible d'associer correctement � cette zone le bloc unique de nombres IP utilis� dans le fichier de zone de r�solution de nom inverse.
