Dns Linux

Installation et configuration
d'un serveur DNS sous Linux
par Guillaume Sigui (Page d'accueil) (Blog)
Date de publication : 22 Avril 2009
Dernière mise à jour : 14 Décembre 2009
Cet tutoriel aborde l'installation et la configuration d'un serveur DNS sous Linux. Il décrit
aussi le fonctionnement des serveurs DNS dans le monde. Vu l'importance de plus en plus
accrue du DNS, il convient de présenter un article qui en aborde les aspects généraux et
techniques fondamentaux. Il est adressé à tout public: débutants et experts.
Installation et configuration d'un serveur DNS sous Linux par Guillaume Sigui (Page d'accueil) (Blog)
Introduction...................................................................................................................................................................3
I - GENERALITES....................................................................................................................................................... 3
I-1 - Avènement des noms de domaine................................................................................................................ 3
I-2 - Définition d'un serveur DNS...........................................................................................................................3
I-3 - Quelques notions fondamentales...................................................................................................................4
I-3-1 - Notion de domaine................................................................................................................................ 4
I-3-2 - Notion d'hôte.......................................................................................................................................... 4
I-3-3 - Notion de zone...................................................................................................................................... 4
I-4 - Architecture de fonctionnement sur internet.................................................................................................. 4
I-4-1 - Architecture logique de fonctionnement................................................................................................ 4
I-4-2 - Gestion des requêtes DNS sur internet................................................................................................ 8
I-4-3 - Serveurs racines du DNS et serveurs du domaine de premier niveau................................................. 8
I-4-4 - Serveurs du domaine de deuxième niveau et notions de registre...................................................... 10
I-5 - Architecture de fonctionnement sur intranet................................................................................................ 10
I-6 - Fonctionnement interne du serveur............................................................................................................. 10
II - INSTALLATION ET CONFIGURATION DE BASE...............................................................................................11
II-1 - Paquet d'installation.....................................................................................................................................11
II-2 - Installation....................................................................................................................................................11
II-3 - Configuration de base................................................................................................................................. 11
II-3-1 - Problématique..................................................................................................................................... 11
II-3-2 - Configuration du fichier principal........................................................................................................ 11
II-3-3 - Configuration des fichiers de zone..................................................................................................... 12
II-4 - Opérations post-configurations....................................................................................................................14
II-4-1 - Redémarrage du serveur....................................................................................................................14
II-4-2 - Inscription du serveur......................................................................................................................... 14
II-4-3 - Tests de configuration.........................................................................................................................15
III - ASPECTS AVANCES DE LA CONFIGURATION............................................................................................... 15
III-1 - Serveur primaire et serveur secondaire.....................................................................................................15
III-1-1 - Définitions...........................................................................................................................................15
III-1-2 - Avantages.......................................................................................................................................... 15
III-1-3 - Transfert de zones.............................................................................................................................15
III-1-4 - Configuration d'un serveur primaire pour une prise en charge de transferts de zone....................... 16
III-1-5 - Configuration d'un serveur secondaire.............................................................................................. 16
III-2 - Service DNS dynamique............................................................................................................................ 17
III-2-1 - Généralités......................................................................................................................................... 17
III-2-2 - DHCP ou Dynamic Host Control....................................................................................................... 17
III-2-3 - Configuration du serveur DNS...........................................................................................................20
III-2-4 - Opérations post-configuration............................................................................................................ 20
III-2-5 - Mise en place d'un DNS dynamique sécurisé...................................................................................20
III-3 - Sécurisation d'un serveur DNS.................................................................................................................. 23
III-4 - Quelques paramètres de sécurisation du serveur DNS BIND................................................................... 23
III-4-1 - Sécurisation de la récursion.............................................................................................................. 23
III-4-2 - Autres paramètres de sécurité.......................................................................................................... 24
Conclusion..................................................................................................................................................................24
-2-
Les sources présentées sur cette pages sont libres de droits, et vous pouvez les utiliser à votre convenance. Par contre la page de présentation
de ces sources constitue une oeuvre intellectuelle protégée par les droits d'auteurs. Copyright © 2009 - Guillaume Sigui. Aucune reproduction,
même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de
l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts.
http://siguillaume.developpez.com/tutoriels/linux/installation-configuration-serveur-dns-sous-linux/
Introduction
Les réseaux informatiques ont franchi plusieurs étapes dans leur évolution jusqu'à ce qu'on soit au résultat actuel.
L'une des étapes fondamentales de cette évolution a été l'invention et la mise en �uvre du concept de noms de
domaine. Cette étape a d'ailleurs marqué l'ascension d'internet, et a davantage facilité les communications sur toute
la toile.
Ce tutoriel aborde ce concept. Tous les aspects généraux seront abordés, de même que l'installation et la
configuration de cet outil dans un environnement Linux.
Tous les tests de ce tutoriel ont été effectués sous la distribution Debian.
I - GENERALITES
I-1 - Avènement des noms de domaine
Les ordinateurs sur le réseau IP sont à la base identifiés à partir de leur adresse IP. Ces adresses sont une
concaténation de plusieurs nombres compris entre 0 et 255. Les nombres sont séparés par un point. On a par
exemple : 192.168.0.37 (IPv4). Retenir les identifiants des machines est alors devenu une tâche difficile, surtout que
leur nombre est de plus en plus grand.
C'est pour faciliter les choses que le principe de noms de domaine a été adopté. En fait, il s'agit d'attribuer des noms
simples aux machines. Ce principe devrait obéir aux règles fondamentales suivantes :
• à chaque nom, correspond une adresse IP ;

• dans un même réseau, un nom ne doit pas être porté par deux machines (adresses IP) différentes ;
• tous les ordinateurs dans le réseau doivent se reconnaître entre eux par leur nom.
I-2 - Définition d'un serveur DNS
Le Domain Name System (ou DNS, système de noms de domaine) est un système permettant d'établir une
correspondance entre une adresse IP et un nom de domaine, mais plus généralement de trouver une information à
partir d'un nom de domaine. Le serveur qui gère cette correspondance, sur un réseau, est désigné par serveur DNS.
Avant le DNS, la résolution se faisait grâce à un fichier texte appelé hosts, local à chaque ordinateur. Sous UNIX
et ses dérivés, il se trouve dans le répertoire /etc. Sous Windows, il se trouve, par défaut, dans %SystemRoot%
\system32\drivers\etc. Dans ce fichier, chaque ligne correspond à une adresse IP à laquelle peuvent être associés
un ou plusieurs noms de domaine. Il est ainsi évident que ce système pose un problème de maintenance car le fichier
doit être recopié sur tous les ordinateurs du réseau.
A l'échelle internet, le fichier hosts était fourni et géré par Arpanet.
Pour palier les insuffisances du système précédent, le DNS fait son apparition en 1983 avec Paul Mockapetris, qui
en implémenta la première version alors qu'il travaillait à l'Information Sciences Institute (ISI) de l'Université de
la Californie du Sud.
DNS, est aussi un protocole qui est rattaché aux RFC 882, 883, 1034 et 1035. (RFC=Request For Comment,
documents de l'IETF (Internet Engineering Task Force) définissant les standards d'Internet.)
Pour le transport des données, le DNS utilise par défaut, le port 53. Les requêtes sont acheminées sous la forme de
datagrammes UDP et les transferts de zone sont effectués en TCP.
-3-
I-3 - Quelques notions fondamentales
I-3-1 - Notion de domaine
Un domaine est un ensemble d'ordinateurs reliés dans un réseau, par exemple internet et possédant une
caractéristique commune. Le domaine est identifié à un nom, appelé nom de domaine. Ce nom est constitué d'au
moins un mot appelé label.
Dans une famille, tous les enfants ont dans leur nom complet, un nom qui vient du père. C'est la même logique pour
le nom de domaine, où même un domaine, porte dans son nom le nom du domaine supérieur dont il appartient.
Dans la nomenclature d'un nom de domaine, le domaine supérieur est écrit à droite, et le caractère point (.) sépare
le nom du domaine supérieur du nom du domaine inférieur.
Un domaine appartenant à un autre est aussi appelé sous-domaine de ce domaine.
I-3-2 - Notion d'hôte
Chaque domaine contient des ordinateurs ou des serveurs. Ce sont eux les hôtes. Les hôtes sont les points finaux
de la chaîne. Leurs noms sont qualifiés de Fully Qualified Domain Name (FQDN), c'est-à-dire Nom de Domaine
Totalement Qualifié.
La profondeur maximale autorisée pour atteindre l'hôte est de 127 niveaux, et la taille maximale du FQDN est de
255 caractères.
I-3-3 - Notion de zone
Une zone est une portion d'un domaine dont l'administration est déléguée à une entité faisant partie ou non de
l'organisation.
Le concept de zone est purement au niveau administratif. La déclaration des machines dans un domaine se fait dans
les zones. Le fichier qui contient les enregistrements des machines d'une zone est appelée fichier de zone.
I-4 - Architecture de fonctionnement sur internet
Le fonctionnement d'internet est assuré par plusieurs serveurs DNS qui interagissent entre eux. Comme présenté
en I.1, tous les serveurs (web, messagerie, téléchargement, etc.) sont à la base étiquetés avec leur adresse IP. La
facilité d'accéder avec un nom commode est donnée par l'interaction des différents serveurs DNS à travers le monde.
Alors comment fonctionnent ils ?
Deux aspects sont à considérer : l'aspect logique et l'aspect physique.
I-4-1 - Architecture logique de fonctionnement
D'un point de vue logique, les noms de domaine sont agencés dans une arborescence, voire une hiérarchie. On a
au sommet une racine, et une arborescence de noeuds.
-4-
Architecture logique de fonctionnement du DNS sur internet
La racine est un point. Elle est gérée par l'ICANN (Internet Corporation for Assigned Names and Numbers). Tous
les n�uds fils de la racine sont administrés par cette organisation. Ces n�uds sont appelés Top Level Domain ou
TLD. En français, ça donne : domaine de premier niveau.
On distingue trois principaux types de TLD :
• le TLD spécial .arpa

• les TLD géographiques ou nationaux
• les TLD génériques
* Le TLD spécial : c'est un domaine exploité exclusivement pour à des fins techniques. ARPA signifie Address and
Routing Parameters Areas, qui veut dire zone des paramètres d'adressage et de routage.
* Les TLD géographiques ou nationaux (cTLD= Country TLD): ce sont des TLD propres à chaque pays du monde.
Tous les pays en possèdent un. De façon nationale, ils sont gérés par des bureaux accrédités.
La liste de tous les TLD géographiques est contenue dans les tableaux ci-dessous. Il y en a 250.
-5-
.ac
.ad
.ae
.af
.ag
.ai
.al
.am
.an
.ao
.aq
.ar
.as
.at
.au
.aw
.ax
.az
.ga
.gb
.gd
.ge
.gf
.gg
.gh
.gi
.gl
.gm
.gn
.gp
.gq
.gr
.gs
.gt
.gu
.gw
.gy
-6-
.na
.nc
.ne
.nf
.ng
.ni
.nl
.no
.np
.nr
.nu
.nz
.om
.pa
.pe
.pf
.pg
.ph
.pk
.po
.pm
.pn
.pr
.ps
.pt
.pw
.py
.qa
.re
.ro
.rs
.ru
.rw
* Les TLD génériques ou gTLD (Generic TLD): ce sont les autres TLD. On les considère comme 'libres'
contrairement aux précédents. Ils sont généralement utilisés par les structures internationales telles que les
multinationales, les institutions, les organismes non gouvernementales, etc.
La liste totale des TLD génériques valides en Avril 2009 est présentée dans le tableau ci-dessous. Il y en a 15.
-7-
TLD Généralement utilisé par

.com les entreprises à vocation commerciale, mais devenu le plus utilisé, même par d'autres types de
structures
.edu les organismes éducatifs (universités, écoles, etc.)
.gov les organismes gouvernementaux
.int les organisations et institutions internationales
.mil les organismes militaires
.net les organismes travaillant dans le réseau, mais devient de plus en plus utilisé comme le .com
.org les structures à but non lucratif
.aero les industries aéronautiques
.biz les entreprises commerciales
.museum les musées
.name les noms de personnages historiques, contemporains ou imaginaires
.info les organisations travaillant dans le secteur de l'information
.coop les coopératives
.pro les professions libérales
.tel les accès simples et centralisés aux coordonnées d'une structure ou même d'un individu (le plus
récemment crée : ouvert au grand public depuis le 24 Mars 2009).
I-4-2 - Gestion des requêtes DNS sur internet
Quand un ordinateur connecté à internet veut se connecter à un site distant à partir du nom DNS, cela est traduit par
une requête DNS qui consiste à résoudre le nom de domaine de ce site.
Pour résoudre ce nom, celui-ci sera lu de la droite vers la gauche. Le premier serveur DNS à être contacté résout le
nom ou renvoie la requête à un autre serveur de niveau supérieur, et ainsi de suite.
A l'échelle d'internet, le DNS est une base de données distribuée sur plusieurs milliers de serveurs. Cette base de
données porte sur les correspondances entre adresses IP et noms de domaines ou noms d'hôtes. Chaque serveur
contient une partie de ces informations. Pour effectuer une correspondance entre un nom et une adresse IP, le serveur
DNS regarde dans sa base, si elle n'y est pas, il transfère la demande aux autres serveurs. Mais pour réduire le
trafic sur internet, les serveurs DNS gardent en cache, les noms de domaine déjà résolus, pendant un certain délai
avant de les rafraîchir.
I-4-3 - Serveurs racines du DNS et serveurs du domaine de premier niveau
Les serveurs racines du DNS sont les serveurs DNS qui gèrent les requêtes envoyées au TLD et qui les redirigent
vers le serveur du TLD concerné.
Comme mentionné au point précédent, les noms de domaine sont lus de la droite vers la gauche pour être résolu.
De façon implicite, l'élément le plus à droite dans un nom de domaine est le caractère point (.). Il est complété par
les logiciels serveurs DNS.
A la base, il existe treize serveurs racines du DNS dans le monde, mais n'importe quel opérateur peut en implémenter
un. Ces treize serveurs sont ceux qui implémentent le DNS de façon officielle. Ils connaissent tous les domaines de
premier niveau. Quand une requête leur parvient, il la transfère au serveur du TLD concerné, et celui-ci la redirige
vers le sous-domaine approprié et ainsi de suite jusqu'à ce que le nom soit entièrement résolu.
Par exemple, on veut se connecter à l'hôte siguillaume.developpez.com.
Quand cette requête parvient à un serveur racine de DNS, il contacte le serveur du domaine de premier niveau .com,
celui redirige la requête vers le serveur qui gère son sous-domaine developpez.com, et le serveur du sous-domaine
identifie l'hôte siguillaume.developpez.com.
Ce parcours est représenté par le schéma suivant :
-8-
Résolution du nom de domaine à partir du serveur racine
La nomenclature des treize serveurs de racine du DNS est présentée par une lettre de l'alphabet comprise entre a
et m, qui est placé à gauche des labels : root-servers.net. Le tableau ci-dessous donne leur liste complète.
Nom Adresse IPv4 Localisation Société Logiciel

a.root-servers.net 198.41.0.4 Dulles (Virginie / États-Unis) VeriSign BIND
b.root-servers.net 192.228.79.201 Marina Del Rey (Californie / VeriSign BIND
États-Unis)
c.root-servers.net 192.33.4.12 trafic distribué par anycast Cogent BIND
Communications
d.root-servers.net 128.8.10.90 College Park (Maryland / Etats- Université du BIND
Unis) Maryland
e.root-servers.net 192.203.230.10 Mountain View (Californie / Etats- NASA BIND
Unis)
f.root-servers.net 192.5.5.241 trafic distribué par anycast ISC BIND
g.root-servers.net 192.112.36.4 Columbus (Ohio / Etats-Unis) Defense BIND
Information
-9-
Systems
Agency
h.root-servers.net 128.63.2.53 Aberdeen (Maryland / Etats-Unis) U.S. Army NSD
Research Lab
i.root-servers.net 192.36.148.17 trafic distribué par anycast Autonomica BIND
j.root-servers.net 192.58.128.30 trafic distribué par anycast VeriSign BIND
k.root-servers.net 193.0.14.129 trafic distribué par anycast RIPE-NCC NSD
l.root-servers.net 199.7.83.42 trafic distribué par anycast ICANN NSD
m.root-servers.net 202.12.27.33 trafic distribué par anycast WIDE Project BIND
Comme présenté dans le tableau, la plupart de ces serveurs peuvent être localisés géographiquement, mais certains
sont distribués par anycast (technique d'adressage et de routage permettant de rediriger les données vers le serveur
le plus proche).
I-4-4 - Serveurs du domaine de deuxième niveau et notions de registre
Les serveurs du domaine de deuxième niveau sont les serveurs qui gèrent les sous-domaines des TLD. Chaque
TLD connait tous ces sous-domaines. Pour cela, tous les sous-domaines d'un TLD sont gérés (créés, modifiés et
supprimés) dans une base de données appelée registre de noms de domaine. En plus de contenir les noms des sous-
domaines, les registres ont aussi les références des autorités qui maintiennent chacun d'eux (cf notion de zone).
Les registres sont tenus par des organisations fonctionnant comme des NIC (Network Information Center). Ces
organisations peuvent des agences gouvernementales, des fournisseurs d'accès à internet, etc.
Certains registres vendent ou louent directement des noms aux utilisateurs, mais par souci de décentralisation,
la plupart d'entre elles vendent par l'intermédiaire de registrars, qui ne sont rien d'autre que des bureaux
d'enregistrement et de vente de noms de domaine. Un même registrar peut vendre des sous-domaines de plusieurs
domaines différents.
I-5 - Architecture de fonctionnement sur intranet
Selon le même principe que sur internet, le serveur DNS peut être aussi utilisé dans un intranet pour faciliter
l'exploitation et la maintenance du réseau. Les possibilités offertes en intranet sont :
• l'administrateur peut donner n'importe quel TLD, et n'importe quel nom à cette adresse, vu que l'intranet est
indépendant d'internet ;
• chaque machine du réseau local peut avoir un nom qui lui est propre.
I-6 - Fonctionnement interne du serveur
Il ne s'agit pas ici de décrire l'architecture de fonctionnement des serveurs DNS entre eux, mais plutôt de présenter
les différentes étapes que suit un serveur DNS pour reconnaitre l'adresse IP d'une machine à partir d'un nom de
domaine donné. Pour mieux comprendre, le fonctionnement présenté ici est spécifique à un cas de fonctionnement
en intranet. Sur internet, le fonctionnement est analogue avec d'autres traitements tels que le transfert de requêtes
entre serveurs, mais surtout la sécurisation : le III et le IV traite de ces détails.
Le fonctionnement interne du DNS suit les étapes ci-dessous.
1 Il faut d'abord comprendre que le serveur DNS lit un fichier principal duquel il tire les instructions qu'il doit
suivre.
2 C'est dans ce fichier que sont déclarés tous les fichiers de zone. Ce sont les fichiers de zone qui assurent la
correspondance les noms de domaines et les adresses IP. Ils sont classés en deux catégories : les fichiers de
résolution directe et les fichiers de résolution inverse.
1 Les fichiers de résolution directe permettent de retrouver l'adresse IP du serveur à partir d'un nom de
domaine. Généralement, les fichiers de résolution directe suffisent pour un fonctionnement minimal du
serveur DNS.
- 10 -
2 Les fichiers de résolution inverse permettent de retrouver les noms de domaine liés à une adresse IP
donnée.
3 La machine doit être reconnue comme serveur DNS par les autres machines du réseau y compris elle-même.
Il faut donc l'inscrire comme tel sur les autres machines.
II - INSTALLATION ET CONFIGURATION DE BASE
II-1 - Paquet d'installation
Le paquetage qui régit l'installation du serveur DNS sous Linux s'appelle bind. Il existe déjà en plusieurs versions.
Il faut aussi dire qu'il existe d'autres paquets qui implémentent le DNS, bind est le plus connu et le plus utilisé. La
version courante est le 9.
II-2 - Installation
Comme tout paquet linux, il existe trois méthodes d'installation, qui sont décrites ici avec le cas d'Apache. Par
exemple, sous Debian, on lance la commande: apt-get install bind9
Après installation, les répertoires /etc/bind/ et /var/bind/ (ou /var/cache/bind/) sont créés. (Ils peuvent être différents
sous d'autres distributions). Ils contiennent les fichiers qui assurent le fonctionnement du serveur DNS.
II-3 - Configuration de base
II-3-1 - Problématique
Problème
Créer dans un intranet un domaine sigui.ci. La machine qui doit héberger ce domaine à pour adresse IP 192.168.1.10.
Sur ce domaine, sera mis en place deux sous-domaines l'un pour l'hébergement d'un site web :www.sigui.ci, et
l'autre pour héberger un serveur de messagerie : mail.sigui.ci .
Résolution
Comme décrit dans l'architecture de fonctionnement interne, résoudre ce problème, c'est d'abord configuré le fichier
principal puis paramétrer les différents fichiers de zone.
II-3-2 - Configuration du fichier principal
Le fichier principal de configuration de notre serveur est named.conf. Il se situe dans le répertoire /etc/bind/. Cela
peut changer selon les distributions. Debian, par exemple, fait la répartition de la configuration entre plusieurs fichiers.
* Paramètres de configuration de base:

Les principaux paramètres de configuration sont :
PARAMETRE EXPLICATION
options ouvre les balises pour les options générales de configuration
directory pour définir le dossier dans lequel sera sauvegardé les fichiers de zone
query-source le port d'écoute du serveur
forward option de transfert de la requête vers un autre serveur
forwarders serveur DNS de réception des requêtes transférées
zone ouvre les balises pour la configuration d'une zone
type type de la zone
file fichier de configuration de la zone
- 11 -
Pour obtenir la liste globale de tous les paramètres d'options du BIND, cliquez ici.
* Exemple de configuration (résolution du problème posé):

A l'installation, le fichier named.conf existe déjà avec un contenu. Les options générales y sont déjà définies. On
a par exemple :
options {
directory "/var/bind";
query-source port 53;
forward only;
forwarders { x.x.x.x;};
};
Au contenu existant du fichier principal, on ajoute les lignes suivantes :
#Déclaration du fichier de résolution directe
zone "sigui.ci" in {
type master ;
file "/var/bind/sigui.ci.direct.db" ;
#Déclaration du fichier de résolution inverse
zone "1.168.192.in-addr.arpa" in {
type master ;
file "/var/bind/sigui.ci.reverse.db";
Remarque
La nomenclature des fichiers de résolution dépendent exclusivement de celui qui configure. Il doit pouvoir les
reconnaitre facilement.
II-3-3 - Configuration des fichiers de zone
Le répertoire /var/bind/ a certes, été crée pendant l'installation de bind, mais il ne contient encore aucun fichier.
Il faudra alors y créer les fichiers de zone sigui.ci.direct.db et sigui.ci.reverse.db, puis définir les paramètres de
configuration de la zone (domaine) sigui.ci.
* Paramètres de configuration des fichiers de zone
- 12 -
Les principaux paramètres de configuration des fichiers de zone sont :
SOA Start Of Authority : démarre la configuration d'une zone. C'est la délégation d'autorité.
TTL Time To Live : durée de vie du SOA
Serial Numéro de version du fichier, sert à la synchronisation. Généralement, on écrit la date de
création de la zone pour composer ce numéro.
Refresh Intervalle de temps pour le rafraichissement, sert aussi à la synchronisation entre des
serveurs primaires et secondaires, par exemple.
Retry Fréquence de ressaie en cas d'échec des rafraichissements. Utilisé par les serveurs
secondaires.
Expire Principalement utilisé par un serveur secondaire, c'est le temps maximal pendant les
informations reçues d'un serveur primaire reste valide.
Negative Cache TTL Durée de vie, par défaut dans le cache d'un serveur qui n'a pas d'autorité sur cette zone.
IN Désigne l'allocation. Commande utilisé pour attribuer les valeurs aux options.
NS Pour définir le nom du serveur de nom de la zone.
A Pour attribuer un nom à une machine à partir de son adresse IP.
MX Pour définir un serveur de messagerie, la valeur de ce paramètre est accompagnée de la
priorité (préférence) de ce serveur.
CNAME C'est une option pour donner un alias à une machine déjà définit avec A.
HINFO Description d'un hôte, d'une machine.
TXT Chaine de caractères, utilisé pour des commentaires
PTR Utilisé dans le fichier de résolution inverse, permet d'associer l'adresse IP à un nom.
* Exemple de configuration des fichiers (résolution du problème posé)
Après leur création, ces fichiers doivent être édités de la façon suivante :
Le premier fichier (résolution directe) sigui.ci.direct.db :
$TTL 604800
;on délègue l'administration de cette zone à root@sigui.ci
;@ est remplacé par '.' Dans l'adresse du root
@ IN SOA sigui.ci. root.sigui.ci. (
20080605 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; Serveur de noms
@ IN NS sigui.ci.
; Les serveurs
www IN A 192.168.1.10
mail IN A 192.168.1.10
mail IN MX 10 mail.sigui.ci.
- 13 -
Le deuxième fichier (résolution inverse) sigui.ci.reverse.db
$TTL 604800
1.168.192.in-addr.arpa IN SOA sigui.ci. root.sigui.ci. (
20080605 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; Serveur de noms
@ IN NS sigui.ci.
; Les machines et les serveurs
10 IN PTR mail.sigui.ci.
10 IN PTR www.sigui.ci.
N.B: Dans les fichiers de configuration des zones, le caractère point virgule ( ;) précède les commentaires.
II-4 - Opérations post-configurations
Après cette configuration, deux opérations déterminantes sont à poser :
• redémarrer le serveur DNS

• inscrire le serveur comme DNS préféré des machines clientes. Le serveur lui-même doit aussi être configuré
comme son propre client.
II-4-1 - Redémarrage du serveur
La commande de démarrage du serveur varie d'une distribution à une autre.

Sous RedHat et Fedora : /etc/rc.d/init.d/bind9 start
Sous Debian : /etc/init.d/bind9 start
II-4-2 - Inscription du serveur
Le serveur DNS doit être reconnu par les autres machines comme tel.
Pour les machines du réseau sous Windows :

1-> Aller dans Connexions Réseaux
2-> Choisir Réseau Local
3-> Entrer dans les propriétés du réseau local
4-> Choisir Protocole internet TCP/IP
5-> Ecrire l'adresse IP de la machine qui héberge le serveur DNS dans les champs requis
6-> Valider toutes ses modifications
Pour les machines du réseau sous Linux, il s'agit d'éditer le fichier /etc/resolv.conf selon l'exemple suivant :
- 14 -
search sigui.ci
nameserver 192.168.37.240
Il est aussi possible de le faire via une interface graphique sous Linux. Mais la procédure à suivre diffère d'une
distribution à une autre.
II-4-3 - Tests de configuration
Il faut maintenant tester le fonctionnement du serveur. Il existe deux principaux utilitaires qui le permettent : nslookup
et dig.
• nslookup permet de retrouver l'adresse IP d'une machine à part de son nom DNS, et l'inverse. Il faut
préciser que cela est propre à un réseau bien donné. Le premier serveur DNS interrogé est celui-ci spécifié
dans l'inscription. Sous UNIX, nslookup est de plus en plus obsolète, mais il reste encore d'actualité sous
Windows. Un exemple de résultat obtenu avec nslookup est :
$ nslookup
> www.sigui.ci
Server: 192.168.1.10
Address: 192.168.1.10#53
• dig : analogue à nslookup, il permet de spécifier le type de serveurs ou de machines qu'on veut contacter.
Par exemple : dig MX mail.sigui.ci
III - ASPECTS AVANCES DE LA CONFIGURATION
III-1 - Serveur primaire et serveur secondaire
III-1-1 - Définitions
• 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.
III-1-2 - Avantages
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.
III-1-3 - Transfert de zones
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.
- 15 -
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.
III-1-4 - Configuration d'un serveur primaire pour une prise en charge de transferts de zone
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:
allow-transfer On y inscrit les adresses IP des serveurs secondaires autorisés à faire des transferts de
zone à partir du serveur.
allow-notify On y inscrit les adresses IP des serveurs secondaires à notifier en cas de modification des
données.
notify Paramètre d'activation de la notification. On le met à oui ou non (yes/no)
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 :
type master ;
allow-transfer { 192.168.1.20; 192.168.1.25 ; };
allow-notify { 192.168.1.20; 192.168.1.25 ; };
notify yes ;
Et on reproduit les mêmes paramètres dans la déclaration du fichier de résolution inverse.
III-1-5 - Configuration d'un serveur secondaire
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 :
- 16 -
type slave ;
masters {192.168.1.10;};
notify no ;
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.
III-2 - Service DNS dynamique
III-2-1 - Généralités
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
III-2-2 - DHCP ou Dynamic Host Control
* 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
- 17 -
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
update-static-leases on;
# Les clients du réseau seront tous reconnus même
# si on ne connaît pas leur adresse mac.
allow unknown-clients;
# Durée de vie du bail (un jour=86400s)
max-lease-time 86400;
default-lease-time 86400;
# Les options qui seront transmisent aux clients :
#le domaine et la passerelle
option domain-name-servers 192.168.1.10;
option domain-name "sigui.ci";
option routers 192.168.1.1;
# La définition de la plage d'IP à distribuer.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.1.11 192.168.1.254;
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
ddns-update-style interim;
#Autorisation de la mise à jour
ddns-updates on;
- 18 -
#Forçage de la mise à jour que par le DHCP, les autres
#sources de modifications sont ignorées
ignore client-updates;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.1.11 192.168.1.254;
#Balises à mettre en fin de ligne pour spécifier le DNS
#à mettre à jour pour ces jours : optionnel, mais recommandé
zone sigui.ci. {
primary 192.168.1.10;
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.10;
- 19 -
III-2-3 - Configuration du serveur DNS
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 :
type master ;
allow-update { 192.168.1.5 ;} ;
type master ;
allow-update { 192.168.1.5 ;} ;
III-2-4 - Opérations post-configuration
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
III-2-5 - Mise en place d'un DNS dynamique sécurisé
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
#On inclut le fichier de clé
include " /etc/rndc.key" ;
#Définition de la méthode de mise à jour
- 20 -
ddns-update-style interim;
#Autorisation de la mise à jour
ddns-updates on;
#Forçage de la mise à jour que par le DHCP, les autres
#sources de modifications sont ignorées
ignore client-updates;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.1.11 192.168.1.254;
#Balises à mettre en fin de ligne pour spécifier le DNS
- 21 -
#à mettre à jour pour ces jours : très recommandé pour le
#décodages des clés
zone sigui.ci. {
primary 192.168.1.10;
key rndckey;
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.10;
key rndckey;
* Configuration du serveur DNS
type master ;
allow-update { key rndckey ;} ;
type master ;
allow-update { key rndckey ;} ;
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
- 22 -
III-3 - Sécurisation d'un serveur DNS
Vu leur importance, les serveurs DNS sont sujets à différents types d'attaques. Le tableau ci-dessous présente les
connus avec des recommandations de sécurité :
Menaces Recommandations
Deny of Service ou DoS (en français Déni de Service): c'est une Limiter à un nombre restreint de réseaux
surcharge de requêtes sur le serveur DNS, qui l'empêche de fournir les requêtes auxquelles doivent répondre le
le service pour lequel il est mis en place : résoudre les noms de serveur DNS.
machines. Utiliser le principe de cryptage avec clé pour
les mises à jour dynamiques.
Footprinting : il s'agit d'une attaque qui consiste à intercepter les N'autoriser le transfert de zones qu'à des
informations sur une zone et même un domaine: les noms et les serveurs DNS connus.
adresses IP des machines de cette zone. Cela permet aux pirates
de mieux planifier leurs attaques sur les ordinateurs du réseau.
Redirection de paquets : c'est une technique par laquelle un N'échanger qu'avec des clients DNS d'un
intrus intercepte des requêtes de résolution de noms adressées au réseau connu, et restreindre l'accès en
serveur, et les redirige vers d'autres serveurs DNS, par exemple écriture sur les données.
ceux dont il a le contrôle. Utiliser le principe de cryptage avec clé pour
les mises à jour dynamiques.
III-4 - Quelques paramètres de sécurisation du serveur DNS BIND
III-4-1 - Sécurisation de la récursion
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:
Paramètres Fonctionnalités
acl Liste de contrôle d'accès. Il permet de définir les réseaux ou les ordinateurs dont on autorise la
résolution des requêtes.
view Mécanisme de vue, qui permet d'autoriser les ordianteurs ou réseaux à prendre en compte. Les
deux valeurs les plus utilisées sont internal et external.
Ces deux valeurs sont logiques, et ne sont pas forcément en rapport avec l'architecture du
réseau en présence.
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
- 23 -
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";
};
III-4-2 - Autres paramètres de sécurité
Il existe des dizaines de paramètres pour circonscrire la sécurité dans la configuration du BIND. Les plus utilisés ont:
Paramètres Fonctionnalités Exemples de configuration

blackhole Principe de black list: on définit les adresses auxquelles blackhole {liste-adresses}
le serveur ne doit pas répondre. Très pratique lorsque liste-adresses peut être une plage
l'administrateur a détecté des adresses qui ont tenté des d'adresses qu'on définit; ou une liste
attaques sur le serveur. de plusieurs adresses.
recursion- Permet de définir le nombre de requêtes simultanées recursion-clients 500
clients auxquelles le serveur doit répondre. Sur BIND 9, cette
valeur est par défaut à 1000.
Conclusion
L'importance du DNS dans un réseau informatique n'est plus à démontrer. Ce tutoriel a présenté ce maillon fort dans
tous ces aspects généraux et a montré les différentes configurations possibles. Vu que le DNS connait beaucoup
d'évolutions, ce tutoriel sera régulièrement mis à jour pour présenter les différentes possibilités.
Je tiens à remercier tout ceux qui ont apporté leur apport à l'édition de ce tutoriel.
- 24 -

Dns Linux

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dns Linux

Uploaded by

Copyright:

Available Formats

Installation et configuration

d'un serveur DNS sous Linux

par Guillaume Sigui (Page d'accueil) (Blog)

Date de publication : 22 Avril 2009

Dernière mise à jour : 14 Décembre 2009

I-1 - Avènement des noms de domaine

• à chaque nom, correspond une adresse IP ;

I-2 - Définition d'un serveur DNS

I-3 - Quelques notions fondamentales

I-3-1 - Notion de domaine

I-3-2 - Notion d'hôte

I-3-3 - Notion de zone

I-4 - Architecture de fonctionnement sur internet

I-4-1 - Architecture logique de fonctionnement

Architecture logique de fonctionnement du DNS sur internet

• le TLD spécial .arpa

TLD Généralement utilisé par

I-4-2 - Gestion des requêtes DNS sur internet

I-4-3 - Serveurs racines du DNS et serveurs du domaine de premier niveau

Résolution du nom de domaine à partir du serveur racine

Nom Adresse IPv4 Localisation Société Logiciel

I-4-4 - Serveurs du domaine de deuxième niveau et notions de registre

I-5 - Architecture de fonctionnement sur intranet

I-6 - Fonctionnement interne du serveur

Le fonctionnement interne du DNS suit les étapes ci-dessous.

II - INSTALLATION ET CONFIGURATION DE BASE

II-1 - Paquet d'installation

II-3 - Configuration de base

II-3-2 - Configuration du fichier principal

* Paramètres de configuration de base:

* Exemple de configuration (résolution du problème posé):

query-source port 53;

Au contenu existant du fichier principal, on ajoute les lignes suivantes :

#Déclaration du fichier de résolution directe

#Déclaration du fichier de résolution inverse

II-3-3 - Configuration des fichiers de zone

* Paramètres de configuration des fichiers de zone

Les principaux paramètres de configuration des fichiers de zone sont :

* Exemple de configuration des fichiers (résolution du problème posé)

;on délègue l'administration de cette zone à root@sigui.ci

;@ est remplacé par '.' Dans l'adresse du root

@ IN SOA sigui.ci. root.sigui.ci. (

604800 ) ; Negative Cache TTL

Le deuxième fichier (résolution inverse) sigui.ci.reverse.db

1.168.192.in-addr.arpa IN SOA sigui.ci. root.sigui.ci. (

604800 ) ; Negative Cache TTL

; Les machines et les serveurs

II-4 - Opérations post-configurations

Après cette configuration, deux opérations déterminantes sont à poser :

• redémarrer le serveur DNS

II-4-1 - Redémarrage du serveur

La commande de démarrage du serveur varie d'une distribution à une autre.

II-4-2 - Inscription du serveur

Pour les machines du réseau sous Windows :

II-4-3 - Tests de configuration

III - ASPECTS AVANCES DE LA CONFIGURATION

III-1 - Serveur primaire et serveur secondaire

III-1-3 - Transfert de zones

#Déclaration du fichier de résolution directe

allow-transfer { 192.168.1.20; 192.168.1.25 ; };

allow-notify { 192.168.1.20; 192.168.1.25 ; };

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

III-1-5 - Configuration d'un serveur secondaire