Red Hat Enterprise Linux 3: Guide de référence | ||
---|---|---|
Précédent | Chapitre 12. Berkeley Internet Name Domain (BIND) | Suivant |
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 desenregistrements 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 noms à une zone.
Toutes les directives et enregistrements de ressources doivent se situer sur leur propre ligne.
Des commentaires peuvent être placés dans les fichiers de zone après les caractères points-virgules (;).
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. Cela permet de stocker des configurations de zone supplémentaires à l'écart du fichier de zone principal.
$ORIGIN — attache le nom de domaine à tout enregistrement non-qualifié, comme ceux qui spécifient seulement l'hôte et rien de plus.
Un fichier de zone peut par exemple, contenir la ligne suivante :
$ORIGIN example.com |
Tout nom utilisé dans les enregistrements de ressources et ne finissant pas par un point (.) se verront ajouter le nom de domaine 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 les enregistrements de ressources de la zone resteront valides. Chaque enregistrement de ressources peut contenir sa propre valeur TTL, qui remplace alors cette directive.
En accroissant cette valeur, les serveurs de noms distants peuvent mettre en cache ces informations de zone pendant plus longtemps. Cela réduit le nombre de requêtes effectuées au sujet de cette zone, mais rallonge également le temps nécessaire pour la prolifération des changements des enregistrements de ressources.
Les enregistrements de ressources représentent le premier composant d'un fichier de zone.
Il existe de nombreux types différents d'enregistrements de ressources de 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 le haut de l'espace de nom. Ce système est la cible de toutes les requêtes non-FQDN.
Examinons les exemples d'enregistrement 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 orienté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 pus connu sous le nom d'enregistrement d'alias.
L'exemple suivant indique à named que toute requête envoyée au <alias-name> devrait alors être orientée vers l'hôte, <real-name>. Les enregistrements CNAME sont généralement utilisés pour orienter 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 fixe un nom d'hôte à une adresse IP alors qu'un enregistrement CNAME y oriente le nom d'hôte www le fréquemment utilisé.
server1 IN A 10.0.1.5 www IN CNAME server1 |
MX — enregistrement Mail eXchange, qui indique où doit se diriger 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 mail pour un espace de nom, en donnant une préférence à certains systèmes de courrier sur d'autres. L'enregistrement de ressource MX doté de la <preference-value> la plus basse est préféré aux autres. Toutefois, de multiples serveurs de courrier peuvent avoir la même valeur pour distribuer de manière égale le trafic des courriers électroniques 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 courrier mail.example.com est préféré au serveur de courrier 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'option <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 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 orienter vers une autre partie de l'espace de nom.
Les enregistrements PTR servent essentiellement à la résolution inverse des noms, puisqu'ils réorientent les adresses IP vers un nom particulier. Consultez la Section 12.3.4 pour obtenir des exemples supplémentaires d'utilisations d'enregistrements PTR.
SOA — enregistrement de ressources "Start Of Authority", proclamant des informations importantes faisant autorité à propos d'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 indique 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 installé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 chaque fois que vous changez le 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 donc 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 placent en cache les informations pour cette zone pendant au moins cette durée de temps.
Lors de la configuration de BIND, toutes les durées sont exprimées en secondes. Toutefois, vous pouvez aussi utiliser des abréviations pour des unités de temps autres que des secondes, comme les minutes (M), heures (H), jours (D) et semaines (W). Le Tableau 12-1 montre une duré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 ressource 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 |
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 courrier configurés par les enregistrements MX orientent 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 standard ftp.example.com et www.example.com, sont orientés vers les serveurs appropriés en utilisant les enregistrements CNAME.
Un fichier de zone de résolution de nom inverse sert à traduire une adresse IP dans un espace de nom particulier en un FQDN. Il ressemble beaucoup à un fichier de zone standard, si ce n'est que les enregistrements de ressources PTR servent à lier les adresses IP au nom d'un domaine pleinement qualifié.
Un enregistrement PTR ressemble à ce qui suit :
<last-IP-digit> IN PTR <FQDN-of-system> |
Le <last-IP-digit> fait référence au dernier chiffre dans une adresse IP qui doit orienter 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 orientent 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 qui suit :
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, si ce n'est dans la manière de nommer l'hôte. Notez qu'une zone de résolution de noms inversée nécessite que les trois premiers blocs de l'adresse IP soient inversés, puis suivis de l'entité .in-addr.arpa. Ceci permet d'associer correctement à cette zone le bloc unique de nombres IP utilisé dans le fichier de zone de résolution de nom inversée.
Précédent | Sommaire | Suivant |
/etc/named.conf | Niveau supérieur | Utilisation de rndc |