20.5. Fichiers de zone

Deux types de fichiers de zone sont nécessaires. L'un assigne des adresses IP aux noms d'hôte et l'autre effectue l'inverse : il fournit un nom d'hôte à une adresse IP.

[Tip]utilisation du point dans les fichiers de zone

Le . a une signification importante dans les fichiers de zone. Si des noms d'hôte sont donnés sans . final, la zone est ajoutée. Ces noms d'hôte complets spécifiés avec un nom de domaine complet doivent se terminer par un . pour éviter que le domaine n'y soit ajouté une nouvelle fois. Un point manquant ou mal placé est probablement la cause la plus fréquente d'erreur de configuration des serveurs de noms.

Le premier cas à considérer est le fichier de zone world.zone, responsable du domaine world.cosmos, présenté dans l'Exemple 20.6, « Fichier /var/lib/named/world.zone ».

Exemple 20.6. Fichier /var/lib/named/world.zone

$TTL 2D
world.cosmos. IN SOA      gateway  root.world.cosmos. (
            2003072441  ; serial
            1D          ; refresh
            2H          ; retry
            1W          ; expiry
            2D )        ; minimum

            IN NS       gateway
            IN MX       10 sun

gateway     IN A        192.168.0.1
            IN A        192.168.1.1
sun         IN A        192.168.0.2
moon        IN A        192.168.0.3
earth       IN A        192.168.1.2
mars        IN A        192.168.1.3
www         IN CNAME    moon
Ligne 1 :

$TTL définit la durée de vie par défaut qui doit s'appliquer à toutes les entrées de ce fichier. Dans cet exemple, les entrées sont valide pendant une période de deux jours (2 D).

Ligne 2 :

L'enregistrement du contrôle SOA (start of authority) commence là :

  • Le nom du domaine à administrer est world.cosmos à la première position. Cela se termine par un ., car sinon la zone aurait été ajoutée une seconde fois. Il est également possible d'entrer @ ici, auquel cas la zone serait extraite de l'entrée correspondante dans /etc/named.conf.

  • Après IN SOA se trouve le nom du serveur de noms responsable en tant que maître de la zone. Le nom est développé de gateway à gateway.world.cosmos, car il ne se termine pas par un ..

  • Suit l'adresse de courrier électronique de la personne responsable de ce serveur de noms. Du fait que le signe @ possède déjà une signification spéciale, . est entré ici à sa place. Pour root@world.cosmos l'entrée doit indiquer root.world.cosmos.. Le . doit être inclus à la fin pour éviter l'ajout de la zone.

  • La ( inclut toutes les lignes jusqu'à ) dans l'enregistrement SOA.

Ligne 3 :

Le serial number est un nombre arbitraire qui augmente chaque fois que le fichier est modifié. Il est nécessaire pour informer les serveurs de noms secondaires (serveurs esclaves) des changements. Pour cela, un numéro à 10 chiffres de la date et du numéro d'exécution, écrit sous la forme AAAAMMJJNN, est devenu le format standard.

Ligne 4 :

Le refresh rate spécifie l'intervalle selon lequel les serveurs de noms secondaires vérifient le serial number de la zone. Dans le cas présent, un jour.

Ligne 5 :

Le retry rate spécifie l'intervalle selon lequel un serveur de noms secondaire, en cas d'erreur, tente de contacter le serveur primaire une nouvelle fois. Ici, l'intervalle est de deux heures.

Ligne 6 :

Le expiration time spécifie le délai au-delà duquel un serveur de noms secondaire abandonne les données cachées s'il n'a pas rétabli le contact avec le serveur primaire. Dans le cas présent, une semaine.

Ligne 7 :

La dernière entrée de l'enregistrement SOA spécifie le negative caching TTL : durée pendant laquelle les résultats des requêtes DNS non résolues à partir d'autres serveurs peuvent être mis en cache.

Ligne 9 :

Le IN NS spécifie le serveur de noms responsable de ce domaine. gateway est développé en gateway.world.cosmos car il ne se termine pas par un .. Il peut y avoir plusieurs lignes comme celle-ci : une pour le serveur de noms primaire et une pour chaque serveur de noms secondaire. Si notify est défini sur no dans /etc/named.conf, tous les serveurs de noms répertoriés ici sont informés des changements effectués dans les données de zone.

Ligne 10 :

L'enregistrement MX spécifie le serveur de messagerie qui accepte, traite et transfère les messages électroniques pour le domaine world.cosmos. Dans cet exemple, il s'agit de l'hôte sun.world.cosmos. Le nombre qui se trouve avant le nom de l'hôte est la valeur de préférence. En cas d'entrée MX multiples, le serveur de messagerie ayant la valeur la plus faible est pris le premier et, si la distribution des messages vers ce serveur échoue, une tentative est faite avec la valeur supérieure suivante.

Lignes 12–17 :

Il s'agit des enregistrements d'adresse dans lesquels une ou plusieurs adresses IP sont assignées aux noms d'hôte. Les noms sont répertoriés ici sans . car ils n'incluent pas leur domaine, de sorte que world.cosmos est ajouté à chacun d'entre eux. Deux adresses IP sont assignées à l'hôte gateway, car il possède deux cartes réseau. Chaque fois que l'adresse de l'hôte est classique (IPv4), l'enregistrement est marqué d'un A. Si l'adresse est de type IPv6, l'entrée est marqué de A6. Le jeton précédent pour les adresses IPv6 était AAAA, mais il est désormais obsolète.

[Note]syntaxe A6

L'enregistrement A6 a une syntaxe légèrement différente de AAAA. Du fait de la possible fragmentation, il est nécessaire de fournir des informations concernant les parties manquantes avant l'adresse. Vous devez fournir ces informations même si vous voulez utiliser une adresse complètement défragmentée. Pour l'ancien enregistrement AAAA avec la syntaxe

 pluto IN            AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
 pluto IN            AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

Vous devez ajouter ces informations concernant les parties manquantes au format A6. Du fait que l'exemple ci-dessus est complet (aucune partie manquante), le format A6 de cet enregistrement est le suivant :

 pluto  IN            AAAA 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
 pluto  IN            AAAA 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0

N'utilisez pas d'adresses IPv4 avec IPv6. Si un hôte a une adresse IPv4, il utilise un enregistrement A, et non A6.

Ligne 18 :

L'alias www peut être utilisé pour adresser mond (CNAME signifie nom canonique).

Le pseudo domaine in-addr.arpa est utilisé pour la recherche inverse d'adresses IP dans les noms d'hôte. Il est ajouté à la partie réseau de l'adresse en notation inverse. Ainsi 192.168.1 est résolu en 1.168.192.in-addr.arpa. Reportez-vous à l'Exemple 20.7, « Recherche inverse ».

Exemple 20.7. Recherche inverse

    

$TTL 2D
1.168.192.in-addr.arpa. IN SOA gateway.world.cosmos. root.world.cosmos. (
                        2003072441      ; serial
                        1D              ; refresh
                        2H              ; retry
                        1W              ; expiry
                        2D )            ; minimum

                        IN NS           gateway.world.cosmos.

1                       IN PTR          gateway.world.cosmos.
2                       IN PTR          earth.world.cosmos.
3                       IN PTR          mars.world.cosmos.
Ligne 1 :

$TTL définit le TTL standard qui s'applique ic à toutes les entrées.

Ligne 2 :

Le fichier de configuration doit activer la recherche inverse pour le réseau 192.168.1.0. Étant donné que la zone est nommée 1.168.192.in-addr.arpa, ne doit pas être ajouté aux noms d'hôte. Par conséquent, tous les noms d'hôte sont entrés sous leur forme complète : avec leur domaine et un . à la fin. Les entrées restantes correspondent à celles décrites dans l'exemple world.cosmos précédent.

Lignes 3–7 :

Reportez-vous à l'exemple world.cosmos précédent.

Ligne 9 :

Cette fois encore, cette ligne spécifie le serveur de noms responsable de cette zone. Cette fois-ci, en revanche, le nom est entré sous sa forme complète avec le domaine et un . à la fin.

Lignes 11–13 :

Il s'agit des enregistrements du pointeur signalant les adresses IP sur les hôtes respectifs. Seule la dernière partie de l'adresse IP est entrée au début de la ligne, sans . à la fin. L'ajout de la zone (sans .in-addr.arpa) se traduit par l'adresse IP complète à l'envers.

Normalement, les transferts de zone entre différentes versions de BIND doivent être possibles sans aucun problème.