BIND fournit un service de resolution de nom grace au service /usr/sbin/named. Il utilise comme fichier de configuration :

• /etc/named.conf : le fichier de configuration du service named
• /var/named/ : le repertoire de travail de named ou sont stokées les fichers de zone, de cache, etc...

2.1.1 Téléchargement

Tout d'abord, il faut télécharger les sources du programme voulu (ftp://ftp.isc.org/isc/bind9/9.2.0/bind-9.2.0.tar.gz).

Nous l'avons mis par exemple dans le répertoire "/tmp". Il reste maintenant à l'extraire, en utilisant la commande :

tar -zxvf bind-9.2.0.tar.gz	    

2.1.2 Compilation et installation

La compilation passe par trois étapes distinctes :

• La configuration des paramètres de compilation.
• La compilation en elle-même.
• L'installation des binaires, documentations et fichiers de configuration par défaut.

Pour la configuration des paramètres de compilation, il faut entrer dans le répertoire racine des sources de BIND (ici "/tmp/bind-9.2.0"), et exécuter la commande "./configure".

La commande "./configure" peut contenir un ou plusieurs paramètres tels que :

• "--with-openssl" : Pour le support du DNSSEC, qui est un canal OpenSSL (version 0.9.5a minimum) permettant de faire transiter le trafic de réplication de zones entre serveurs DNS primaire et secondaire(s).
• "--enable-threads" : Ajoute le support pour le multithreading, pour pouvoir tirer partie des systèmes multi-processeurs.
• "--with-kame" : Support de IPv6, s'il n'est pas pris en charge par défaut par le système installé.

Il existe beaucoup d'autres paramètres, dont nous ne parlerons pas, mais dont on peut avoir le listing et la description avec la commande "./configure --help".

La compilation en elle-même s'effectue en utilisant la commande :

make	    

Il ne reste plus qu'à installer les binaires compilés, ainsi que les documentations dans les répertoires appropriés avec la commande :

make install	    

Une fois ces étapes accomplies, Bind est à présent installé et prêt à être configuré.

2.2 Configuration de Bind

Maintenant que Bind est installé, nous allons maintenant voir les différentes étapes de configurations du service.

2.2.1 Le fichier /etc/named.conf

Ce fichier est composé d'une suite de définitions (ou statements) utilisant des options insérées entre accolages qui vont nous permettre de définir les caractéristiques de notre serveur.

<déclaration> ["<déclaration-1-nom>"] [<déclaration-1-classe>] {
   <option-1>;
   ...
   <option-N>;
};	    

2.2.2 Les différents types de déclaration

Les listes de contrôle d'accès

Ce type de déclaration permet de définir des groupes d'hôtes. Le but est de définir ces groupes pour ensuite dans d'autres déclarations pouvoir les désigner par le biais du nom de la liste. La syntaxe est la suivante :

acl <nom_de_la_liste> {
   <élément-correspondant>;
   [<élément-correspondant>; ...]
};	    

Il est possible d'utiliser des mots clés tels que :

• any : toutes les addresses IP
• localhost : toutes les IP utilisées par le serveur
• localnets : tous les réseaux directement connectés au serveur
• none : aucune IP

Afin d'illustrer cela, voici un exemple ou nous configurons 2 listes :

acl bad_network {
   172.16.0.0/16
   192.168.0.0/24;
};

acl my_network {
   192.168.1.0/24;
};

options {
   blackhole { bad_network; };
   allow-query { my_network; };
   allow-recursion { my_network; };
}	    

Les inclusions

L'un des problèmes de sécurité du service named est que le fichier /etc/named.conf est accessible en lecture par tous les utilisateurs.

Les inclusions sont utilisées afin de pouvoir stocker des informations « critiques » dans des fichiers séparés et à accès restreint puis de pouvoir les utiliser depuis named.conf. La syntaxe est la suivante :

include  "<nom-fichier>"	    

Les options

Ce type de déclaration fournit les options générales de configuration du serveur et établit les valeurs par défaut pour les autres déclarations

options { 
   <option>;
   [<option>; ...] 
};	    

Voici un exemple d'option :

acl "labo-linux" { 127.0.0.1; 192.168.1.0/24; };

options {
   directory "/etc/namedb";
   forwarders {
      193.252.19.3;		# Les DNS de notre 
      193.252.19.4;		# providers
   };
	       
   allow-query {"labo-cisco";};

   listen-on { 192.168.1.1; };

   pid-file "named.pid";
};	    

Les déclarations de zone

Ce type de déclaration permet de définir les caractéristiques d'une zone :

• L'emplacement de ses fichiers de configurations
• Les options spécifiques à la zone

La syntaxe à utiliser est la suivante :

zone <zone-nom> <zone-classe> {
   <zone-options>;
   [<zone-options>; ...]
};	    

De nombreuses options peuvent être spécifiées pour ce type de déclaration :

Illustrons cela avec deux exemples, le premier dans le cas d'un serveur maître et le second pour un serveur esclave

# Cas du serveur maître : 
   zone "." {
   type hint;
   file "named.root";
};

zone "labo-linux.com" IN{
   type master;
   file "labo-linux.com.zone";
   allow-update { none; };
};

# Cas du serveur esclave : 
zone "labo-linux.com" {
   type slave;
   file « labo-linux.com.zone » ;
   masters { 192.168.0.1; };
};	    

Nous avons ici définit notre serveur en tant que maître pour la zone labo-linux.com et avons indiqué à named de refuser la mise à jour à partir de n'importe quel hôte. Nous avons également indiqué que le fichier comportant le détail de la zone serait labo-linux.com dans /var/named.

Une fois la configuration du fichier /etc/named.conf, il nous faut à présent créer et définir les fichiers de zone.

2.3.1 Configuration d'un fichier de zone

Le nom du fichier doit correspondre au nom définit dans l'option file de la déclaration insérée dans named.conf.

Ce type de fichier peut contenir 2 types d'informations :

• Des directives : Ce sont des instructions pour l'exécution de certaines taches ou de paramètres spéciaux
• Des enregistrements de ressources : des définitions des paramètres de la zone et assignation des identités aux hôtes.

Les directives de fichiers de zone

Pour insérer une directive ; de préférence au début du fichier ; il convient d'utiliser le symbole $ suivi du nom de la directive. Les directives les plus courantes sont :

2.3.2 Les enregistrements de ressources d'un fichier de zone

De nombreux types d'enregistrements sont disponibles, voici les plus courants :

Les enregistrements de type «A»

Cet enregistrement est utilisé pour associé un nom à une IP. Si l'hôte n'est pas spécifié, l'adresse sera utilisé par défaut pour le domaine.

Syntaxe :
<hôte>	IN	A	<adresse IP>	    

Exemple :

      IN     A       192.168.10.1
dc1   IN     A       192.168.10.2	    

Les enregistrements de type «CNAME»

L'enregistrement CNAME est un alias redirigeant vers un autre nom d'hôte

Syntaxe :
<alias>     IN     CNAME   <nom>	    

Exemple :

dc1		IN    A       192.168.10.2
serveur	IN    CNAME   dc1 	    

Les enregistrements de type «MX»

Le but de ces enregistrements est de rediriger le courier à destination de ce domaine vers un ou plusieurs serveurs de courriers par défaut.

Syntaxe :
IN	  MX 	<préférence>	<nom-serveur>	    

Exemple :

IN	  MX     10     mail.labo-linux.com.
IN	  MX     20     mail2.labo-linux.com.	    

Les enregistrements de type «NS»

Cet enregistrement annonce les serveurs de noms faisant autorité pour une zone.

Syntaxe :
IN	  NS	 Serveur	    

Exemple :

IN     NS     main-dns.labo-linux.com.
IN     NS     backup-dns.labo-linux.com.	    

Les enregistrements de type SOA

Utilisé pour indiquer les informations importantes au sujet de cet espace de nom, cet enregistrement est le premier à insérer après les directives.

La syntaxe est la suivante :

@     IN     SOA	    <serveur-noms-primaire>     <email> (
<numéro-série>
<temps-actualisation>
<temps-nouvel essai>
<temps-expiration>
<TTL-minimum> )	    

Expliquons à présent les différents champs présent ici :

• 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.
• <serveurs-noms-primaire> : le serveur faisant autorité
• <email> : l'adresse de la personne à contacter à propos de cet espace de noms
• <numéro-série> : incrémenté à chaque changement du le fichier de zone afin que named sache qu'il doit recharger cette zone. Cela 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.
• <temps-actualisation> : 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.
• <temps-nouvel essai> : 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.
• <temps-expiration> : temps maximum depuis une abscence de réponse du serveur maître avant que le serveur esclave ne cesse de répondre en tant qu'autorité pour les requêtes au sujet de cet espace de nom.
• <TTL-minimum> : demande que d'autres serveurs de noms placent en cache les informations pour cette zone pendant au moins cette durée (en secondes).

Toutes les durées sont exprimées en secondes, cependant les mots clés tels que M, H, D et W (semaine) fonctionnent.

Voici à présent un exemple d'application :

@            IN           SOA       dns.labo-linux.com.         hostmaster.labo-linux.com. (
02050500			      ; numéro de série
3H				      ; rafraichir après 3 heures 
1800				      ; retenter après 30 minutes
604800				      ; expire après 1 semain
3D )				      ; TTL minimum de 3 jours

		  IN	   NS		  dns.labo-linux.com.
		  IN	   MX       10	  mail.labo-linux.com.

dns		  IN       A		  192.168.1.1
www               IN       CNAME	  dns.labo-linux.com.
ftp               IN       A		  192.168.1.2
mail              IN       A		  192.168.1.3
pop               IN       CNAME	  mail.labo-linux.com.
smtp              IN       CNAME	  mail.labo-linux.com.
imap              IN       CNAME	  mail.labo-linux.com.
imprimante        IN       A		  192.168.1.4
tftp              IN       A		  192.168.1.5
routeuradsl       IN       A		  192.168.1.254	    

A présent que notre fichier de zone est prêt, il nous faut à présent nous occuper du fichier de zone inverse.

2.4.1 Principe de domaine inversé

Le processus de résoution inversé permet la recherche d'un nom à partir d'une IP. Le domaine "in-addr.arpa" a été créé pour cela. On l'appelle domaine inverse et la résolution des adresses IP en noms de domaine se nomme table inverse (translation inverse). Le nom de domaine inverse est créé en inversant les nombres de l'adresse IP, et ajoutant in-addr.arpa à la fin.

Exemple : l'adresse IP de www.labo-linux.com est 212.180.91.66. Son nom de domaine inversé est donc 66.91.128.212.in-addr.arpa

Afin de comprendre le fonctionnement et la nécessité de ce nom inversé, prenons un exemple concret :

Votre serveur FTP accepte des requêtes de divers clients. Cependant vous ne souhaitez n'accepter que des requêtes provenant de domaines bien spécifiques, par exemple labo-linux.com.

Lorsqu'un client se connecte chez vous, votre serveur peut vous dire quelle est l'adresse IP du client, puisque cette dernière se trouve dans tous les paquets qui traversent le réseau. L'adresse IP que le système fournit au serveur FTP est 212.180.91.66. Pour retrouver le nom de cette machine, il nous faut trouver 66.91.180.212.in-addr.arpa.

Le serveur de noms va donc d'abord trouver les serveurs puis les serveurs arpa., puis in-addr.arpa, et poursuivre la recherche inverse par 212, puis 180 et finalement trouver le serveur pour la zone 91.128.212. à in-addr.arpa a labo-linux.com

C'est ce dernier qui lui dira que pour 66.91.180.212.in-addr.arpa nous avons un champ ``PTR www.labo-linux.com'', ce qui veut dire que le nom qui va avec 212.180.91.66 est www.labo-linux.com.

Notre serveur n'acceptant que certain domaines dont labo-linux.com, la connexion sera donc autorisée.

S'il n'existait pas de résolution inverse de 212.180.91.66 au travers de la zone in-addr.arpa, le serveur aurait été tout à fait incapable de trouver le nom et donc de filtrer en fonction du nom de domaine.

De nombreux serveurs n'acceptent pas les connexions venant de machines dont ils ne peuvent retrouver le nom. C'est pourquoi la résolution de noms inverse pour les machines est obligatoire.

2.4.2 Configuration d'un fichier de résolution de noms inversé

Le but de ce fichier va être de fournir une résolution inversée, donc un nom FQDN à partir d'une adresse IP. Ce fichier est similaire au fichier de noms précédents si ce n'est que les enregistrements sont de types PTR :

Exemple :

$ORIGIN 1.168.192.in-addr.arpa
$TTL 86400
@            IN           SOA       dns.labo-linux.com.  hostmaster.labo-linux.com. (
02050500			; numéro de série
3H				; rafraichir après 3 heures 
1800				; retenter après 30 minutes
604800				; expire après 1 semain
3D )				; TTL minimum de 3 jours

	       IN	NS	    dns.labo-linux.com.
	       IN	MX    10    mail.labo-linux.com.
20	       IN       PTR	    ws1.labo-linux.com.
21	       IN       PTR	    ws2.labo-linux.com.
22	       IN       PTR	    ws3.labo-linux.com.
23	       IN       PTR	    laptop1.labo-linux.com.
24	       IN       PTR	    database.labo-linux.com.
25	       IN       PTR	    gateway.labo-linux.com.	    

Ce fichier serait mis en service avec la déclaration suivante dans named.conf :

zone "1.0.10.in-addr.arpa" IN {
   type master;
   file "labo-linux.com.rr.zone";
   allow-update { none; };
};	    

Le but de la Sand Box, en cas d'attaque pirate, est de limiter l'accès à seulement une infime partie du système de fichiers.

Pour cela, nous allons démarrer le daemon de BIND dans un environnement chrooté. L'effet obtenu sera de faire croire à BIND que son repertoire sera sa propre racine de système de fichiers.

Nous allons voir comment sécuriser le DNS via la mise en place d'une SandBox. Pour cela, il va falloir procéder à quelques modifications :

• Créer un utilisateur non-privilégié pour faire fonctionner BIND.
• Changer le propriétaire des fichiers de BIND.
• Créer un fichier PID dans notre environnement chrooté.
• Modifier le fichier de configuration principal.
• Démarrer BIND avec les bons paramètres.

Commençons la creation de l'utilisateur non-privilégié. Nous avons choisi d'utiliser le compte dns (UID = 1005).

Nous créons maintenant le fichier PID pour bind, avec la commande "touch named.pid".

Le changement de propriétaire des fichiers de BIND (présents dans le répertoire "/etc/namedb") se fait grâce à la commande "chown dns *" dans le répertoire de base de BIND.

Les modifications qu'il faut apporter au fichier de configuration principale sont les suivantes :

• directory "/";
• pid-file "named.pid";

La dernière modification concerne les paramètres de démarrage. Il suffit pour cela de mettre "-u 1005 -t /etc/namedb -c named.conf" en tant que paramètre pour l'option "named_flags" du fichier "/etc/rc.conf", au lieu de "-c /etc/namedb/named.conf".

Il ne nous reste plus qu'à redémarrer le serveur afin que le service DNS soit entièrement fonctionnel avec toutes les dernières modifications.

5. Annexes

zone "labo-linux.com" {
   type master;
   file "/var/named/labo-linux.zone";
   allow-update {
      127.0.0.1;
   };
};
# La zone de recherche inverse
zone "10.168.192.in-addr.arpa" {
   type master;
   file "/var/named/reverse.rev";
   allow-update {
      127.0.0.1;
   };
};	 

# méthode de mise à jour du DNS :
ddns-update-style interim;

# mise à jour autorisée
ddns-update on;

# mise à jour par le serveur DHCP forcée
ignore client-updates;

# la mise à jour des IP fixes forcée
update-static-leases on;

# on définit également quel DNS doit être mis à jour pour ces zones :
zone labo-linux.com. {
   primary 127.0.0.1;
}

zone 10.168.192.in-addr.arpa. {
   primary 127.0.0.1;
}	 

send host-name "lenomdelamachine";	 

5.2 Exemples de fichiers de configuration

acl "labo-linux" { 127.0.0.1; 192.168.1.0/24; };
options {
   directory "/etc/namedb";
   forwarders {
      193.252.19.3;
      193.252.19.4;
   };
   allow-query {"labo-linux";};
};

zone "." {
   type hint;
   file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
   type master;
   file "localhost.rev";
};

zone "labo-linux.com" {
   type master;
   file "labo-linux.zone";
};

zone "1.168.192.in-addr.arpa" {
   type master;
   file "1.168.192.in-addr.arpa";
};	    

@            IN           SOA       dns.labo-linux.com.    hostmaster.labo-linux.com. (
02050500
10800
1800
3600000
259200 )
	       IN    NS		    dns.labo-linux.com.
	       IN    MX	      10    mail.labo-linux.com.
dns            IN    A		    192.168.1.1
www            IN    CNAME	    dns.labo-linux.com.
ftp            IN    A		    192.168.1.2
mail           IN    A		    192.168.1.3
routeuradsl    IN    A              192.168.1.254
passerelle     IN    CNAME          routeuradsl.labo-linux.com.	    

@            IN           SOA       dns.labo-linux.com.         hostmaster.labo-linux.com.  (
02042800
3600
900
3600000
3600 )
      IN           NS         labo-linux.com.
1     IN           PTR        localhost.	    

options {
   directory "/var/named";
   allow-query { 192.168.1.0/24; };
   allow-transfer{ 192.168.1.0/24; };
   allow-recursion{192.168.1.0/24; };
};

controls {
   inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

zone "." IN {
   type hint;
   file "named.ca";
};

zone "localhost" IN {
   type master;
   file "localhost.zone";
   allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
   type master;
   file "named.local";
   allow-update { none; };
};

include "/etc/rndc.key";	    

5.3 Bibliographie