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 :
$ORIGIN example.com.
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 :
<host> IN A <IP-address>
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 :
IN NS <nameserver-name>
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.