1.

Configuration d’un serveur DNS sous unix

BIND (Berkeley Internet Name Domain), précédemment appelé: Berkeley Internet Name Daemon est
le serveur DNS le plus utilisé sur Internet, spécialement sur les systèmes de type UNIX et est devenu de
facto un standard.

La configuration de bind ce fait en modifiant le fichier :

 /etc/named.conf : Contient les paramètres généraux.

 /var/named/named.ca : Indique les serveurs dns racines.
 /var/named/named.local : résolution locale des adresses loopback
 et en créant des fichiers de zone dans le répertoire /var/named/.

1.1. /etc/named.conf

Le fichier racine pour la configuration du serveur de nom est le fichier "/etc/named.conf". Ce fichier est
lu au démarrage du service et donne la liste des fichiers qui définissent la base de données pour la zone.

Déclaration options

La déclaration options permet de paramétrer des options globales du serveur de noms. Une seule
déclaration options peut être utilisée dans le fichier /etc/named.conf. Voici un exemple de déclaration
options avec les options les plus utilisés :

options {

Directory chemin ;

};

 directory : spécifie le répertoire de travail du serveur de noms. Par défaut, le répertoire

/var/named est utilisé
 Déclaration de zone

Une déclaration de zone définit les caractéristiques particulières d’une zone, tel que le nom de son
fichier de configuration … :

Zone nom_domaine in {
Type master ;
File nom ;
};
zone nom_domaine in {
type slave ;
masters {adr_ip ; [adr_ip ; ]} ;
file nom ;
};
zone «.» in {
type hint ;
file nom;
};

Dans la déclaration, nom-domaine correspond au nom de la zone. Cet attribut est particulièrement
important, puisqu'il représente la valeur par défaut assignée à la directive $ORIGIN utilisés au sein du
fichier de zone correspondant.
 Parmi les options les plus courantes de la déclaration de zone figurent:

 type : définit le type de zone. Ci-après figure une liste des types valides:
 hint : un type spécial de zone utilisé pour diriger des transactions vers les serveurs de noms
racines qui résolvent des requêtes lorsqu'une zone n'est pas connue autrement. Aucune
configuration au-delà de la valeur par défaut n'est nécessaire avec une zone hint.
 master : désigne le serveur de noms faisant autorité pour cette zone. Une zone devrait être
configurée comme de type master (maître) si les fichiers de configuration de la zone se
trouvent sur le système.
 slave : désigne le serveur de noms comme serveur esclave pour cette zone. Cette option
spécifie également l'adresse IP du serveur de noms maître pour cette zone.
 masters : l'option masters établit une liste des adresses IP à partir desquelles demander des
informations sur la zone faisant autorité. Cette option ne doit être utilisée que si la zone est définie
comme de type slave.
 file : spécifie le nom du fichier qui contient les données de configuration de la zone, dans le
répertoire de travail named.
 allow-transfer : spécifie les serveurs esclaves qui sont autorisés à requérir un transfert des
informations de la zone. Par défaut toutes les requêtes de transfert sont autorisées.
 notify : informe les serveurs esclaves lorsqu'une zone est mise à jour. Les options suivantes
sont acceptées:
 yes : informe les serveurs esclaves.
 no : n’informe pas les serveurs esclaves.
 allow-query : spécifie les clients qui sont autorisés à requérir des informations à propos de
cette zone. Par défaut toutes les requêtes d'informations sont autorisées.
 allow-update : spécifie les hôtes qui sont autorisés à mettre à jour dynamiquement des
informations dans leur zone. Par défaut aucune requête de mise à jour dynamique n'est autorisée.
Ci-dessous se trouve un exemple de déclaration de zone pour le serveur de nom primaire
hébergeant ofppt.org :
Zone ofppt.org IN {
type master;
file db.ofppt;
allow-update {none};
};

La déclaration de zone pour le serveur esclave de ofppt.org ressemble à l’extrait ci-dessous :

Zone ofppt.org IN {
type slave;
file db.ofppt.org;
masters {192.168.0.1};
};

Remarque : Plusieurs outils sont disponibles pour réaliser des tests de la configuration du serveur et de
ses zones :

 named-checkconf : Pour chercher les erreurs de syntaxe dans les fichiers "named.conf*".

 named-checkzone : Similaire à checkconf, mais pour les fichiers de zones.

1.2. Fichiers de zone

Il existe deux fichiers de configuration pour chaque zone. L’un est nécessaire pour trouver l’adresse
IP d’après le nom de l’hôte (résolution directe) et l’autre pour trouver le nom d’hôte d’après l’adresse IP
(résolution inverse). Chaque fichier de zone est nommé selon le paramètre fourni à l’option file dans la
déclaration zone (/etc/named.conf).
 Directive de fichier de zone
Les directives sont identifiées par le symbole ($) suivit du nom de la directive. Elles apparaissent au haut
du fichier de zone. Les directives les plus couramment utilisées sont les suivantes:
 $TTL : règle la valeur par défaut de Time to Live (TTL) (ou temps de vie) pour la zone. Cette
valeur exprimée en secondes, correspond à la durée pendant laquelle les enregistrements de
ressources de la zone resteront valides. Chaque enregistrement de ressources peut contenir
sa propre valeur TTL, qui remplace alors cette directive. En accroissant cette valeur, les serveurs
de noms distants peuvent mettre en cache ces informations de zone pendant plus longtemps.
Cela réduit le nombre de requêtes effectuées au sujet de cette zone, mais rallonge également le
temps nécessaire pour la prolifération des changements des enregistrements de ressources.
 $ORIGIN : attache le nom de domaine à tout enregistrement non-qualifié. L'utilisation de la
directive $ORIGIN n'est pas nécessaire si l'on nomme la zone dans /etc/named.conf parce que le
nom de la zone est utilisé par défaut, comme la valeur de la directive $ORIGIN
Enregistrement de ressources
Les enregistrements de ressources représentent les premiers composants d’un fichier de zone. Il existe
de nombreux types différents d’enregistrements de ressources, les plus fréquemment utilisé sont
énumérés ci-dessous.
 SOA (Start of Authority) : L’enregistrement SOA (ou Origine d’autorité) indique l’origine de la
zone. Voici la syntaxe de cet enregistrement :
@ IN SOA nom_serveur. email_contact. (
numero_serie ; Serial
rafraichissement ; Refreah
nombre_essais ; Retry
expiration ; Expire
ttl_minimum) ; Minimum
Le symbole @ place la directive $ORIGIN (ou le nom de domaine). Le serveur de noms primaire
faisant autorité pour ce domaine est utilisé pour le nom_serveur et l'adresse email de la personne à
contacter à propos de cet espace de nom est remplacée par email_contact.
Voici la description des paramètres d’un enregistrement SOA :
 numéro_série est incrémentée chaque fois que vous changez le fichier de zone afin que named
sache qu'il doit recharger cette zone. La valeur numéro_série 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.
 rafraîchissement 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.
 nombre_essai (retry) 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.
 expiration Si le serveur maître n'a pas répondu à une requête de rafraîchissement avant que la
durée indiquée dans expiration ne se soit écoulée, le serveur esclave 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).
 NS : Name Server
L’enregistrement NS indique le serveur de noms responsable d’un domaine. Sa syntaxe est la suivante :
IN NS seveur.
 A : Address
L’enregistrement A indique l’adresse d’un hôte. Voici la syntaxe de cet enregistrement :
nom_hôte_complet IN A adresse_IP
Par exemple, la ligne :
www.ofppt.org. IN A 10.73.127.132
Indique l’adresse IP du serveur Web www.ofppt.org. Le fichier de zone doit contenir au moins un
enregistrement A par hôte. Il est possible d’indiquer uniquement le nom de l’hôte, comme dans l’exemple
suivant :
www IN A 10.73.127.132
Le nom de domaine sera automatiquement ajouté au nom de l’hôte.
 CNAME : Canonical Name
L’enregistrement CNAME indique l’alias d’un hôte officiel. Voici la syntaxe d’un enregistrement
CNAME :
nom_alias IN CNAME nom_hote.
Par exemple, l’enregistrement
ftp.ofppt.org. IN CNAME www.ofppt.org.
indique que le nom ftp.ofppt.org. est associé à www.ofppt.org. . Il est aussi possible d’utiliser uniquement
les noms d’hôtes comme dans l’exemple suivant :
ftp IN CNAME www

 MX :
Indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné.
ofppt.org. IN MX 10 mai1l.ofppt.org.
ofppt.org. IN MX 20 mai1l1.ofppt.org.

10, 20 : Indique la priorité

L'enregistrement de ressources MX doté de la priorité la plus basse est préféré aux autres.
Toutefois, de multiples serveurs de messagerie peuvent avoir la même valeur pour distribuer
uniformément le trafic d'emails entre eux.
 PTR : Domain Name Pointer
Cet enregistrement transforme une adresse IP en nom d’hôte. C’est le service des noms de
domaine inverse. Voici la syntaxe d’un enregistrement PTR :
adresse_IP IN PTR nom_hôte.
Par exemple, l’enregistrement
10.73.127.132 IN PTR www.ofppt.org.
associe l’adresse IP 10.73.127.132 à l’hôte www.ofppt.org.

1.3. Named.ca

Ce fichier n’a pas à être modifier. Il contient les adresses des serveurs dns racine.

1.4. named.local

@ IN SOA linux.ofppt.org. root. ofppt.org .(

2000101500 ; numéro de série
28800 ; rafraîchissement toutes les 8 heures
14400 ; nouvel essai toutes les 4 heures
604800 ; expiration dans 7 jours
86400 ) ; temps de vie minimal 24 heures
NS linux.ofppt.org.
1 PTR localhost.
Normalement, les valeurs de ce fichier ne doivent pas être modifiées. Si une modification doit être faite
dans ce fichier vous devez modifier le numéro de série doit être modifié afin de faire connaître cette
modification aux autres serveurs dns.
2. Configuration d’un client DNS

Pour accéder aux différents serveurs de l’Internet, il est nécessaire de configurer le client DNS. La
partie cliente d’un DNS s’appelle un « resolver ». Il s'agit d'un ensemble de fonctions écrites en C
permettant aux différents programmes de lancer une requête de résolution de nom. Les fichiers de
configuration du « resolver » s'appellent /etc/resolv.conf et /etc/host.conf.

2.1. /etc/host.conf

Ce fichier permet de spécifier au système la manière de résoudre les adresses IP en fonction des
noms. Si vous utilisez les services d'un serveur de noms, il doit contenir ces deux lignes:

order hosts, bind

multi on

La première ligne des fichiers définit l’ordre dans lequel les services de résolution de noms doivent
être interrogés. Dans notre exemple, c’est d’abord le fichier local /etc/hosts qui est parcouru. Si aucune
correspondance n’est trouvée, le programme interroge le serveur de noms.

La deuxième ligne indique, par le terme « multi on », permet d'avoir plusieurs adresses IP pour un
même nom de machine dans /etc/hosts.

2.2. /etc/resolv.conf

Permet d'affecter les serveurs de noms à interroger pour faire la résolution des noms.

search microapp.fr
# Adresse du serveur de noms
nameserver 205.1.1.1
nameserver 205.1.1.5
nameserver 205.1.2.1

L’entrée « search » impose au programme de tenter de résoudre un nom incomplet. Ce nom de

domaine est ajouté après les noms incomplets. Cette entrée s’appelait précédemment « domain », pour
ce fichier. Conformément à la demande RFC1535 (Request For Comment 1535), il est fortement
recommandé de ne plus utiliser l’entrée « domain ».

3. Démarrage du serveur DNS

Il est possible de démarrer le serveur de nom manuellement à l’aide de la commande suivante :
#service named restart / start / stop

4. teste du serveur DNS

Les commandes ping nslookup, host et dig permettent de tester le serveur DNS, elles sont décrites dans
les sections suivantes.
- Ping
Le programme ping permet de vérifier si une connexion fonctionne en affichant de l’information semblable
à celle ci-dessous :
# ping shuttle.mike.fr
PING shuttle.mike.fr (132.195.99.2): 56 data bytes
64 bytes from 132.195.99.2: imcp_seq=0 ttl=254 time 5.9 ms
64 bytes from 132.195.99.2: imcp_seq=1 ttl=254 time 5.9 ms
64 bytes from 132.195.99.2: imcp_seq=2 ttl=254 time 5.9 ms
 - dig
L'utilitaire dig permet de faire des requêtes DNS évoluées et fournit un maximum d'informations sur la
requête. Il est très utile pour vérifier la bonne configuration d'un serveur DNS.
Exemples d'utilisation de dig :
Requête sur le champ "A" du nom www.mondomaine.org auprès du serveur DNS 12.42.112.242 :
% dig @12.42.112.242 www.mondomaine.org A
Requête sur la champ "MX" du nom mondomaine.org auprès du serveur DNS 12.42.112.242 :
% dig @12.42.112.242 mondomaine.org MX
Requête sur tous les champs du nom mondomaine.org auprès du serveur DNS 12.42.112.242 :
% dig @12.42.112.242 mondomaine.org ANY
Requête inverse (i.e. reverse DNS) sur l'IP 12.42.111.242 auprès du serveur DNS
12.42.112.242 :
% dig @12.42.112.242 -x 12.42.111.242

Exemple de configuration :

foo.org. IN SOA ns1.foo.org. hostmaster.foo.org. (

20001210011 ; numéro de série
10800 ; rafraîchissement
3600 ; nouvel essai
604800 ; Obsolescence après une semaine
86400 ) ; TTL minimal de 1 jour
# Enregistrement de type NS pour le domaine foo.org:
foo.org. IN NS ns1.foo.org.
foo.org. IN NS ns2.foo.org.
# Enregistrements de type A : Nous devons décrire la correspondance Nom / Adresse
ns1.foo.org. IN A 192.168.0.1
ns2.foo.org. IN A 192.168.0.2
localhost.foo.org. IN A 127.0.0.1
# Enregistrements de type CNAME : Ce sont les alias (Canonical Name). Une requête du type
http://www.foo.org sera adressée à ns1.foo.org, puisque www est un alias de ns1.
ns1.foo.org. IN CNAME www.foo.org.
ns2.foo.org. IN CNAME ftp.foo.org.

# Enregistrement de type PTR : Ils serviront à la résolution de nom inverse.

1.0.168.192.in-addr.arpa. IN PTR ns1.foo.org.
2.0.168.192.in-addr.arpa. IN PTR ns2.foo.org.

5. Mise en place d’un serveur DNS dynamique

Un serveur DNS dynamique (DDNS) est un serveur DNS qui sera mis à jour automatiquement
par un serveur DHCP. Les clients du réseau qui se connecteront, vont obtenir une adresse IP
automatiquement, et feront partit du domaine.
 De cette façon, l'administrateur du réseau ne devra plus mettre à jour le nom d'hôtes du client
avec son adresse IP dans les fichiers de zones, du serveur DNS, c'est le serveur DHCP qui mettra
à jour automatiquement le fichier.

Pour configurer un DDNS il faut modifier les fichiers de configuration des deux serveurs. A
savoir le fichier dhcpd.conf, et le fichier named.conf.

5.1. Modification du serveur DHCP

La modification du serveur DHCP consiste à activer la mise à jours automatique du serveur DNS,
d’indiquer pour quelle zone le serveur DHCP doit faire la mise à jour et en fin de sécuriser l’accès au
serveur DNS par un e clé cryptée.
Code DHCP:
include "/etc/rndc.key";
ddns-update-style interim;
ddns-updates on;
ddns-domainname "ofppt.org";
ddns-rev-domainname "in-addr.arpa";
zone ofppt.org
{
primary 192.168.0.201;
key rndckey;
}

zone 0.168.192.in-addr.arpa
{
primary 192.168.0.201;
key rndckey;
}

 include "/etc/rndc.key": Pour que le serveur DHCP, puisse mettre à jour le DNS, une clef cryptée
doit être déclaré dans le fichier de configuration du serveur DHCP, pour une question de sécurité.
Vérifier que vous avez bien le fichier rndc.key.
 ddns-update-style interim: Indique la méthode de mise à jour DNS.
 ddns-updates on: active la mise à jours dynamique.
 ddns-domainname "ofppt.org": indique la zone qui va être mis à jours dynamiquement.
 ddns-rev-domainname "in-addr.arpa": la zone inverse, La valeur "in-addr.arpa" correspond à
chaque réseaux/sous réseaux.
 Zone : Il faut indiquer dans quelle zone le serveur DHCP peut écrire dans le fichier de configuration
du serveur DNS.
5.2. Modification du serveur DNS

La modification du serveur DNS consiste à indiquer sur quel port est autorisée la mise à jour ainsi que à
partir de quelle machine et de sécuriser l’accès au serveur DNS par une clé cryptée.
Code DNS:
include "/etc/rndc.key";

controls
{
inet 127.0.0.1 port 953 allow { 127.0.0.1; 192.168.0.201; } keys { "rndckey"; };
inet 192.168.0.0 port 953 allow { 127.0.0.1; 192.168.0.201; } keys { "rndckey"; };
};

zone " ofppt.org "

{
 type master;
file "db.ofppt.org ";
allow-update { key rndckey; };
notify yes;
};
zone "0.168.192.in-addr.arpa"
{
type master;
file “db.192.168.0";
allow-update { key rndckey; };
notify yes;
};

La clef: Il faut déclarer clef en faisant une inclusion du fichier clef (Comme pour le serveur DHCP).
Le port d'écoute (controls): Avec cette ligne, on autorise la mise à jour par une clef sur le port 953.
Les zones: On précise les zones qui doivent être mis à jour par le serveur DHCP

5.3. Les droits

Pour terminer avec la configuration il ne reste plus qu'à modifier les droits d'accès au dossier: /var/named,
par les commandes suivantes:
# chmod 2775 /var/named
# chown root:named /var/named
Maintenant, il ne reste plus qu'à redémarrer les deux serveurs par les commandes suivantes:
# service named restart
# service dhcpd restart
Remarque : si vous éditez vos fichiers de zone, vous n'allez pas voire le nom d'hôtes et l'adresse IP du
client qui vient d'être ajouté par le DHCP, c'est pourquoi il y a les deux nouveaux fichiers .jnl. Mais après
quelques minutes les fichiers de zone vont être mis à jour automatiquement!