Installation et configuration d'un serveur DNS sous Linux

Guillaume Sigui

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.

- Titre : Installation et configuration d'un serveur DNS sous Linux

- Auteur : Guillaume Sigui

- Parution : 22 avril 2009

- Mise à jour : 14 décembre 2009

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. 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'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- Introduction

- I. GENERALITES

- I-1. Avènement des noms de domaine

- 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

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

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

- 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

- II. INSTALLATION ET CONFIGURATION DE BASE

- II-1. Paquet d'installation

- II-2. Installation

- II-3. Configuration de base

- II-3-1. Problématique

- II-3-2. Configuration du fichier principal

- II-3-3. Configuration des fichiers de zone

- II-4. Opérations post-configurations

- II-4-1. Redémarrage du serveur

- II-4-2. Inscription du serveur

- II-4-3. Tests de configuration

- III. ASPECTS AVANCES DE LA CONFIGURATION

- III-1. Serveur primaire et serveur secondaire

- III-1-1. Définitions

- III-1-2. Avantages

- III-1-3. Transfert de zones

- III-1-4. Configuration d'un serveur primaire pour une prise en charge de transferts de zone

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

- III-2. Service DNS dynamique

- III-2-1. Généralités

- III-2-2. DHCP ou Dynamic Host Control

- III-2-3. Configuration du serveur DNS

- III-2-4. Opérations post-configuration

- III-2-5. Mise en place d'un DNS dynamique sécurisé

- III-3. Sécurisation d'un serveur DNS

- III-4. Quelques paramètres de sécurisation du serveur DNS BIND

- III-4-1. Sécurisation de la récursion

- III-4-2. Autres paramètres de sécurité

- Conclusion

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.

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.

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.

Liste des TLD nationaux commençant par A-B-C-D-E-F

TLD

Pays

TLD

Pays

TLD

Pays

TLD

Pays

.ac

Ile de l'Ascension

.ba

Bosnie-Herzégovine

.ca

Canada

.de

Allemagne

.ad

Andorre

.bb

Barbade

.cc

Îles Cocos

.dj

Djibouti

.ae

Emirates Arabes Unis

.bd

Bangladesh

.cd

République Démocratique du Congo

.dk

Danemark

.af

Afghanistan

.be

Belgique

.cf

République Centrafricaine

.dm

Dominique

.ag

Antigua et Barbuda

.bf

Burkina Faso

.cg

Congo Brazzaville

.do

République dominicaine

.ai

Anguilla

.bg

Bulgarie

.ch

Suisse

.dz

Algérie (El Djazaïr)

.al

Albanie

.bh

Bahreïn

.ci

Côte d'Ivoire

.ec

Equateur

.am

Arménie

.bi

Burundi

.ck

Îles Cook

.ee

Estonie

.an

Antilles Néerlandaises

.bj

Bénin

.cl

Chili

.eg

Egypte

.ao

Angola

.bm

Bermudes

.cm

Cameroun

.eh

Sahara Occidental

.aq

Antarctique

.bn

Brunei

.cn

Chine

.er

Erythrée

.ar

Argentine

.bo

Bolivie

.co

Colombie

.es

Espagne

.as

Samoa Américaines

.br

Brésil

.co.uk

Royaume-Uni

.et

Ethiopie

.at

Autriche

.bs

Bahamas

.cr

Costa Rica

.eu

Union Européenne

.au

Australie et îles Ashmore, Carthier et Mer de Corail

.bt

Bhoutan

.cu

Cuba

.fi

Finlande

.aw

Aruba

.bv

Île Bouvet

.cv

Cap Vert

.fj

Fidji

.ax

Åland

.bw

Botswana

.cx

Île Christmas

.fk

Îles Malouines

.az

Azerbaïdjan

.by

Biélorussie

.cy

Chypre

.fm

Micronésie

.bz

Belize

.cz

République Tchèque

.fo

Îles Féroé

.fr

France

Liste des TLD nationaux commençant par G-H-I-J-K-L-M

TLD

Pays

TLD

Pays

TLD

Pays

TLD

Pays

.ga

Gabon

.hk

Hong-Kong

.ke

Kenya

.ma

Maroc

.gb

Grande Bretagne

.hm

Ile Heard et Iles McDonald

.kg

Kirghizstan

.mc

Monaco

.gd

Grenade

.hn

Honduras

.kh

Cambodge

.md

Moldavie

.ge

Géorgie

.hr

Croatie

.ki

Kiribati

.me

Monténégro

.gf

Guyane française

.ht

Haîti

.km

Union des Comores

.mg

Madagascar

.gg

Guernesey

.hu

Hongrie

.kn

Saint-Christophe-et-Niévès

.mh

Marshall

.gh

Ghana

.id

Indonésie

.kp

Corée du Nord

.mk

Macédoine

.gi

Gibraltar

.ie

Irlande

.kr

Corée du Sud

.ml

Mali

.gl

Groenland

.il

Israël

.kw

Kowëit

.mm

Birmanie

.gm

Gambie

.im

Ile de Man

.ky

Îles Caïmans

.mn

Mongolie

.gn

Guinée

.in

Inde

.kz

Kazakhstan

.mo

Macao

.gp

Guadeloupe

.io

Territoire britannique de l'Océan Indien

.la

Laos

.mp

Îles Mariannes du Nord

.gq

Guinée équatoriale

.iq

Iraq

.lb

Liban

.mq

Martinique

.gr

Grèce

.ir

Iran

.lc

Sainte-Lucie

.mr

Mauritanie

.gs

Géorgie du Sud et les îles Sandwich du Sud

.is

Islande

.li

Lichtenstein

.ms

Montserrat

.gt

Guatemala

.it

Italie

.lk

Sri Lanka

.mt

Malte

.gu

Guam

.je

Jersey

.lr

Libéria

.mu

Maurice

.gw

Guinée-Bissau

.jm

Jamaïque

.ls

Lesotho

.mv

Maldives

.gy

Guyana

.jo

Jordanie

.lt

Lituanie

.mw

Malawi

.jp

Japon

.lu

Luxembourg

.mx

Mexique

.lv

Lettonie

.my

Malaisie

.ly

Lybie

.mz

Mozambique

Liste des TLD nationaux commençant par N-O-P-Q-R-S-T-U-V-W-X-Y-Z

TLD

Pays

TLD

Pays

TLD

Pays

.na

Namibie

.sa

Arabie Saoudite

.ua

Ukraine

.nc

Nouvelle Calédonie

.sb

Salomon

.ug

Ouganda

.ne

Niger

.sc

Seychelles

.um

Îles mineures éloignées des Etats-Unis

.nf

Île Norfolk

.sd

Soudan

.us

Etats-Unis

.ng

Nigéria

.se

Suède

.uy

Uruguay

.ni

Nicaragua

.sg

Singapour

.uz

Ouzbékistan

.nl

Pays-Bas

.sh

Sainte-Hélène

.va

Vatican

.no

Norvège

.si

Slovénie

.vc

Saint-Vincent-et-les-Grenadines

.np

Népal

.sj

Svalbard et Jan Mayen

.ve

Venezuela

.nr

Nauru

.sk

Slovaquie

.vg

Îles vierges britanniques

.nu

Niue

.sl

Sierra-Léone

.vi

Îles vierges américaines

.nz

Nouvelle Zélande

.sm

Saint-Marin

.vn

Viêt Nam

.om

Oman

.sn

Sénégal

.vu

Vanuatu

.pa

Panama

.so

Somalie

.wf

Wallis-et-Futuna

.pe

Pérou

.sr

Suriname

.ws

Samoa

.pf

Polynésie Française

.st

Sao Tomé-et-Principe

.ye

Yémen

.pg

Papouasie-Nouvelle-Guinée

.su

CEI (Anciennement Union Soviétique)

.yt

Mayotte

.ph

Philippines

.sv

Salvador

.yu

Serbie

.pk

Pakistan

.sy

Syrie

.za

Afrique du Sud

.po

Pologne

.sz

Swaziland

.zm

Zambie

.pm

Saint-Pierre-et-Miquelon

.tc

Îles Turques et Caïques

.zw

Zimbabwe

.pn

Pitcairn

.td

Tchad

.pr

Porto Rico

.tf

Terres australes et antarctiques françaises

.ps

Autorité palestinienne (Cisjordanie et Bande de Gaza)

.tg

Togo

.pt

Portugal

.th

Thaïlande

.pw

Palaos

.tj

Tadjikistan

.py

Paraguay

.tk

Tokelau

.qa

Qatar

.tl

Timor oriental

.re

La Réunion

.tm

Turkménistan

.ro

Roumanie

.tn

Tunisie

.rs

Serbie

.to

Tonga

.ru

Russie

.tp

Timor oriental (anciennement Timor portugais)

.rw

Rwanda

.tr

Turquie

.tt

Trinité-et-Tobago

.tv

Tuvalu

.tw

Taïwan

.tz

Tanzanie

* 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.

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 :

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 / États-Unis)

VeriSign

BIND

c.root-servers.net

192.33.4.12

trafic distribué par anycast

Cogent Communications

BIND

d.root-servers.net

128.8.10.90

College Park (Maryland / Etats-Unis)

Université du Maryland

BIND

e.root-servers.net

192.203.230.10

Mountain View (Californie / Etats-Unis)

NASA

BIND

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 Information Systems Agency

BIND

h.root-servers.net

128.63.2.53

Aberdeen (Maryland / Etats-Unis)

U.S. Army Research Lab

NSD

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.

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

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 { <br/>
directory "/var/bind"; <br/>
query-source port 53; <br/>
forward only; <br/>
forwarders { x.x.x.x;}; <br/>
};

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/>
file "/var/bind/sigui.ci.direct.db" ;<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/>
}<br/>

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
Les principaux paramètres de configuration des fichiers de zone sont :

PARAMETRE

EXPLICATION

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<br/>
;on délègue l'administration de cette zone à root@sigui.ci<br/>
;@ est remplacé par '.' Dans l'adresse du root<br/>
@ IN SOA sigui.ci. root.sigui.ci. (<br/>
20080605 ; Serial<br/>
604800 ; Refresh<br/>
86400 ; Retry<br/>
2419200 ; Expire<br/>
604800 ) ; Negative Cache TTL<br/>
; Serveur de noms<br/>
@ IN NS sigui.ci.<br/><br/>
; Les serveurs<br/>
www IN A 192.168.1.10<br/>
mail IN A 192.168.1.10<br/>
mail IN MX 10 mail.sigui.ci.<br/>

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

$TTL 604800<br/>
1.168.192.in-addr.arpa IN SOA sigui.ci. root.sigui.ci. (<br/>
20080605 ; Serial<br/>
604800 ; Refresh<br/>
86400 ; Retry<br/>
2419200 ; Expire<br/>
604800 ) ; Negative Cache TTL<br/>
; Serveur de noms<br/>
@ IN NS sigui.ci.<br/>
; Les machines et les serveurs<br/>
10 IN PTR mail.sigui.ci.<br/>
10 IN PTR www.sigui.ci.<br/>

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 :

search sigui.ci<br/>
nameserver 192.168.37.240<br/>

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.
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:

PARAMETRE

EXPLICATION

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 :

#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.

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 :

#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.

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 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/>

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 :

#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/>

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

<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

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 surcharge de requêtes sur le serveur DNS, qui l'empêche de fournir le service pour lequel il est mis en place : résoudre les noms de machines.

Limiter à un nombre restreint de réseaux les requêtes auxquelles doivent répondre le serveur DNS.
Utiliser le principe de cryptage avec clé pour les mises à jour dynamiques.

Footprinting : il s'agit d'une attaque qui consiste à intercepter les informations sur une zone et même un domaine: les noms et les adresses IP des machines de cette zone. Cela permet aux pirates de mieux planifier leurs attaques sur les ordinateurs du réseau.

N'autoriser le transfert de zones qu'à des serveurs DNS connus.

Redirection de paquets : c'est une technique par laquelle un intrus intercepte des requêtes de résolution de noms adressées au serveur, et les redirige vers d'autres serveurs DNS, par exemple ceux dont il a le contrôle.

N'échanger qu'avec des clients DNS d'un réseau connu, et restreindre l'accès en écriture sur les données.
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
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 le serveur ne doit pas répondre. Très pratique lorsque l'administrateur a détecté des adresses qui ont tenté des attaques sur le serveur.

blackhole {liste-adresses}
liste-adresses peut être une plage d'adresses qu'on définit; ou une liste de plusieurs adresses.

recursion-clients

Permet de définir le nombre de requêtes simultanées auxquelles le serveur doit répondre. Sur BIND 9, cette valeur est par défaut à 1000.

recursion-clients 500

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.