DNS avec Bind9 - Les fichiers de zones

UN SERVEUR DE NOMS DE DOMAINES AVEC BIND 9

créer les fichiers de zones

Il existe bien des manières d'écrire un tel fichier ; celle qui a été adoptée ici n'est pas nécessairement la plus concise, mais elle est homogène et à priori, aussi claire que possible.
On a vu, à la fin de named.conf, que l'on définissait cinq zones à l'aide de fichiers qui seront placés dans le répertoire /var/named. Deux de ces fichiers sont installés par défaut, named.ca et named.local. Comme l'indique le commentaire en tête de named.ca, celui-ci contient les adresses des serveurs racines, donc du sommet de l'arborescence des noms. Il doit théoriquement être régulièrement tenu à jour : celui qui est livré avec les plus récentes versions de Bind datant du mois d'août 1997, on peut penser que cette opération n'est pas souvent nécessaire. A l'opposé, named.local sert, lui, à la résolution inverse du nom localhost.
On a ajouté un fichier localhost qui sert seulement à la résolution de l'hôte local, et qui permet donc de trouver la classique adresse 127.0.0.1 : il est indispensable que cette information soit, d'une manière ou d'une autre, fournie au serveur.

 
$TTL 86400 
localhost.	SOA	superathlon.mondomicile.local.	root.mondomicile.local.( 
                                      2001122400 ; Numero 
                                      28800      ; Refresh 
                                      14400      ; Retry 
                                      3600000    ; Expire 
                                      86400 )    ; Minimum 
localhost.	NS	superathlon.mondomicile.local. 
localhost.	A	127.0.0.1

Restent donc les deux fichiers créés pour notre DNS. Le nombre est pair, c'est normal : le second fichier assure la résolution inverse du nom, c'est à dire à la recherche d'un nom associé à une adresse IP connue. Le concept est un petit peu compliqué, on y reviendra donc en détail plus loin. Et le premier, arbitrairement nommé mondomicile.dns, contient toute les données nécessaires au bon fonctionnement de la zone. On connaît donc ce type de fichier sous le nom de resource records, alias RR.

les données dans mondomicile.dns

Chaque enregistrement du fichier contient normalement cinq champs, séparés par un espace ; on verra pourquoi il existe quelques exceptions. Ces cinq champs sont :

d'abord, le nom du domaine.
ensuite, la durée de validité de l'enregistrement, alias Time To Live ou TTL.
la classe, c'est à dire le protocole utilisé ; aujourd'hui, seul subsiste IN pour Internet
puis le type d'information contenu dans l'enregistrement.
et enfin les données elle-mêmes ; en fonction du type de données, ce champ contiendra des informations de nature différente.

Le fichier utilisé a la syntaxe suivante :

 
$TTL 86400 
@		IN	SOA 	superathlon.mondomicile.local. root.mondomicile.local. ( 
                                      2001122303 ; Numero 
                                      28800      ; Refresh 
                                      14400      ; Retry 
                                      3600000    ; Expire 
                                      86400 )    ; Minimum 
 
			NS	superathlon.mondomicile.local. 
superathlon		A 	192.168.200.20 
superathlon		HINFO "AMD Athlon 1Ghz" "Linux Mandrake 8.1"  
 
 
 
www		CNAME	superathlon 
imap		CNAME	superathlon 
pop		CNAME	superathlon 
smtp		CNAME	superathlon 
ftp		CNAME	superathlon 
moregroup	CNAME	superathlon 
nuke		CNAME	superathlon 
myadmin		CNAME	superathlon 
midgard		CNAME	superathlon 
mensaidf	CNAME	superathlon 
 
bravek6		A	192.168.200.21 
486pourri	A	192.168.200.22 
alien		A	192.168.200.19 
alien		TXT	"Alien Computer - ordinateur invite"

On se souvient que notre serveur de noms est maître sur la zone mondomicile.local, ce pourquoi il a été défini avec le type master dans named.conf. Notre fichier de zone doit donc commencer par un enregistrement dit SOA pour start or autority, qui définira le nom du serveur, l'adresse électronique de l'administrateur, et quelques paramètres. Pourtant, le fichier commence par :

$TTL 86400

Qu'est-ce que ça fait là ? Bind nous permet de définir un nombre très limité de variables, qui seront placées au début du fichier et établiront des valeurs par défaut pour les enregistrements. Il s'agit de :

$TTL, permet de définir, en secondes et dans un intervalle qui va de 0 à 2147483647, soit, si je ne me trompe pas dans mes calculs, près d'une dizaine d'années, le délai maximum pendant lequel un enregistrement pourra être gardé en cache. Avec 86400, le cache sera vidé, et les fichiers relus, toutes les 24 heures.
$ORIGIN déclare un nom de domaine à ajouter pour reconstituer le nom pleinement qualifié. Si mon serveur est maître sur la zone upaca, sous-domaine de ac-porquerolles.fr, ce dernier pourra être définit par la directive $ORIGIN.
$INCLUDE permet d'indiquer le chemin d'accès d'un fichier à utiliser ; après le chemin, on peut indiquer un nom de domaine différent de celui qui a été défini par $ORIGIN. On comprend que ces deux directives servent essentiellement à la gestion de domaines et sous-domaines d'architecture complexe.

Passons donc à l'analyse de notre premier enregistrement, le SOA.

 
@	IN	SOA		superathlon.mondomicile.local. root.mondomicile.local.  ( 
                                      20010122303 ; Numero 
                                      28800      ; Refresh 
                                      14400      ; Retry 
                                      3600000    ; Expire 
                                      86400 )    ; Minimum

Cela semble d'abord un peu déroutant, mais les cinq champs dont nous parlions plus haut sont bien présents, et dans l'ordre prévu. Détaillons un peu :

le @ à peine visible au début de l'enregistrement est une manière simplifiée de définir la zone, ici mondomicile.local. Cette définition a été donnée dans le fichier named.conf
ensuite, le TTL. Comme elle ne diffère pas de celle qui a été définie dans $TTL, il est inutile de spécifier une valeur.
puis apparaît la classe, IN. On pourra parfaitement, dans la suite du fichier, se dispenser de la préciser.
après, le type d'information. Sur un serveur maître, il existe nécessairement un et un seul enregistrement SOA, et c'est toujours le premier du fichier de zone.
pour finir, les données. En l'espèce, elles sont particulièrement fournies puisqu'on trouve :

superathlon.mondomicile.local., le nom pleinement qualifié du serveur de nom. On ne manquera pas de noter le . si discret à droite du fr et caractéristique de ces noms absolus. Il permet à Bind de remonter au sommet de l'arborescence des noms.
root.mondomicile.local. est la manière particulière dont Bind prend en compte l'adresse électronique de l'administrateur du serveur, avec un . à la place de l'@.
ensuite, entre (), un certain nombre de paramètres suivis de commentaires introduits par un ;, à savoir :

d'abord un numéro de série que l'on ne doit pas oublier d'incrémenter à chaque modification du fichier. Ce numéro permet aux serveurs esclaves de savoir s'il y a du nouveau, et de modifier le contenu de leurs bases en conséquence. Il est d'usage de choisir un numéro du type yyyymmdd, suivi d'un numéro d'ordre, mais cela n'est nullement obligatoire, l'important étant que ces numéros soient toujours croissants.
Refresh, Retry, et Expire sont des délais, exprimés en secondes, qui vont piloter le comportement des serveurs esclaves. A l'expiration du délai refresh, l'esclave va entrer en contact avec le maître ; s'il ne le trouve pas, il essaiera de nouveau à la fin du délai retry. Et si, au bout du délai expire, il n'est pas parvenu à ses fins, il considérera que le serveur maître a été retiré du service. minimum, enfin, détermine, toujours en secondes, la durée de vie minimum du cache. On remarque la disposition des parenthèses, obligatoire pour disposer les informations sur plusieurs lignes.

Passons à la suite, à savoir la résolution du nom du serveur lui-même :

 
			NS	superathlon.mondomicile.local. 
superathlon		A 	192.168.200.20 
superathlon		HINFO	"AMD Athlon 1Ghz" "Linux Mandrake 8.1"

Nous voyons apparaître trois nouveaux types d'enregistrements : NS, A et HINFO. NS désigne naturellement un serveur de noms, et A une adresse IP classique. Pour que l'on puisse trouver notre serveur, et qu'il arrive à se trouver lui-même, deux lignes sont nécessaires :

Sur la première, on déclare superathlon.mondomicile.local comme étant un serveur de noms.
Sur la seconde, le nom superathlon est associé à une adresse IP, 192.168.200.20. Généralement, les serveurs tournant sur une machine ne servant qu'à ça s'appellent ns, lequel ns est aussi arbitraire et traditionnel que le www des serveurs web.
Pour finir, on a créé un enregistrement HINFO, lequel doit contenir obligatoirement deux informations entre "" : le type de machine, et le système d'exploitation.

Sur notre petit réseau ne figure qu'un seul serveur de noms. En principe, c'est très mal, et on peut donc entrer les adresses d'autres serveurs, chacun sur leur ligne. On constate d'autre part que le @ en tête de ligne a disparu : dans la mesure où le domaine est toujours le même, il est déduit de l'enregistrement précédent. Le même principe s'applique à la classe, IN en l'occurrence : il suffit de la préciser une fois, dans l'enregistrement SOA. Nous trouvons enfin deux séries d'enregistrements :

 
www		CNAME	superathlon 
imap		CNAME	superathlon 
pop		CNAME	superathlon 
smtp		CNAME	superathlon 
ftp		CNAME	superathlon 
moregroup	CNAME	superathlon 
nuke		CNAME	superathlon 
myadmin		CNAME	superathlon 
midgard		CNAME	superathlon 
mensaidf	CNAME	superathlon 
 
bravek6		A	192.168.200.21 
486pourri	A	192.168.200.22 
alien		A	192.168.200.19 
alien		TXT	"Alien Computer - ordinateur invite"

On constate la présence d'un nouveau type d'enregistrement, CNAME : il s'agit d'un alias qui renverra vers le serveur réel. On en profite pour mettre là tout son bazar d'hôtes virtuels, tous hébergés par la même machine : Apache étant correctement configuré, en saisissant mensaidf.mondomicile.local dans la barre d'adresse de mon navigateur client, j'arriverai directement sur mon site. On retrouve enfin des adresses de type A, qui établissent la correspondance vers les autres ordinateurs du réseau, ceux que l'on a déjà vu dans le fichier hosts.
Pour finir, on a ajouté une ligne pour accueillir si besoin est une machine supplémentaire sur le réseau, un portable par exemple ; on a associé à celui-ci un enregistrement de type TXT, composé d'une simple description placée entre guillemets. Notons l'absence du é à invité : Bind ne comprend que l'ASCII.
Il existe une assez grande quantité d'autres possibilités, dont voici les principales :

A6 concerne les adresses conformes au nouveau futur bientôt sur nos micros protocole IPv6.
MX donne l'adresse d'un ou plusieurs relais pour l'acheminement du courrier électronique. Si plusieurs serveurs sont disponibles, il faut leur affecter un numéro de priorité, comme ceci :
```
 
upaca.ac-porquerolles.fr.	MX	0	smtp.upaca.ac-porquerolles.fr. 
				MX	1	zozo.upaca.ac-porquerolles.fr.	 
smtp.upaca.ac-porquerolles.fr.	A	129.165.18.13 
zozo.upaca.ac-porquerolles.fr.	A	135.118.99.3 
```
Comme sur notre réseau superathlon fait tout, ce type d'enregistrement n'est pas nécessaire.
Pour finir, PTR renvoie vers une autre branche de l'espace des noms. On en a besoin notamment pour la résolution inverse des noms.

la résolution inverse

Tout le travail effectué jusqu'à présent ne servait qu'à associer une adresse IP à un nom. Pour le bon fonctionnement du réseau, il est nécessaire que l'opération inverse - retrouver un nom à partir d'une adresse IP - soit possible : nombre de protocoles, HTTP et FTP pour n'en citer que deux, vérifient grâce à cette méthode, lors de la connexion d'un client, l'exactitude des informations d'identification qu'il a donné. On utilise pour cela une arborescence dont la racine n'est plus matériaisée par un simple point, mais par un nom : in-addr.arpa, et où les adresses IP sont consignées en sens inverse de l'ordre habituel.
Pour bien comprendre le mécanisme, il faut se rappeller que les points, dans un nom de domaine, sont des séparateurs hiérachiques : en parcourant le nom de gauche à droite, on va du plus petit au plus grand. Pour la résolution inverse, on lit des adresses IP, et on inverse l'ordre : 127.0.0.1 devient ainsi 1.0.0.127., adresse que l'on termine par le domaine conventionnel in-addr.arpa. On crée ainsi la zone "0.0.127.in-addr.arpa", qui, dans named.conf, renvoie au fichier named.local. On remarque que le nom de la zone ne reprend pas le dernier octet de l'adresse IP : celui-ci se retrouve dans le seul enregistrement de named.local :

 
1	IN	PTR	localhost.

Ces deux informations permettent à Bind de reconstituer l'adresse complète.

Le fichier mondomicile.inv comportera donc les enregistrements suivants :

 
$TTL 86400 
@	IN	SOA	superathlon.mondomicile.local.	root.mondomicile.local.  ( 
                                     		 2001121702 ; Serial 
                                    		 28800      ; Refresh 
                                    		 14400      ; Retry 
                                     		 3600000    ; Expire 
                                     		 86400 )    ; Minimum 
		NS	superathlon.mondomicile.local. 
 
20		PTR	superathlon.mondomicile.local. 
21		PTR 	bravek6.mondomicile.local. 
22		PTR 	486pourri.mondomicile.local. 
19		PTR 	alien.mondomicile.local.

Et c'est tout : la partie supérieure reprend exactement la déclaration SOA de mondomicile.dns, mais la zone à laquelle renvoie le @ est maintenant 200.168.192.in-addr.arpa., et les seuls enregistrements appropriés sont des pointeurs, alias PTR, auxquels sont associés les derniers octets des adresses des machines. Remarquons que rien n'interdit d'entrer des adresses complètes, 20.200.168.192.in-addr.arpa., de la même manière que l'on peut éventuellement entrer des noms pleinement qualifiés dans les enregistrements de type A. C'est plus long, plus sûr d'un certain point de vue, mais d'un autre côté on multiplie le risque de fautes de frappe. Et Bind fonctionne très bien sans. Le problème avec Bind, c'est d'ailleurs qu'il fonctionne presque toujours, du moment que named.conf ne comporte pas d'erreur de syntaxe, même quand il n'est pas en mesure de fournir les informations demandées : c'est pourquoi il ne faut pas hésiter à le torturer un peu.