DNS avec Bind9 - Configuration de Named

UN SERVEUR DE NOMS DE DOMAINES AVEC BIND 9

faire tourner bind

Named, comme tout daemon Linux, se doit d'être lancé au démarrage du serveur grâce à l'habituel init.d, et commence par lire son fichier de configuration, /etc/named.conf. Celui-ci est généré lors de l'installation ou du premier démarrage de Bind, avec des modalités variant selon les distributions. Pour la Mandrake 8.1, il s'agit d'un script Perl exécuté à l'installation ; pour la RedHat 7.2, il faut utiliser l'interface graphique bindconf. Voici à quoi ce fichier peut ressembler :

 
// generated by named-bootconf.pl 
 
 
// secret must be the same as in /etc/rndc.conf 
key "key" { 
        algorithm       hmac-md5; 
        secret 
"c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; 
}; 
 
controls { 
    inet 127.0.0.1 allow { any; } keys { "key"; }; 
}; 
 
 
options { 
	pid-file "/var/run/named/named.pid"; 
	directory "/var/named"; 
	/* 
	 * If there is a firewall between you and nameservers you want 
	 * to talk to, you might need to uncomment the query-source 
	 * directive below.  Previous versions of BIND always asked 
	 * questions using port 53, but BIND 8.1 uses an unprivileged 
	 * port by default. 
	 */ 
	// query-source address * port 53; 
	// les adresses des serveurs du FAI, pour les requetes externes 
	forward first; 
	forwarders {212.27.32.5; 212.27.32.6;}; 
}; 
 
//  
// a caching only nameserver config 
//  
zone "." { 
	type hint; 
	file "named.ca"; 
}; 
zone "0.0.127.in-addr.arpa" { 
	type master; 
	file "named.local"; 
}; 
//un fichier pour l'hote local 
zone "localhost" { 
	type master; 
	file "localhost"; 
}; 
 //DNS maître sur mondomicile.local 
zone "mondomicile.local" { 
     type master; 
    file "mondomicile.dns"; 
    forwarders{}; 
}; 
//resolution inverse de mondomicile.local 
zone "200.168.192.in-addr.arpa" { 
        type master; 
        file "mondomicile.inv"; 
        forwarders{}; 
};

Ça a l'air plutôt ardu ; essayons de décrypter un peu :

D'abord, les règles de syntaxe, qui paraissent d'ailleurs relativement évidentes si l'on étudie attentivement le fichier :

Les lignes débutant par // sont des commentaires ; les /* et */ du C, le # du bash sont également acceptés. Le ; en début de ligne est interdit.
Les autres lignes sont des règles de configuration, lesquelles se terminent toujours par un ;. Si une règle est imbriquée dans une autre, elle doit aussi se terminer par un ; et on doit alors utiliser les {}.
Ces règles comportent deux, et souvent trois parties :

D'abord, un mot-clé comme key, zone, acl ou include
Ensuite, si besoin est, le nom de la règle.
Et enfin, le contenu de celle-ci. Bien évidemment, le contenu change selon la catégorie.

Voyons d'ailleurs les principaux types de régles :

logging et options ne peuvent apparaître qu'une fois dans le fichier. logging permet de préciser une quantité quasi astronomique de paramètres pour les logs du daemon, et options un nombre encore plus impressionant d'options. La liste complète figure dans la page man named.conf.
Ici, on a ajouté deux lignes pour permettre la résolution des noms qui n'appartiennent pas au domaine que gère notre DNS, c'est à dire, pour faire court, la navigation sur Internet :
- le mot clé forwarders est suivi de la liste des adresses des serveurs de référence, ici ceux du fournisseur d'accès.
- forward first ordonne à named d'aller interroger d'abord ces serveurs-là, avant d'aller ennuyer les serveurs racine dont les adresses sont contenues dans le fichier named.ca
- et pour éviter de faire appel à ces serveurs externes pour résoudre des noms de notre réseau local, par exemple à la suite d'une erreur dans la saisie d'une adresse, on ajoute dans chaque zone une liste vide de serveurs de référence, avec forwarders{};
Le fichier présenté plus haut, fichier installé par Bind et à peine modifié, ne comporte que deux options : le répertoire où l'on trouvera l'identifiant de bind, et celui où seront conservés les fichiers de données propres à chaque zone, ici, et en général, /var/named.
key et controls déterminent des paramètres de sécurité nécessaires à l'administration du serveur au moyen de l'utilitaire ad hoc, rndc, lequel dispose, avec rndc.conf, de son propre fichier de configuration.
key définit une clé secrète à l'aide de deux arguments, algorithm, pour l'instant seulement hmac-md5, et secret ; cette clé sera comparée à celle qui figure dans le fichier rndc.conf et, étant secrète, il vaut mieux qu'elle ne soit pas accessible à tous. controls restreint l'accès physique à l'administration du serveur : ici, seul l'accès TCP/IP, alias inet à l'hôte local est autorisé, du moment qu'il possède la clé.

Jusqu'à présent, le serveur tourne et peut être administré, mais il ne sert à rien : l'information utile se trouve dans les définitions de zone.

Le contenu de chaque zone sera détaillé dans un fichier propre, ici placé dans le répertoire /var/named. named.conf ne contient que des paramètres généraux, à savoir :

Le type de zone, master pour celles qui sont placées sous l'autorité du serveur, slave pour celles dont il garde juste une copie, qui sera mise à jour en fonction des paramètres enregistrés dans le fichier de zone. Rien n'empêche un même serveur d'être maître sur une ou plusieurs zones, et esclave sur d'autres. hint est un type particulier de zone, celui des serveurs root, placés donc au sommet de l'arborescence du DNS. Leur nom est un simple ".", leur présence dans le fichier named.conf rigoureusement indispensable.
Le nom de la zone, entre " ", suit immédiatement le mot-clé zone. On constate qu'il n'est pas nécessairement identique au nom du fichier qui lui est associé, lequel est définit par le terme file. Par contre, le nom de la zone doit être identique à celui du domaine concerné.
Dans les zones master et slave, quelques options sont disponibles, que l'on retrouva dans le paramètre options.

gérer un serveur secondaire

Et si l'on est suffisamment riche pour entretenir un second serveur, rien de plus simple que de le transformer en esclave. Voici à quoi ressemblera named.conf, cette fois-ci sur une RedHat 7.2 :

 
## named.conf - configuration for bind 
# 
# Generated automatically by bindconf, alchemist et al. 
controls { 
        inet 127.0.0.1 allow { localhost; } keys { rndckey; }; 
}; 
  
include "/etc/rndc.key"; 
 
options {  
	directory "/var/named/"; 	 
}; 
 
 
 
zone "mondomicile.local" {  
	type slave;  
	file "mondomicile.slv"; 
	masters {  
		 192.168.200.20; 
		};  
}; 
zone "200.168.192.in-addr.arpa" {  
	type slave;  
	file "200.168.192.in-addr.arpa.slv"; 
	masters {  
		 192.168.200.20; 
		};  
};

Il nous suffit donc de :

attribuer le type slave aux zones déjà définies dans le serveur maître.
donner l'adresse IP du serveur maître sur la ligne masters, en respectant les ; et autres {} voulus par la syntaxe.
prévoir par commodité un nom différent pour le fichier de zone conservé dans le même répertoire /var/named du serveur esclave.

Et c'est tout : au démarrage, le serveur secondaire interrogera le serveur primaire, récupèrera les fichiers spécifiés dans named.conf et les écrira dans son répertoire /var/named. On peut vérifier tout ça grâce aux messages du serveur primaire :

 
Jan 10 16:38:23 superathlon named[1317]: client 192.168.200.21#32770:
 transfer of 'mondomicile./IN': AXFR started 
Jan 10 16:38:23 superathlon named[1317]: client 192.168.200.21#32770:
 transfer of '200.168.192.in-addr.arpa/IN':  
AXFR started

Un dernier contrôle dans /var/named : les fichiers .slv sont bien là.

contrôler le daemon

Le serveur peut donc être contrôlé avec un utilitaire en ligne de commande, rndc. Celui-ci supporte notamment les commandes suivantes :

stop permet d'arrêter gentiment le serveur ; les amateurs de la manière forte utiliseront plutôt halt.
reload permettra de relire la configuration et de recharger toutes les zones, alors que reconfig relit la configuration et charge seulement les nouvelles zones, sans s'occuper des anciennes. Sur de gros serveurs, la seconde possibilité est évidemment plus rapide.
flush permet de vider les adresses mises en cache dans le serveur.

status, enfin, affiche des informations du type de celles-ci :

 
number of zones: 5 
debug level: 0 
xfers running: 0 
xfers deferred: 0 
soa queries in progress: 0 
query logging is OFF 
server is up and running

A priori, tout va bien.

notons que rndc est incapable de démarrer named, et ne marchera pas si le daemon n'est pas déjà lancé : si tel est le cas, il faudra donc le démarrer avec, par exemple, un classique, sur les Mandrake et RedHat, /etc/rc.d/init.d/named start .

rndc, qui remplace l'ancien ndc, est une des nouveautés de la version 9 de Bind : en cours de développement, la liste de ses commandes change avec chaque nouvelle version du daemon.
Le fichier de configuration de rndc, /etc/rndc.conf, doit obligatoirement contenir la même clé secrète que named.conf, faute de quoi l'accès au serveur sera impossible.
Enfin, deux autres commandes accomplissent des tâches subalternes : named-checkconf vérifie la syntaxe du fichier named.conf, et named-checkzone avec comme option le nom de la zone et le chemin du fichier de zone, valide la syntaxe de ce dernier : named-checkzone mondomicile.local /var/named/ mondomicile.dns fournit un résultat de ce type :

 
 
	dns_rdata_fromtext: /var/named/mondomicile.dns:8: near '@': extra input text
 
	zone mondomicile.local/IN: loading master file /var/named/mondomicile.dns: extra input text

Ah finalement, tout ne va pas si bien. Ça n'a pas l'air trop grave, le serveur marche quand même. Reste à le nourrir de quelques noms et adresses.