Installation et configuration d'un serveur DNS sous Linux

• Serveur primaire: un serveur DNS est dit serveur primaire d'une zone, lorsqu'il lit directement les informations de cette zone à partir d'un fichier. Ce fichier est stocké sur la même machine que le serveur.
• Serveur secondaire: un serveur DNS est dit serveur secondaire d'une zone, lorsqu'il reçoit les informations sur cette zone à partir d'un serveur primaire. Il peut aussi avoir l'autorité sur la zone.

Dans le jargon technique, le serveur primaire est souvent désigné par maître et le serveur secondaire est qualifié d'esclave.

La configuration de serveur primaire et de serveurs secondaires pour une même zone présente plusieurs avantages. Il est même recommandé de mettre en œuvre un serveur primaire et plusieurs serveurs secondaires pour la gestion d'une même zone.
L'un des avantages majeurs que cela présente est la disponibilité continue des informations sur la zone même en cas de panne ou en cas de saturation du serveur primaire. Les connexions peuvent toujours être relayées vers les serveurs secondaires.

Le transfert de zones est d'une façon globale la procédure de mise à jour des serveurs secondaires. Il y a plusieurs types de transferts.
Quand un nouveau serveur secondaire est configuré, il fait une copie complète des fichiers de zone. Après cette étape, les mises à jour à effectuer peuvent être incrémentielles, c'est-à-dire que le serveur secondaire ne copie que les modifications effectuées.

La mise à jour du serveur secondaire est faite selon un délai défini dans la configuration. Mais il est possible que le serveur DNS alerte ses serveurs secondaires dès qu'il subit une modification. C'est le principe de notification. Il s'agit d'un mécanisme de diffusion permettant d'informer des serveurs secondaires, d'une modification effectuée dans le serveur primaire. Pour que cela puisse se faire, les adresses IP des serveurs secondaires à être notifiés sont enregistrées dans une liste de notifications.

Dans le chapitre I, la configuration présentée est celle d'un serveur primaire. Les paramètres de prise en charge des serveurs secondaires ne sont pas mentionnés. Le tableau ci-dessous les présente:

Exemple de configuration :
Au serveur précédent, on associe deux serveurs secondaires d'adresses IP 192.168.1.20 et 192.168.1.25.
Au contenu existant du fichier principal, on ajoute les lignes suivantes :

#Déclaration du fichier de résolution directe<br/>
zone "sigui.ci" in {<br/>
	type master ;<br/>
	allow-transfer { 192.168.1.20; 192.168.1.25 ;  };<br/>
	allow-notify {  192.168.1.20; 192.168.1.25 ; };<br/>
	notify yes ;<br/>
	file "/var/bind/sigui.ci.direct.db" ;<br/>
}<br/>

Et on reproduit les mêmes paramètres dans la déclaration du fichier de résolution inverse.

La configuration du serveur secondaire est analogue à celle du serveur primaire. Les différences sont au niveau du type et au niveau de la source de lecture des données. On a donc :

#Déclaration du fichier de résolution directe<br/>
zone "sigui.ci" in {<br/>
	type slave ;<br/>
	masters {192.168.1.10;};<br/>
	file "/var/bind/sigui.ci.direct.db" ;<br/>
	notify no ;<br/>
}<br/>

Cela traduit le fait que le serveur va chercher ces données sur la machine d'adresse IP 192.168.1.10, et dans le fichier spécifié. La même configuration est à faire avec le fichier de résolution inverse.

Dans un réseau, il peut arriver que les machines auxquelles on veut attribuer un nom ait leur adresse IP qui s'attribue dynamiquement, c'est-à-dire qu'elles ont des adresses changeantes et gérées par un serveur DHCP (Dynamic Host Control Protocol). Pour que l'on puisse toujours se connecter à une machine via son nom, il faudrait maintenir la correspondance entre ce nom et l'adresse changeante. Le service offre ce maintien est appelé DNS Dynamique.

Pour une machine sur internet dont le FAI attribue une adresse IP dynamiquement, l'administrateur de celle-ci peut recourir à des services (payants et gratuits) offerts par des entreprises. A chaque changement d'adresse IP, ces services diffusent des mises à jour sur le serveur DNS du domaine dans lequel se trouve la machine. Certains de ces services requièrent l'installation de logiciels clients sur la machine.

Un administrateur d'un réseau peut être dans le besoin de configurer un service DNS dynamique. Pour ce faire, il aura à installer en plus du serveur DNS, un serveur DHCP. C'est la conjugaison des deux configurations qui fournit le service de DNS dynamique. Une autre solution moins sécuritaire et pas recommandé, consiste à demander aux machines clientes de s'annoncer chez le serveur DNS une fois qu'elles auront reçu la modification de leur adresse.

Dans les points qui suivent, un cas pratique d'exemple sera étudié :

• la passerelle du réseau est à l'adresse 192.168.1.1
• le nom du domaine est sigui.ci
• l'adresse IP du serveur DNS est 192.168.1.10
• l'adresse IP du serveur DHCP est 192.168.1.5

* Généralités

DHCP ou Dynamic Host Control Protocol est un protocole qui permet de configurer (attribuer les adresses IP et fournir les adresses de la passerelle et du serveur DNS) les postes clients d'un réseau de façon automatique.
Le serveur DHCP dispose d'une plage d'adresses à distribuer aux machines du réseau. Lorsque l'attribution de l'adresse est faite, il établi un bail. Ce bail a une durée limitée dans le temps.

* Installation

Le paquet requis pour l'installation du serveur DHCP est dhcpd. Après installation, le fichier dhcpd.conf est crée, de même que le répertoire /var/lib/dhcp/. Ce répertoire contient le fichier dhcpd.leases qui est la base de données des informations d'attribution des adresses. Ces informations concernent le bail de l'attribution, le destinataire de l'attribution de l'adresse IP, et l'adresse MAC de la carte réseau du client. Le service DHCP ne fonctionne pas tant que la base de données d'attribution n'existe pas. Si elle n'a pas été créée pendant l'installation, il faut la créer manuellement avec la commande touch /var/lib/dhcpd.leases, par exemple. Ce fichier ne doit pas être édité manuellement.

* Configuration du serveur DHCP

Le fichier de configuration principal du serveur DHCP est dhcpd.conf. Sans prise en compte du service DNS Dynamique, la configuration basique du DHCP avec les exigences du cas pratique donne :

# Forçage de la mise à jour des IP fixes<br/>
update-static-leases on;<br/>
<br/>
# Les clients du réseau seront tous reconnus même<br/>
# si on ne connaît pas leur adresse mac.<br/>
allow unknown-clients; <br/>
<br/>			
# Durée de vie du bail (un jour=86400s)<br/>
max-lease-time 86400;<br/>
default-lease-time 86400; <br/>
<br/>
# Les options qui seront transmisent aux clients :<br/>
#le domaine et la passerelle <br/>
option domain-name-servers 192.168.1.10;<br/>
option domain-name "sigui.ci";<br/>
option routers 192.168.1.1; <br/>
<br/>
# La définition de la plage d'IP à distribuer.<br/>
subnet 192.168.0.0 netmask 255.255.255.0 {<br/>
range 192.168.1.11 192.168.1.254;<br/>
}

Cette configuration subit des modifications dans la mise en œuvre d'un DNS dynamique. On a le résultat suivant :

#Définition de la méthode de mise à jour<br/>
ddns-update-style interim;<br/>
<br/>
<br/>	
#Autorisation de la mise à jour<br/>
ddns-updates on;<br/>
<br/>
# Forçage de la mise à jour des IP fixes<br/>
update-static-leases on;<br/>
<br/>
#Forçage de la mise à jour que par le DHCP, les autres<br/>
#sources de modifications sont ignorées<br/>
ignore client-updates;<br/>
<br/>
<br/>
# Les clients du réseau seront tous reconnus même<br/>
# si on ne connaît pas leur adresse mac.<br/>
allow unknown-clients; <br/>
<br/>
# Durée de vie du bail (un jour=86400s)<br/>
max-lease-time 86400;<br/>
default-lease-time 86400; <br/>
<br/>
# Les options qui seront transmisent aux clients :<br/>
#le domaine et la passerelle <br/>
option domain-name-servers 192.168.1.10;<br/>
option domain-name "sigui.ci";<br/>
option routers 192.168.1.1; <br/>
<br/>
# La définition de la plage d'IP à distribuer.<br/>
subnet 192.168.0.0 netmask 255.255.255.0 {<br/>
range 192.168.1.11 192.168.1.254;<br/>
}<br/>
<br/>
#Balises à mettre en fin de ligne pour spécifier le DNS<br/>
#à mettre à jour pour ces jours : optionnel, mais recommandé<br/>
zone sigui.ci. {<br/>
	primary 192.168.1.10;<br/>
}<br/>
<br/>
zone 1.168.192.in-addr.arpa. {<br/>
	primary 192.168.1.10;<br/>
}<br/>

Le cas pratique se poursuit toujours. Au niveau du DNS, une nouvelle option de paramétrage apparaît : allow-update. C'est option indique au serveur DNS qu'il peut recevoir d'un serveur DHCP configuré sur la machine dont l'adresse IP est écrite.
La nouvelle configuration du fichier named.conf devient :

#Déclaration du fichier de résolution directe<br/>
zone "sigui.ci" in {<br/>
	type master ;<br/>
	file "/var/bind/sigui.ci.direct.db" ;<br/>
	allow-update { 192.168.1.5 ;} ;<br/>
}<br/>
<br/>
#Déclaration du fichier de résolution inverse<br/>
zone "1.168.192.in-addr.arpa" in {<br/>
	type master ;<br/>
	file "/var/bind/sigui.ci.reverse.db";<br/>
	allow-update { 192.168.1.5 ;} ;<br/>
}<br/>

Après ces différentes configurations, il faut redémarrer les deux serveurs :
Sous RedHat et Fedora :
/etc/rc.d/init.d/bind9 restart
/etc/rc.d/init.d/dhcpd restart

Cela consiste à mettre en place un système d'authentification entre les deux serveurs, basé sur une clé. Il existe plusieurs types de générateurs. Celui qui sera considéré ici, c'est rndc.key, souvent associé à BIND. Son fichier de configuration est: /etc/rndc.key.
On a les nouvelles configurations suivantes :

* Configuration du serveur DHCP

<paragraph>	
#On inclut le fichier de clé<br/>
include " /etc/rndc.key" ;<br/>
<br/>
#Définition de la méthode de mise à jour<br/>
ddns-update-style interim;<br/>
<br/>
<br/>
#Autorisation de la mise à jour<br/>
ddns-updates on;<br/>
<br/>
# Forçage de la mise à jour des IP fixes<br/>
update-static-leases on;<br/>
<br/>
#Forçage de la mise à jour que par le DHCP, les autres<br/>
#sources de modifications sont ignorées<br/>
ignore client-updates;<br/>
<br/>
<br/>
# Les clients du réseau seront tous reconnus même<br/>
# si on ne connaît pas leur adresse mac.<br/>
allow unknown-clients; <br/>
<br/>
# Durée de vie du bail (un jour=86400s)<br/>
max-lease-time 86400;<br/>
default-lease-time 86400; <br/>
<br/>
# Les options qui seront transmisent aux clients :<br/>
#le domaine et la passerelle <br/>
option domain-name-servers 192.168.1.10;<br/>
option domain-name "sigui.ci";<br/>
option routers 192.168.1.1; <br/>
<br/>
# La définition de la plage d'IP à distribuer.<br/>
subnet 192.168.0.0 netmask 255.255.255.0 {<br/>
range 192.168.1.11 192.168.1.254;<br/>
}<br/>
<br/>
#Balises à mettre en fin de ligne pour spécifier le DNS<br/>
#à mettre à jour pour ces jours : très recommandé pour le <br/>
#décodages des clés <br/>
zone sigui.ci. {<br/>
	primary 192.168.1.10;<br/>
	key rndckey;<br/>
}<br/>
<br/>
zone 1.168.192.in-addr.arpa. {<br/>
	primary 192.168.1.10;<br/>
	key rndckey;<br/>
}<br/>
</paragraph>

* Configuration du serveur DNS

#Déclaration du fichier de résolution directe<br/>
zone "sigui.ci" in {<br/>
	type master ;<br/>
	file "/var/bind/sigui.ci.direct.db" ;<br/>
	allow-update { key rndckey ;} ;<br/>
}<br/>
<br/><br/>
#Déclaration du fichier de résolution inverse<br/>
zone "1.168.192.in-addr.arpa" in {<br/>
	type master ;<br/>
	file "/var/bind/sigui.ci.reverse.db";<br/>
	allow-update { key rndckey ;} ;<br/>
}<br/>

Après ces configurations, il faut lancer une nouvelle génération de clés, puis redémarrer les serveurs. Pour la génération de clés, il suffit d'exécuter la commande :
rndc-confgen -a

Par defaut, la configuration du BIND accepte de répondre à toutes les demandes de résolution qui lui parviennent. Ce type de récursion est une faille de sécurité, dans la mesure où elle est peut être exploitée pour les attaques de type DoS, ou encore peuvent permettre à des personnes d'utiliser le serveur à des fins mal intentionnées.
Pour rémédier à cela, il est possible de n'autoriser qu'un réseau précis à faire des requêtes. Pour ce faire, on utilise deux paramètres principaux présentés dans le tableau ci-dessous:

Pour mieux organiser l'administration des fichiers de configuration, on peut regrouper la configuration des zones dans un fichier zones.conf, et dans le named.conf on fait, par exemple:

    //
    // Utilisation des Access-lists
    //On spécifie les réseaux et ordinateurs dont les requêtes seront acceptées
	//
    acl "recursionAutorise" {
        10.31.20.0/24;
        127.0.0.1;
    };

    //
    // Vues permettant de rendre le serveur DNS récursif en interne et Non recursif en externe
    //
	// On autorise la recursion pour la vue internal. A cette vue, on ajoute la liste des réseaux autorisés
    view "internal" {
                 match-clients {recursionAutorise;};
                 recursion yes;
                 include "/etc/zones.conf";
           };

	// On interdit la recursion pour la vue external. Cette vue concerne tous les autres réseaux non spécifiés.
    view "external" {
                 match-clients {any;};
                 recursion no;
                 include "/etc/zones.conf";
           };

Il existe des dizaines de paramètres pour circonscrire la sécurité dans la configuration du BIND. Les plus utilisés ont: