Vous êtes sur la page 1sur 48

Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

DOMAIN NAME
SERVER (D.N.S.)

11/10/2009 Page 1 sur 48


23243440.doc
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

SOMMAIRE

1. INTRODUCTION..................................................................................................................3
1.1. Contexte de l'Etude....................................................................................................................3
1.2. But des Serveurs de Noms.........................................................................................................3
1.3. Différents Services de Noms......................................................................................................4
2. GENERALITES SUR LE DNS ...........................................................................................6
2.1. Définitions..................................................................................................................................6
2.2. Types d'Enregistrements.........................................................................................................14
2.3. Données Cachées......................................................................................................................17
2.4. Serveurs Itératifs et Serveurs Récursifs ................................................................................18
2.5. Serveur Primaire et Serveur Secondaire................................................................................19
2.6. Domaines Virtuels....................................................................................................................22
2.7. Sous Domaines.........................................................................................................................22
2.8. Serveur de Nom Local.............................................................................................................23
2.9. Station Cliente..........................................................................................................................23
2.10. Test du Serveur......................................................................................................................23
2.11. Protocole DNS........................................................................................................................24
2.12. Références DNS......................................................................................................................24
3. CONFIGURATION SOUS LINUX ...................................................................................25
3.1. Côté Serveurs...........................................................................................................................25
3.2. Côté Clients..............................................................................................................................35
3.3. Débogage du Serveur...............................................................................................................36
3.4. Sécurité.....................................................................................................................................39
3.5. Boîte à Outils............................................................................................................................40
4. CONCLUSION....................................................................................................................40
Annexe 1 : Administration locale avec Linuxconf ...............................................................41
Annexe 2 : Administration distante avec Webmin................................................................45
Ecran principal..............................................................................................................................45
Ecrans secondaires ........................................................................................................................46

11/10/09 23243440.doc 2
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

1. INTRODUCTION
1.1. Contexte de l'Etude
L'étude des Serveurs de Noms de Domaine est un vaste sujet, car il regroupe à travers le
temps plusieurs procédés (Wins, N.I.S., etc…) élaborés par des sociétés diverses, procédés
pouvant être mis en oeuvre sous des systèmes d'exploitation différents.
Cette étude suivante est volontairement restreinte au Système de Noms de Domaine (Domain
Name System ou DNS) dans le cadre de l'interconnexion des systèmes hétérogènes UNIX et
Windows NT.
Le service DNS fonctionne suivant le principe client-serveur. Il nécessite donc une station
configurée comme serveur. Ce serveur peut fonctionner aussi bien sous Windows NT que
sous UNIX.
La plupart des serveurs DNS fonctionnent sous UNIX. Aussi, le présent document est limité à
l'installation d'un serveur DNS sous LINUX. Il est néanmoins transposable sous n'importe
quelle version d'UNIX.

1.2. But des Serveurs de Noms


Ils ont pour but de simplifier la vie des utilisateurs qui lancent des requêtes à travers un
réseau reposant sur l'emploi des protocoles TCP/IP.
Le plan d’adressage IP V.4 (version 4) nécessite des nombres de 32 bits séparés en 4 octets.
Chaque octet, pouvant prendre une valeur de 0 à 255, est séparé du suivant par un point. La
représentation finale est donc de la forme 16.192.210.46.
Il est difficile de retenir plus de dix adresses IP différentes. L'utilisateur peut se constituer un
carnet d'adresses IP, mais l'emploi en est fastidieux et inefficace.
La mémoire de chacun est encore plus sollicitée dans le cas d'adresses IP version 6 où les
adresses comportent 16 octets.
Pour des raisons de simplicité, il a été décidé de faire correspondre à chaque adresse IP un
nom de machine (nom d'hôte ou hostname) beaucoup plus représentatif qu'une suite de
chiffres.

Le système DNS permet donc d’identifier une machine par un (des) nom(s) représentatif(s)
de la station et du (des) réseau(x) sur le(les)quel(s) elle se trouve ; par exemple :
st1.esat.terre.def identifie la station st1 sur le réseau esat.terre.def

Tous les programmes reposant sur l'emploi des protocoles TCP/IP doivent se connecter à
un service de résolution de noms pour que le nom d'ordinateur soit converti en adresse IP.
L'organisation d
es noms de domaine est gérée de manière centralisée par un organisme mondial : l’ICANN
(Internet Corporation for Assigned Names and Numbers), successeur de l'IANA (Internet
Assigned Number Authority
). Au vu de l'expansion démesurée du réseau Internet, l'ICANN a rapidement délégué ses
responsabilités auprès d'organismes continentaux ou nationaux comme RIPE (Réseaux IP

11/10/09 23243440.doc 3
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Européens), NIC France (Network Information Center), etc... L'acquisition d'un nom de
domaine s'effectue par l'intermédiaire d'organismes prestataires de ces organismes délégués
comme l'INRIA (Institut National de Recherche en Informatique et Automatique) pour le
domaine .fr.
Ce sujet n'est pas développé dans ce document, mais au sein du cours Internet.

1.3. Différents Services de Noms

1.3.1. Résolution Locale


Sur un réseau de petite taille, la résolution de noms sous UNIX peut se réaliser localement
grâce à un fichier hosts implanté sur chaque machine (il est situé sous /etc sous UNIX, sous
Winnt\system32\drivers\etc sous Windows NT4, sous \Windows pour Windows 98). Ceci
pose le problème de mise à jour de chaque machine chaque fois qu’on en intègre une nouvelle
dans le réseau.
Exemple de fichier /etc/hosts sous UNIX :
# Internet Address Hostname # Comments

127.0.0.1 loopback localhost

160.192.15.60 svraix1 aix1


160.192.15.61 svraix2 aix2
160.192.15.62 svrsnx snx
Les lignes commençant par le caractère "#" sont commentées, donc inactives.

1.3.2. Procédé NIS


Pour pallier ce problème, SUN a développé le procédé NIS (Network Information System ou
Yellow pages) qui permet de conserver le fichier hosts et bien d’autres informations dans une
base de données sur une machine maître.
Par ce procédé, les stations clientes peuvent disposer à tout moment des informations pour
satisfaire les requêtes.
Ce système a été utilisé sur Internet jusqu'à ce qu 'il trouve ses limites face au développement
extraordinaire du réseau (nombre important d’abonnés).
La mise à jour du fichier HOSTS.TXT n'était pas immédiate. L'administrateur de l'organisme
client, désirant nommer une machine, envoyait un courrier électronique au responsable de la
maintenance du fichier. Le fichier, situé sur un ordinateur central du NIC, était mis à jour,
publié via FTP et répliqué sur des serveurs secondaires. L'administrateur de l'organisme
client, trois jours après, dans le meilleur des cas, téléchargeait par FTP la nouvelle version du
fichier.

1.3.3. Procédé DNS


Paul Mockapetris a conçu et spécifié ce qu'était le DOMAIN NAME SYSTEM, ou DNS, en
rédigeant les RFC882 et RFC883. Ceux-ci furent plus tard mis à jour sous le nom de

11/10/09 23243440.doc 4
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

RFC1033 (Domain Names - Concepts and Facilities) et RFC1034 (Domain Names -


Implementations and Specifications), spécifications officielles du système.
L’introduction du DNS en 1984 a permis de régler les problèmes cités précédemment
(évolution des Yellow Pages). Quatre années ont été cependant nécessaires pour que le réseau
Internet adopte, en fin d'année 1987, le principe du DNS.
Le principe de fonctionnement repose sur l'existence d'une banque de données partagée
impliquant de très nombreux serveurs. Il représente pour le réseau Internet une sorte de
gigantesque annuaire téléphonique.

Pour cela, un mécanisme client-serveur est implémenté.


Le client lance une requête réseau (connexion à distance, transfert de fichiers, page Web,
etc…). Au lieu de passer en paramètre à la commande ou d'indiquer au logiciel utilisé
l'adresse IP en clair, il emploie le nom de domaine complet (ou nom d'hôte) correspondant,
par exemple:
telnet svr1.esat.terre.def

La station destinatrice de la requête est désignée par son nom de domaine associé.
La requête ne peut être envoyée sur le réseau que si l'on remplace cet alias par la véritable
adresse IP. L'application Internet doit donc interroger un serveur de noms
.

L'application Internet sollicitée lors de la requête passe en réalité par un intermédiaire local :
le resolver. Il s'agit de la partie cliente du service de noms de domaine chargé de trouver cette
correspondance. L'ensemble de l'opération s'appelle résolution de noms.
Ce client DNS va donc interroger le serveur DNS qui possède la table de correspondance. Ce
serveur, dont l'adresse est configurée sur la station cliente, s'appelle serveur de rattachement.
Le client et le serveur communiquent grâce au protocole DNS (voir RFC de références).
Le serveur de noms retourne l’adresse IP au logiciel client :
160.192.37.201
Le logiciel client contacte le serveur (telnetd) comme si l’utilisateur avait spécifié une adresse
IP :
telnet 160.192.37.201

Si le premier serveur de noms interrogé n'est pas en mesure d'effectuer cette résolution, ce
serveur interroge à son tour d’autres serveurs de noms jusqu’à ce que l’association nom de
domaine complet / adresse IP soit trouvée.
Le service DNS fonctionne dans les deux sens. Il assure aussi la traduction "adresse IP 
nom de domaine complet de la station". Cette opération s'appelle résolution inverse.

11/10/09 23243440.doc 5
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Tout serveur n'est pas compétent pour l'ensemble du réseau, mais pour une (ou des) zone(s)
données. Un système de réplication entre serveurs désignés assure une fiabilité raisonnable,
tandis que des mémoire-caches propres aux serveurs augmentent la performance du système.

Ce système permet ainsi de classer les noms d’hôtes selon une hiérarchie de domaines.

2. GENERALITES SUR LE DNS


2.1. Définitions

2.1.1. Espace "Noms de Domaine"


Imaginons l’arborescence de la figure suivante.
Les noms de domaine constituent un chemin dans un arbre inversé appelé l’espace Nom de
domaine :
 chaque noeud est identifié par un nom
 127 niveaux maxima sont possibles

Le sommet de l’arborescence est représenté par un point : c’est le domaine racine (root
domain).
Au niveau juste inférieur, sont représentés les domaines de plus haut niveau (Top Level
Domain ou TLD) où chaque pays gère son propre domaine (dans l’exemple : fr = France ; fi
= Finlande ; au = Australie).
Le cas de la France montre un découpage en plusieurs sous domaines à l'intérieur desquels la
résolution de noms est effectuée par un Serveur DNS.
Un nom de domaine est la séquence de labels depuis le noeud de l’arbre correspondant
jusqu’à la racine. Le caractère de séparation des différents niveaux est le point. Le point
représentatif de la racine n'apparaît pas dans le nom final.

. (root domaine)

fi fr au

com gouv org

defense finances

11/10/09 23243440.doc 6
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

terre air mer

esat

Espace "Nom de Domaine"

Dans ce système, deux noeuds fils ne peuvent avoir le même nom, d'où unicité d’un nom de
domaine au niveau mondial. Mais des noeuds peuvent avoir les mêmes noms dans des
domaines différents : svr1.esat.terre.defense.gouv.fr et svr1.emat.terre.defense.gouv.fr.
Le nom complet d'une station s'appelle "nom de domaine totalement qualifié", traduction
littérale de "Fully Qualified Domain Name", l'acronyme FQDN étant souvent employé.
Le nom complet peut se décomposer donc en un nom de station (hostname) svr1 et le nom du
domaine d'appartenance (ou suffixe de nom de domaine) esat.terre.defense.gouv.fr.

Domaine : sous-arbre de l’espace « nom de domaine ».


Un domaine peut englober d’autres domaines.
Un domaine intérieur à un autre domaine est appelé un sous-domaine.
Un nom de domaine est un index dans la base DNS, par exemple :
 svr1.esat.terre.def pointe vers une adresse IP
 esat.terre.def pointe vers des informations de routage de courriel et
éventuellement des informations de sous-domaines
 terre.def et def pointe vers des informations structurelles de sous-domaines

Les machines sont reliées entre elles dans un même domaine logique et non par
adressage.

11/10/09 23243440.doc 7
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

La lecture des noms de domaine s'effectue à


l’inverse de l’adressage IP, la partie la plus significative se situe à gauche de la syntaxe. Le
nom de la station est à gauche, celui de son "Top Level Domain" est à droite.

vers le plus significatif vers le plus significatif

svr1.esat.terre.de
160.192.37.201
f

Remarque :
Le fait que le nom de domaine soit en quatre éléments est un pur hasard : pas de
correspondance à établir entre un élément et un octet de l'adresse IP.
Le système DNS impose peu de règles de nommage :
 le nom de domaine ne doit pas excéder 255 caractères,
 chaque composante du nom ne doit pas comporter plus de 63 caractères,
 le nom de domaine complet est
 insensible à la casse,
 le premier caractère est obligatoirement une lettre,
 il n'existe
 pas
 de contrainte particulière pour les noms exceptées les signes espace et
souligné.

2.1.2. Domaines de plus haut niveau (Top Level Domain)


Six domaines de plus haut niveau ont été prédéfinis à l’origine d’Internet par INTERNIC
(www.internic.net) pour le seul territoire américain :
.com (sociétés commerciales), .edu (établissements d'enseignement),
11/10/09 23243440.doc 8
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

.gov (organisations gouvernementales), .mil (organisations militaires),


.net (organisations du réseau Internet), .org (organisations non commerciales),

Le domaine .int (organisations internationales) est un domaine particulier réservé à l'OTAN,


et à tous les organismes militaires qui en dépendent.
Le domaine .arpa est le seul TLD réservé à la résolution de nom inverse : adresse IP 
nom de domaine (cf. paragraphe 2.1.8).
Par la suite, une fois que le réseau Internet s'est solidement implanté au niveau international,
INTERNIC a mis en place des chartes nationales de nommage. Celles-ci devaient respecter la
norme ISO 3166 qui limite le nom du pays à une combinaison de deux lettres : fr, uk, de, it,
us, au, ca, se, etc.
Pour distinguer la première série des TLD des seconds, il a été décidé de nommer les
premiers les gTLD ("g" pour generic), les seconds les ccTLD ("cc" pour "country codes").
Le 16 novembre 2000, l’ICANN (www.icann.org) a retenu sept nouveaux gTLD: .aero (pour
l’industrie aéronautique), .biz (pour les activités commerciales), .coop (pour les
coopératives), .info (pour différentes activités), .museum (pour les musées), .name (pour les
noms de personnes) et .pro (pour les professionnels).
L'autorité gérant l'administration de ces domaines spécifiques aux pays est en règle générale
confiée aux autorités responsables d'une partie du réseau Internet. L'organisation RIPE
(www.ripe.net) en fait partie.
Les divisions en sous-domaines existent dans certains pays et pas dans d’autres :
 L'Australie a mis en place l'organisation des TLD d'origine sous la racine propre
au pays : edu.au, com.au, etc… Les conventions ont tendance à appuyer cette
procédure.
 D'autres ont créé leur propre organisation : co.uk, ac.uk, en Grande-Bretagne;
ny.us ou va.us pour chacun des 50 états des USA.
 L'autorité responsable du domaine fr, NIC France devenu AFNIC, n'a pas pratiqué
de division.

2.1.3. Délégation
Le système DNS est entièrement distribué au niveau planétaire grâce au mécanisme sous-
jacent de délégation de domaine.
A tout domaine est associé une responsabilité administrative.
Une organisation responsable d’un domaine peut découper ce domaine en sous-
domaines :
 Il peut déléguer les sous-domaines à d’autres organisations qui deviennent, à leur
tour, responsables du (des) sous-domaine(s) qui leurs sont délégué(s).
 Ces organisations peuvent, à leur niveau, déléguer vers de nouveaux sous-
domaines.

11/10/09 23243440.doc 9
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

2.1.4. Zone
Il s'agit d'une partie de l'espace "nom de domaine" géré administrativement et techniquement
par un serveur de noms (name servers).
 A une zone correspond au moins un domaine.
 Un serveur de noms peut gérer plusieurs zones.
 Un serveur de noms d'une zone contient les informations d’un domaine sauf
celles concernant les sous-domaines délégués.

Cette zone se traduit par l'existence d'un fichier descriptif situé sur le serveur de noms. En
chargeant ce fichier, le serveur devient l'autorité compétente de cette zone. Ces fichiers
indiquent généralement dans leur nom celui de la zone dont le serveur est responsable.
Pour chaque zone gérée par le serveur, il existe deux fichiers descriptifs : celui destiné à la
résolution normale (nom  adresse IP), et celui destiné à la résolution inverse (adresse IP 
nom).

Exemple sur la délégation :


Le domaine defense.gouv.fr a autorité sur toutes les stations du ministère de la défense mais
ne les gère pas toutes. Les stations de la zone esat.terre.defense.gouv.fr sont gérés par les
serveurs de l'Ecole Supérieure et d'Application des Transmissions.
Dès qu'un domaine accueille une grand nombre de stations, il est plus simple de le diviser en
plusieurs sous domaines. Si le sous-domaine esat devient trop complexe à gérer, il peut être
intéressant de le découper en plusieurs sous domaines, voire ajouter une nouvelle zone pour la
résolution de noms (DMSI par exemple). Il sera alors possible de confier la gestion du
domaine dmsi.esat.terre.defense.gouv.fr aux administrateurs de ce sous réseau.
La gestion du domaine esat se verra donc simplifiée.

2.1.5. Serveurs de Noms


 Serveur de noms primaire : il maintient la base de données de la zone dont il a l’autorité
administrative.
 Serveur de noms secondaire : il obtient les données du serveur de nom primaire qu’il
interroge périodiquement.

Un ou plusieurs serveurs secondaires s


ont généralement mis en œuvre pour pallier la défaillance éventuelle du serveur primaire.
L'autre nom du serveur primaire couramment rencontré dans la littérature est celui de serveur
maitre, alors que celui de serveurs esclaves est réservé aux serveurs secondaires.
Un serveur de noms peut être primaire pour une (des) zone(s) et secondaire pour d’autre(s).
Les serveurs de noms possèdent une mémoire-cache plus importante que celles des processus
clients ou resolvers, car ils récupèrent toutes les requêtes. Si la réponse ne se trouve pas dans
la mémoire-cache, alors il consulte un serveur racine (voir paragraphe 2.1.7).

11/10/09 23243440.doc 10
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Il ne faut pas confondre un serveur racine avec le domaine racine ".".

2.1.6. Resolver
Les resolvers sont les processus clients qui contactent les serveurs de noms. Leur
fonctionnement est le suivant :
 Il interroge un serveur de noms dont l’adresse est configurée sur la station cliente
 Il interprète les réponses
 Il retourne l’information au logiciel appelant
Le serveur DNS peut interroger également d’autres serveurs de noms, lorsqu’il n’est pas en
mesure d'effectuer la résolution de noms (par manque d'autorité sur la zone requise par
exemple). Cette deuxième requête peut se faire en mode itératif ou récursif (cf. partie 2.2).
Dans ce cas,
il peut être amené à contacter un serveur racine (voir paragraphe 2.1.7).

Remarques :
Les fonctions de resolver ont été portées avec succès du monde UNIX vers le monde
Windows. Ils ont été intégrés à l'interface Winsock.
Le resolver comprend entre autres la fonction gethostbyname() pour la résolution normale et
la fonction gethostbyaddr() pour la résolution inverse. Ces fonctions se trouvent dans la
bibliothèque standard libc sous LINUX.

2.1.7. Serveurs Racine


Les serveurs racine connaissent les serveurs de noms ayant autorité sur tous les domaines de
plus haut niveau (TLD) : à la fois les registres génériques tels que .com, .org, etc. et les
registres nationaux des 244 pays.
Les serveurs racine sont les piliers du système DNS. Si les serveurs racine sont indisponibles,
plus personne ne peut communiquer sur Internet sans connaître l'adresse IP du correspondant.
Ils sont actuellement 13 répartis sur la planète : 10aux USA, 2 en Europe, 1 au Japon.

11/10/09 23243440.doc 11
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

2.1.8. Résolution Inverse


Cette opération consiste a obtenir le nom de domaine à partir de l’adresse IP de la station :
pour des raisons de sécurité par exemple.
Le système utilise les adresses IP comme des noms :
 le domaine de plus haut niveau est in-addr.arpa
 les noms des noeuds correspondent aux octets de l’adresse IP en ordre inverse
 le domaine in-addr.arpa a 256 sous-domaines,
 chacun de ces sous-domaines a 256 sous-domaines,

11/10/09 23243440.doc 12
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

arpa

in-addr

160 255
0

0 192 255

0 37 255

sta1.esat.terre.def

0 201 255

 chacun de ces sous-domaines peut s'ouvrir, à son tour, sur 256 sous-domaines,
 le 4ème niveau correspond à un nom de domaine associé à cette adresse IP désormais
complète.

La zone in-addr.arpa est gérée par ARIN (American Registry of Internet Numbers) à l'adresse
suivante : www.arin.net.
La résolution d’un nom de domaine se fait de droite à gauche,
par exemple pour l'adresse : 201.37.192.160.in-addr.arpa
• in-addr.arpa -> A.ROOT-SERVER.NET
• 160.in-addr.arpa -> NS.RIPE.NET
• 192.160.in-addr.arpa -> NS.RIPE.NET
• 37.192.160.in-addr.arpa -> svr1.esat.terre.def
11/10/09 23243440.doc 13
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

2.2. Types d'Enregistrements


Les données d’un serveur DNS sont enregistrées dans une base. Cette base comprend
plusieurs fichiers de données dont les noms reprennent les noms de domaine de la zone gérée,
ceci quel que soit l'environnement d'exploitation.
Par exemple, sous Windows, ces fichiers portent l'extension dns : esat.terre.def.dns,
160.192.37.dns, 127.0.0.dns, cache.dns.

Ces fichiers ont leur propre syntaxe et leurs propres paramètres dont les principaux vont être
explicités ci-dessous. Chaque ligne représente une entrée du fichier ou un enregistrement.
Le signe choisi pour introduire un commentaire est le point-virgule.

SOA (Start Of Authority) :


Ce champ, présent dans chaque fichier de zone, signifie que le serveur hôte de
l'information qui suit ce trigramme a autorité sur un domaine DNS nommément
désigné.

@ IN SOA ns.esat.terre.def. pdupont.esat.terre.def. (


64 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL

Le signe @ signifie que le nom du domaine est décrit dans le fichier d'initialisation (ou de
définition) des fichiers de zone du serveur. Ce signe peut être remplacé par le nom de
domaine complet terminé par le point de la racine DNS. Il s'agit alors du nom absolu du
domaine.
Il est possible d'intercaler, entre le premier paramètre @ et le deuxième IN, un argument TTL
dont la valeur est exprimée en secondes, pour donner une durée de vie à l'enregistrement.
L'argument IN, abréviation d'Internet, est là pour spécifier que les données qui suivent
s'appliquent au réseau Internet, et non à un autre.
Le nom de domaine complet du serveur est : ns.esat.terre.def.
Pour exprimer le fait qu'il est la plus haute autorité sur la zone, le nom du serveur se termine
par un point (racine dans l'arborescence DNS), idem pour l'adresse de courriel qui suit.
L'adresse qui suit celle du serveur représente l'adresse de courriel de l'administrateur du
serveur où le signe @, déjà employé dans un autre but, est remplacé par le point.
Les paramètres techniques qui suivent, situées entre les parenthèses, concernent la réplication
des données entre le serveur DNS primaire et le(s) serveur(s) DNS secondaire(s). Ils seront
explicités dans un paragraphe ultérieur.

11/10/09 23243440.doc 14
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

NS (Name Server) :
Chaque entrée de ce type représente un des serveurs de noms du domaine : serveur
primaire d'abord, puis les serveurs secondaires s'ils existent.

esat.terre.def IN NS ns.
@ IN NS 160.192.37.2
@ IN NS ntserver.
@ IN NS 160.192.37.3

Le premier enregistrement indique que la station ns est serveur de la zone esat.terre.def. Le


deuxième enregistrement précise son adresse IP.
La troisième entrée renseigne sur l'existence d'un serveur de noms secondaire.

A (Address) :
Cette entrée permet la résolution de noms : nom de domaine complet  adresse IP.

C201-0115-0780 IN A 160.192.20.16
C201-0115-0785 IN A 160.192.20.17
svr-intranet IN A 160.192.80.2

Seul le nom de la station suffit pour décrire celle-ci, et non le nom de domaine complet. Ceci
est possible parce que le serveur gestionnaire du domaine fait lui-même partie intégrante du
domaine.
Bien sûr, le fichier de zone doit comporter autant d'entrées que de stations gérées présentes
dans cette zone.
Le champ A, valide dans le cas d'une adresse IP version 4 (4 octets), est remplacé par AAAA
s'il s'agit d'une adresse IP de la version 6 en 16 octets.
Une même station peut avoir plusieurs enregistrements dans le cas d'adresses IP multiples
(notion d' <IP aliasing> ou d'adresse IP virtuelle). Dans ce cas, la répétition du nom d'hôte
ou de station en début de ligne n'est pas nécessaire.

CNAME (Canonical Name) :


Cette option permet de définir des alias lorsque le nom de domaine devient trop
complexe, ou lorsque la station visée n'est autre qu'un serveur Internet.
Dans ce deuxième cas, il sert à désigner des noms de site Internet (web ou ftp ou
autre) hébergés par la station dont l'entrée de type Address (A) précède.

svr-intranet IN A 160.192.80.2
ftp IN CNAME svr-intranet
11/10/09 23243440.doc 15
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

mail IN CNAME svr-intranet


www IN CNAME svr-intranet

Le premier champ est le nom de l'alias se substituant au nom de la station indiqué dans le
dernier champ.

PTR :
Cet enregistrement est utilisé dans le cadre de la résolution de noms inverse (mode
reverse) au sein du domaine in-addr.arpa : adresse IP  nom de domaine de la
station.

10.20.192.160.in-addr.arpa IN PTR sunstation8.esat.terre.def.


11.20.192.160.in-addr.arpa IN PTR sunstation9.esat.terre.def.

La valeur débute par l'adresse IP inversée suivie du nom de domaine racine propre à la
résolution inverse.

HINFO (Host Information) :


Cette option, si elle est présente, décrit le type de station hébergeant le serveur DNS
ainsi que son système d'exploitation. Les désignations autorisées pour le matériel et le
système d'exploitation sont consignées dans le RFC 1700 établi par l'IANA.
Malheureusement, la liste n'est plus d'actualité.

TXT :
Ce champ optionnel permet à l'administrateur d'ajouter des commentaires particuliers.

MX (Mail Exchanger) :
Cet enregistrement important définit le serveur de courrier de la zone. Il permet
l’adressage sur la base du nom de domaine plutôt que sur l’adresse du (des) serveur(s)
de courrier :
pdupont@esat.terre.def plutôt que pdupont@lx4.esat.terre.def
Cet enregistrement présente d'autres avantages.
o Il permet à l’émetteur de messages d’ignorer quelle est la station
hébergeant le serveur de courrier.
o Il permet le déplacement du serveur de courrier vers une autre station.
o Il permet la gestion de plusieurs serveurs de courrier du même domaine
en indiquant l’ordre de consultation des serveurs grâce à un indice de priorité.

11/10/09 23243440.doc 16
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

esat.terre.def IN MX 8 sun1.esat.terre.def.
esat.terre.def IN MX 99 next.esat.terre.def.

L’enregistrement MX est consulté par tous les logiciels SMTP client (mailers), que ce soit
Outlook Express sous Windows ou autre.
Le nombre suivant le paramètre MX représente le niveau de priorité donné à la station dont le
nom suit. Plus le chiffre est petit, plus la priorité est élevée.
Ce nombre croissant est déterminant pour distinguer le serveur principal de courrier du
domaine, toujours décrit en premier, d'un (ou des) serveur(s) secondaire(s).

2.3. Données Cachées


Le cache DNS, tel qu'il est appelé sous Windows, est un fichier (cache.dns sous Windows,
named.ca sous UNIX) qui répertorie l'ensemble des serveurs racines du réseau Internet.

. IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. IN A 198.41.0.4
. IN NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. IN A 128.9.0.107
. IN NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. IN A 192.33.4.12
. IN NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. IN A 128.8.10.90
. IN NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. IN A 192.203.230.10
. IN NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. IN A 39.13.229.241
. IN NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. IN A 192.112.36.4
. IN NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. IN A 128.63.2.53
. IN NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. IN A 192.36.148.17

Il ne faut pas confondre cette notion de données caches ou fichier "cache", avec celle de la
mémoire-cache enregistrant aussi bien au niveau du resolver que des serveurs les "requêtes-
réponses".
Cette liste ne change que très rarement. Au cas où un doute s'instaure, il suffit de rapatrier le
fichier adéquat depuis l'adresse suivante : ftp://ftp.rs.internic.net/domain/named.root.
Cette liste ne concerne que les serveurs du réseau Internet. Les réseaux indépendants, style
IntraTerre, ont leurs propres serveurs racines, et donc leur propre liste.

11/10/09 23243440.doc 17
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

2.4. Serveurs Itératifs et Serveurs Récursifs


Dans le cas de la résolution d'un nom de domaine situé hors de la zone de compétence du
serveur DNS local (ou de rattachement), la résolution de noms peut être récursive ou
itérative:
 récursive : le serveur de noms local (de rattachement) du client interroge successivement
les serveurs de noms des domaines constitutifs du nom de domaine à résoudre, en
commençant par le suffixe le plus à droite (donc .def en premier).

Voici un schéma explicatif.

requête
Resolver Serveur de Noms local (zone esat.terre.def)
réponse
svrfoto.esat.terre.de
1
f
joke> ping
Root NS
svrfoto.esat.terre.def demander à def
NS
2
svrfoto.esat.terre.de
f
def NS
demander à
terre.def
3
svrfoto.esat.terre.de
f
terre NS
demander à esat.terre.def

o Il l'envoie en premier vers un des treize serveurs racine (Root NS). Après
interrogation de la base, si le nom recherché est absent, ce dernier envoie
comme réponse l'adresse du serveur de noms du domaine immédiatement
inférieur .def par exemple.
o Le serveur DNS local envoie une nouvelle requête vers le serveur de la zone
.def désigné. Si ce dernier ne connaît pas la réponse, il renvoie au serveur local
l'adresse du serveur de noms du domaine immédiatement inférieur .terre.def.
o La procédure se termine avec le serveur local de la zone .esat.terre.def.

 itérative : le serveur de nom local interroge des serveurs nommément désignés dans sa
configuration.
o Si le premier contacté ne connaît pas la réponse, il renvoie au serveur local
l'adresse d'un serveur susceptible de répondre, et ainsi de suite…
Les serveurs DNS racine, étant surchargés en demandes, ne travaillent qu'en mode itératif.

11/10/09 23243440.doc 18
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Les serveurs DNS UNIX utilisant le programme BIND (Berkeley Internet Name Domain)
travaillent par défaut en mode récursif. Il faut ajouter une directive pour les faire travailler en
mode itératif dans le fichier de configuration.

options {
recursion no
}

Serveurs de Noms
B
Le serveur de noms A reçoit une
requête en provenance du resolver
A interroge B. 2 3 C
B renseigne A au sujet des
serveurs de noms, dont C.
A interroge C.
4
C renseigne A au sujet des
serveurs de noms, dont D. 5
A interroge D. 6
D répond.
A D
A renvoie la réponse au resolver. 7
1

Resolver

2.5. Serveur Primaire et Serveur Secondaire

2.5.1. Transfert de zone


Le serveur primaire (ou maître) et le(s) serveur(s) secondaire(s) (ou esclave) d'une même
zone communiquent périodiquement.
Chaque fois que l'administrateur du service modifie la base de données du serveur primaire,
les modifications sont répliquées sur le serveur secondaire à une date déterminée par certains
paramètres. Cette opération s'appelle transfert de zone.

11/10/09 23243440.doc 19
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

C'est la raison pour laquelle l'enregistrement SOA contient une série d'informations entre
parenthèses faisant suite à ses propres paramètres. Ces parenthèses empêchent que le contenu
soit interprété comme des lignes isolées.

@ IN SOA ns.esat.terre.def. plouche.esat.terre.def. (


64 ; serial number
3600 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL

Numéro de série (serial number) :


Il représente le numéro de mise à jour du fichier de zone. Il est utile aux serveurs DNS
secondaires pour constater une modification du fichier, car le numéro est incrémenté à
chaque mise à jour.
La tendance actuelle vise à utiliser la date selon le format AAAAMMJJxy, où AAAA
représente l’année, MM le mois, JJ le jour, et xy le véritable numéro de série à
incrémenter.

199802151 ; Serial, todays date + todays serial

Rafraîchissement (refresh) :
Cette valeur exprimée en secondes représente l'intervalle de vérification des
enregistrements entre les deux serveurs.

Tentatives (retry) :
Cette durée exprimée en secondes détermine l'intervalle entre deux tentatives de
rafraîchissement pour un serveur DNS secondaire sur le serveur DNS primaire.

Expiration (expire) :
Ceci représente la durée en secondes à l'issue de laquelle un serveur secondaire arrête
le service car il considère que ses informations sont périmées. Cette durée est bien
sûre supérieure aux deux durées précédentes cumulées.
Les valeurs sont comprises entre 86400 (valeur par défaut correspondant à une
journée) et 604800 (une semaine).

TTL (Time To Live) :


Chaque serveur DNS détient des informations (appelées aussi Ressources Records)
stockées dans des fichiers de zone. Suite aux différentes requêtes, ces informations
sont conservées pendant un certain temps dans la mémoire-cache des serveurs. La
11/10/09 23243440.doc 20
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

valeur du paramètre TTL indique à ces serveurs la durée maximale de conservation de


ces informations.

Ces durées, exprimées par défaut en secondes, peuvent aussi utiliser des lettres réservées : W
pour Week, D pour Day, H pour Hour. Voici un exemple tiré d’un fichier cache ou la valeur
5w6d16h représente 5 semaines - 6 jours - 16 heures.
. 6D IN NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33

2.5.2. Comment les différencier ?

Un serveur est primaire ou secondaire en fonction du contenu de son fichier de configuration.

L'enregistrement NS des fichiers de zone n'indique rien. Cependant, le fichier de zone du


serveur primaire le mentionne comme deuxième serveur de noms du domaine, avec
éventuellement un enregistrement MX si ce dernier héberge aussi un serveur de courrier.

@ IN NS svr2.dmsi.esat.terre.def.
@ IN MX 100 svr2.dmsi.esat.terre.def.
@ IN A 160.192.20.21

Le serveur secondaire doit aussi être référencé dans le fichier de résolution inverse.

21.20.192.160 IN PTR svr2.dmsi.esat.terre.def.

Le fichier d'initialisation du serveur secondaire, quant à lui, mentionne obligatoirement son


rôle. Voici un exemple de fichier tiré du programme BIND version 4, puis de BIND version
8.

secondary dmsi.esat.terre.def 160.192.20.20 dmsi.hosts

zone "dmsi.esat.terre.def" in {
type slave ;
file "dmsi/dmsi.hosts";
masters { 160.192.20.20 };
}

Le paramètre secondary en BIND v4 (type "slave" en BIND v8) indique que ce serveur est
secondaire pour la zone dmsi.esat.terre.def. L'adresse IP est celle du serveur primaire de la
même zone, le fichier est celui du serveur primaire dupliqué sur le serveur secondaire.

La deuxième différence entre le serveur primaire et serveur secondaire vient de l'origine du


fichier de données. Le serveur primaire les obtient des fichiers locaux alors que le serveur
secondaire les obtient par téléchargement périodique depuis le serveur primaire. Mais ces
fichiers restent identiques.

11/10/09 23243440.doc 21
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Il en est de même des fichiers cache et de résolution locale.

En ce qui concerne le serveur primaire, il faut autoriser le(s) serveur(s) secondaire(s) à


recharger les fichiers de zone à l’aide des paramètres notify et allow-transfer (voir paragraphe
consacré à la sécurité).

2.6. Domaines Virtuels


Un serveur peut gérer plusieurs zones (ou domaines) avec un même service DNS.
Lorsque ces domaines sont associés à des noms d'une autre branche de l'arborescence DNS,
ils sont dits virtuels.

Domaine principal esat.terre.def


Domaine(s) virtuel(s) esat.marine.def
ctein.terre.def

Chacun de ces domaines virtuels peut être géré dans un fichier de zone spécifique sur le
serveur.

2.7. Sous Domaines


Si le serveur DNS doit gérer dans sa zone quelques stations d'un sous-domaine, plusieurs
procédés existent.

2.7.1. Station isolée


Le premier procédé et le plus simple consiste à décrire dans le premier champ de
l'enregistrement A le nom de station suivi du nom du sous-domaine, sans rajouter le nom du
domaine du serveur.
Exemple d'une station du sous-domaine DMSI :

svr1.dmsi IN A 160.192.21.60

2.7.2. Serveur d'un sous-domaine


La question de l'existence d'un serveur dans un sous-domaine entraîne celle de la délégation
de zone.
L'administrateur du domaine, selon les circonstances, est amené à :
 garder la responsabilité de ce sous-domaine en le déclarant dans son propre fichier de
zone (première série d'exemples)
 transférer la responsabilité du sous-domaine vers un organisme subalterne (deuxième série
d'exemples).

11/10/09 23243440.doc 22
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Sans délégation

1) dmsi NS svrdmsint.esat.terre.def. ; premier cas où l’adresse du serveur


svrdmsint.esat.terre.def. IN A 160.192.20.20 ; du domaine principal est rappelée

2) $ORIGIN laval.esat.terre.def ; première variante avec la directive


; $ORIGIN changeant le suffixe des
guerelec IN A 160.192….
; noms de stations qui suivent
3) $ORIGIN laval.esat.terre.def ; deuxième variante avec un fichier
; séparé inséré par directive d'inclusion
$INCLUDE laval.hosts

Avec délégation

da NS svrda.da.esat.terre.def. ; deuxième cas où l’adresse d’un serveur


svrda.da IN A 160.192.10.23 ; spécifique au sous-domaine est indiqué

Note : le caractère ";" précède tout commentaire dans les fichiers.

2.8. Serveur de Nom Local


Le serveur de noms est d'abord serveur de lui-même, en ce qui concerne l'adresse IP de
boucle locale (loopback) : 127.0.0.1 ou localhost.
Sous UNIX, un même fichier descriptif spécifique existe pour permettre les deux types de
résolution.

2.9. Station Cliente


Une station cliente spécifie le(s) serveur(s) de noms de son domaine : adresse(s) IP
obligatoirement, éventuellement son nom de domaine comme critère de recherche.

Les deux environnements principaux que sont UNIX et Windows offrent une approche
différente pour le paramétrage.
o sous UNIX, il s'agit de modifier à l'aide d'un simple éditeur de texte le fichier
/etc/resolv.conf (voir paragraphe ultérieur)
o sous Windows NT, l'opération consiste à accéder aux propriétés de l'administration
TCP/IP afin d'en modifier le contenu.

2.10. Test du Serveur


Il existe plusieurs commandes du monde TCP/IP pour tester le fonctionnement du serveur :
tout simplement la commande PING pour tester la présence d'une station sur le réseau, ou la
commande NSLOOKUP dédiée comme son nom l'indique à l'interrogation du service DNS.

11/10/09 23243440.doc 23
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

2.10.1. Commande PING


Le client souhaite connaître l'adresse IP de la station Form4.UNIX par exemple.
Après avoir exécuté la commande "ping Form4.UNIX", une requête part sur le serveur de
noms de l'organisme.
Si celui ci est en mesure de retourner l'adresse IP de Form4.UNIX, alors le système retourne :

PING Form4.UNIX: (160.192.21.106): 56 data bytes


64 bytes from 160.192.21.106: icmp_seq=0 ttl=127 time=2 ms
64 bytes from 160.192.21.106: icmp_seq=1 ttl=127 time=1 ms
64 bytes from 160.192.21.106: icmp_seq=2 ttl=127 time=1 ms

2.10.2. Commande NSLOOKUP


Non seulement elle sert à interroger le contenu des fichiers de ce dernier à distance, sans avoir
accès à l'administration du service, mais encore elle représente une commande essentielle
pour tester la bonne configuration du serveur.

2.11. Protocole DNS


La communication entre le client et le serveur peut s'établir aussi bien avec le protocole UDP
qu'avec le protocole TCP.
Le port 53 est dédié au service DNS. Aussi ce numéro de port, indispensable au
fonctionnement du service, ne doit pas être filtré sur le réseau.
Un logiciel parefeu bloque les requêtes de résolution de noms, il faut alors décommenter les
paramètres suivants dans le fichier d'initialisation /etc/named.conf de BIND 8 (enlever le
signe "//") :

options {
directory "/var/named";
// query-source port 53; };

Note : les commentaires peuvent revêtir plusieurs formes dans les fichiers d’initialisation du
service : /* … */, ou le signe "//", ou le signe "# ".
Si les logiciels clients (resolvers) peuvent choisir entre les deux, ils préfèrent le protocole
TCP en raison de sa fiabilité.
D'un autre côté, le protocole UDP est utilisé de préférence entre les serveurs de noms lors de
la réplication des données.

2.12. Références DNS


En dehors des RFC 1034 et 1035 déjà cités, il existe d'autres RFC relatifs au sujet :
 RFC 1032, Domain Administrators Guide, 1987

11/10/09 23243440.doc 24
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

 RFC 1033, Domain Administrators Operations Guide, 1987


 RFC 1183, New DNS RR Definitions
 RFC 1480, The US Domain, 1993
 RFC 1591, Domain System Structure and Delegation, 1994
 RFC 1712, DNS Encoding of Geographical Location
 RFC 1713, Tools for DNS debugging
 RFC 1912, Common DNS Operational and Configuration Errors
 RFC 2136, Dynamic Updates in the Domain Name System
 RFC 2137, Secure Domain Name System Dynamic Update
 RFC 2782, A DNS RR for specifying the location of services (DNS SRV)
La liste des documents de référence ci-dessus se veut synthétique des différentes sources
consultées pour constituer le document. Elle n’est pas exhaustive.
Il existe en outre des documents spécifiques à l’Europe consultable sur le site du RIPE. La
liste complète des documents de références est disponible sur le site www.nic.fr (site de
l’AFNIC).

3. CONFIGURATION SOUS LINUX


3.1. Côté Serveurs

3.1.1. Le service de noms


Le principal programme qui réalise le service de noms sous UNIX est BIND. Le logiciel est
un graticiel disponible sur le site de l'ISC (Internet Software Consortium) à l'adresse
www.isc.org. Il en existe plusieurs versions mises en œuvre au sein des réseaux Internet.
Les plus anciennes versions encore utilisées sont BIND4, dont la documentation reste
disponible à l'adresse suivante : www.math.uio.no/~janl/DNS/ (HOWTO actuel). En cas
d’impossibilité de migration vers les versions 8, le consortium ISC recommande l'utilisation
de la version BIND 4.9.9 (www.isc.org/products/BIND/bind4.html).
La version la plus courante aujourd’hui est BIND 8.x.x. La toute dernière de la série est
BIND 8.3.3 (28 juin 2002) disponible à l'adresse
http://www.isc.org/products/BIND/bind8.html. Il est recommandé d'upgrader les versions
antérieures à la 8.2.5 pour des raisons de sécurité.
Le paragraphe suivant fait référence à l'empaquetage BIND 8.2 (ou package), mais la section
suivante présente les deux versions.
La plupart des distributions GNU/Linux incluent le logiciel BIND et ses dérivés qu'ils
proposent sous forme d'empaquetages à installer.

3.1.2. Détails des empaquetages


Trois empaquetages sont nécessaires pour mettre en œuvre le service sous UNIX : un pour le
service proprement dit, un pour installer des squelettes de fichiers de configuration hormis les

11/10/09 23243440.doc 25
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

fichiers de zone, un pour installer les utilitaires permettant de tester le fonctionnement du


serveur (nslookup).
Pour une distribution Mandrake 8.2, on a :
• Le Package "bind-8.2...mdk" qui permet d'installer :
• Le véritable exécutable sous /usr/sbin : named,
• Le script de démarrage du processus démon named ci-dessus sous
/etc/rc.d/init.d,

• Le Package "caching-nameserver-6.0-3mdk"
Ce paquetage permet d'installer les squelettes des fichiers de configuration suivants :
• sous /etc :
 named.boot = fichier sommaire des fichiers de configuration du service
(BIND V4)
 named.conf = squelette d'un fichier qui a le même rôle (BIND V8) que le
précédent (redondance)
• sous /var/named, les fichiers named.ca (fichier cache des serveurs racine),
named.local (résolution de boucle locale)

• Le Package "bind-utils-6.0-3mdk"
Cet empaquetage contient l'ensemble des utilitaires de tests ou d'administration du
service : nslookup, dig, host (commande de remplacement de nslookup), ndc, h2n, etc…
Une documentation locale à la station est accessible par les commandes : man named, ou
« navigateur » /usr/doc/bind/html/index.html.

3.1.3. Principaux Fichiers de Gestion


/
Voici un schéma récapitulatif des principaux fichiers impactés par le service DNS.
Le processus démon à lancer, principal exécutable du service, est /usr/sbin/named.
usr
Le service, au lancement,varcherche ses informations dans un fichier
etc sommaire nommé
named.boot (version 4) ou named.conf (version 8) qui contient un ensemble de pointeurs vers
les fichiers de références ou fichiers de zone.
Les deux seuls fichiers nonnamedencore cités sont
sbinles fameux fichiers de zone. Ils portent par
défaut des noms bien évocateurs de leurs fonctions : named.hosts
rc.d pour le fichier de résolution
normale, named.rev pour le fichier de résolution inverse.
named.boot
Si l'administrateur gèrenamed.ca
plusieurs zones avec le même service, il est amené à renommer ces
fichiers en incluant dans leurs noms, soit named init.d
le nom du sous-domaine géré pour le fichier
named.hosts, soit l'adresse IP inverse pour le fichier named.rev, par exemple : ctein.hosts
pour la zone ctein.terre.def, 17.99.128.rev pour le réseau 128.99.17.xx. named.conf
Fichiers named.local named
de zone
Fichiers de
démo
named.hosts
11/10/09 n
23243440.doc référence 26
script

named.rev
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Le logiciel Bind est insensible à la casse. Le seul caractère interdit sous UNIX est "_".

3.1.4. Démarrage
Une fois que l'on a installé et configuré le service, l'administrateur peut démarrer le service en
ligne de commandes : cd /etc/rc.d/init.d, puis ./named start (stop pour l'arrêter).
Pour vérifier l’état du service, l'administrateur lance la commande : ps -ef | grep named, ou
/etc/rc.d/init.d/named status.
Un message d'erreur similaire à l’exemple suivant peut apparaître. Il suffit alors d'arrêter puis
de démarrer le service pour le réinitialiser.

ndc: error: ctl_client: evConnect(fd 3): Connexion refusée


ndc: error: cannot connect to command channel (/var/run/ndc)

Comme le suggère le message d'erreur, en dehors du script de démarrage named, il existe une
autre commande pour démarrer le serveur DNS BIND : ndc (name demon control) situé sous
/var/run. Elle peut fonctionner de manière interactive.

# ndc # ndc start


Type help -or- /h if you need help new pid is 26103
ndc> start # ndc reload
new pid is 26103 ; serveur secondaire qui recharge le
ndc> stop fichier zone du serveur primaire
ndc>^D # ndc status
; PID du processus named

Un serveur DNS DOIT TOUJOURS être relancé après une modification des fichiers de
configuration.

11/10/09 23243440.doc 27
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Le processus named fait partie des services à lancer au démarrage de la station. Pour cela, il
est possible sous LINUX de lancer l'utilitaire semi-graphique ntsysv en ligne de commandes
ou linuxconf en mode graphique.

3.1.5. Configuration du fichier d'initialisation de BIND 4


Le fichier /etc/named.boot, est le premier fichier lu par le processus named, chargé du service
DNS. Il était utilisé par la version 4 de BIND. Même s'il est désormais remplacé par le fichier
named.conf, il est toujours disponible dans les distributions. De plus, les trois premières
lignes restent toujours analysées par le serveur DNS.
Il présente deux utilités majeures : préciser le rôle du serveur hôte (primaire ou secondaire),
localiser les fichiers de zone sur le serveur.

; a caching only nameserver config

directory /var/named
cache . named.ca
primary 0.0.127.in-addr.arpa named.local
primary esat.terre.def named.hosts
primary 192.160.in-addr.arpa named.rev

Voici un exemple de fichier où nous allons détailler le rôle de chacun des paramètres.

directory :
Il désigne le répertoire dans lequel se trouvent les fichiers de zone (named.ca –
named.local – named.hosts - named.rev). Par défaut sous /var/named,
l'administrateur du service peut le déplacer à volonté.
Note : les nom de fichiers rappellent le nom du service qui l'appelle et leurs rôles respectifs.

cache :
Il définit le fichier de cache nécessaire pour assurer les bonnes performances du
serveur DNS. Ce fichier contient les adresses de tous les serveurs racine du réseau
auquel appartient le serveur DNS.
Si le cache n'est pas défini, le service named est incapable de joindre les serveurs
racine, et donc de résoudre n'importe quelle demande de résolution .Dans ce cas, le
serveur ne résoud que les noms de sa propre zone.

11/10/09 23243440.doc 28
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

primary :
Il désigne un service de noms primaire. Pour chaque zone décrite, deux paramètres
sont définis : le nom de domaine desservi et le nom du fichier de zone associé.
La première référence concerne la zone locale (résolution de boucle locale) : 127.0.0.1
<-> localhost. Il porte le nom d'une zone de résolution inverse, l'adresse IP inversée
amputée du dernier octet suivie du nom de domaine racine de l'espace inverse.
La deuxième référence concerne le domaine esat.terre.def. Cette entrée est cruciale car
l'on indique le nom de la zone desservie. Il existe d'autres fichiers dans lesquelles cette
information est mentionnée, mais celle-ci prime sur les autres mentions.
La troisième référence concerne le même domaine esat.terre.def, mais pour la
résolution inverse. Comme dans le cas de la première référence, le nom de domaine
in-addr.arpa est précédé de l'adresse IP inversée du réseau du domaine esat.terre.def.
Contrairement au premier exemple, deux octets seulement sont utilisés. Cela implique
que seuls les deux derniers octets restants seront décrits dans le fichier associé pour
identifier assurément chaque nom de station du domaine. Les nombres d'octets décrits
de part et d'autre sont donc obligatoirement complémentaires. Le nombre d'octets
utilisé pour nommer la zone varie selon le segment d'adresses à référencer.
Ainsi l'administration de toute zone implique l'existence d'au moins deux fichiers de
référence.
En tant que serveur primaire, le service named charge les informations de zone de ces fichiers
de références.

Remarque :
La zone "." est obligatoire. Si le fichier de configuration ne décrit que cette zone et les zones
"localhost" et "0.0.127.in-addr.arpa", nous avons affaire à un serveur cache DNS.

Autres options disponibles :


secondary (ou secondaire) déclare un serveur secondaire d'une zone donnée (fichier du
serveur secondaire).
slave (ou esclave) déclare un serveur primaire comme serveur secondaire vis à vis
d'une autre zone (fichier du serveur primaire).
forwarders permet d'interroger une liste restreinte de serveurs de noms, au
sein d'un réseau donné, sans remonter jusqu'aux serveurs racine
du réseau Internet ou d'un réseau fédérateur (fichier du serveur
primaire).
stub définit une zone enfant auprès de laquelle un serveur parent
récupère les informations de délégation.

Avec la version BIND 8.2, un nouveau fichier de configuration est apparu, le fichier
/etc/named.conf.
Son rôle est le même que le fichier named.boot précédent. Toutefois, si les deux fichiers sont
utilisés pour configurer le serveur, il est déconseillé de laisser dans le fichier named.boot les
deux dernières lignes données en exemple.

11/10/09 23243440.doc 29
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

3.1.6. Configuration du fichier d'initialisation de BIND 8

; /etc/named.conf
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
notify no;
};
zone "esat.terre.def " {
type master;
file "named.hosts";
notify no;
};
zone "192.160.in-addr.arpa" {
type master;
file "named.rev";
notify no;
};

La structure des données est différente (similaire au langage C), mais la nature des
renseignements et le rôle du fichier restent identiques.
Le paramètre type renseigne sur la nature de la zone : hint pour le fichier cache, master pour
les zones gérées par un serveur primaire, slave pour les zones dont il est serveur secondaire.
Le paramètre file désigne le fichier de référence associé à la zone.
Le paramètre notify indique au serveur primaire s'il faut aviser le serveur secondaire (ou
esclave) de toute modification.

Variante 1 : forwarder
L’entreprise veut limiter, pour plusieurs raisons (connexion Internet facturée au trafic, bande
passante de connexion trop limitée), le nombre de résolutions d’adresse envoyées vers le Net.
11/10/09 23243440.doc 30
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Le logiciel BIND propose alors le service de retransmission (forwarding) pour une zone
donnée.

Pour configurer un serveur forwarder, il faut définir les zones cache et locale. Puis, il faut
indiquer aux autres serveurs de la zone qu'ils doivent consulter ce serveur. Le bloc
d'instructions qui suit donne un exemple de configuration tiré d'Internet.

zone "wanadoo.fr." { Nous créons sur notre serveur de noms une


type forward; zone "wanadoo.fr" qui permet de rediriger
forward only; vers… toutes les requêtes destinées à
forwarders { Wanadoo.fr.
62.161.120.11;
};
};

Le serveur ci-dessus, grâce à la directive forward only, ne consultera pas les serveurs racine,
mais uniquement le serveur indiqué par son adresse IP : il devient un serveur de noms
restreint.
Le serveur configuré ainsi, recherche d'abord la réponse dans sa mémoire-cache interne, avant
de consulter les retransmetteurs. Dans le cas où il n'est pas restreint dans son comportement, il
va en dernier consulter les serveurs racines.

Variante 2 : stub
Une configuration avancée entre serveurs de domaine (parent) et serveurs de domaine délégué
(enfant) peut conduire l'administrateur à ajouter un nouveau bloc d'instructions similaire à
l'exemple ci-dessous. Il permet au serveur parent de gérer dynamiquement les informations de
délégation du serveur enfant.

zone "dmsi.esat.terre.def" {
type stub;
file "dmsi.hosts";
masters { 160.192.20.20; };
};

3.1.7. Configuration du cache


Le cache, ou plutôt les serveurs racine, sont décrits dans ce fichier /var/named/named.ca
(nota : le nom du fichier et son répertoire ont été définis dans le fichier /etc/named.boot ou
/etc/named.conf).

; /var/named/named.ca

. 99999999 IN NS lx1.esat.terre.def.

11/10/09 23243440.doc 31
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

lx1.esat.terre.def. 99999999 IN A 160.192.11.112

L'exemple est particulier dans la mesure où il fait référence à une séance de cours de travail
pratique. Dans ce cas unique, le serveur DNS hôte de ce fichier est lui-même son serveur
racine.
L'IntraTerre forme une bulle déconnectée du réseau Internet. Il s'appuie sur un réseau
fédérateur IP (REFEDAT) qui possède ses propres serveurs racine. Pour des raisons évidentes
de confidentialité, ces derniers ne sont pas mentionnés dans ce document.
Le chiffre indiqué "99999999" a une valeur symbolique (la valeur 0000000 peut se
rencontrer). Il représente la durée de vie (TTL) de l'information. Dans les versions BIND8, ce
chiffre a été remplacé par 3600000, la durée de vie maximum d'un enregistrement.
Le point final représente le sommet de l'arborescence DNS du réseau concerné ou racine. La
présence d'un point à la fin d'une adresse indique au serveur qu'il n'a pas à rajouter de suffixe
à l'adresse en question.

3.1.8. Description du fichier de résolution locale


Le nom du fichier et son répertoire (/var/named/named.local) ont été définis dans le
fichier /etc/named.boot ou /etc/named.conf.
Le fichier assure à la fois la résolution normale et la résolution inverse concernant
uniquement l'adresse de boucle locale (loopback). Ce fichier permet au serveur de
communiquer avec lui-même. Chaque serveur est responsable du réseau interne 127.

; /var/named/named.local

@ IN SOA localhost. root.localhost. (


1 ; Serial
360000 ; Refresh
3600 ; Retry
3600000 ; Expire
360000 ; Minimum
)

@ IN NS localhost.
1 IN PTR localhost.

Ce fichier doit absolument contenir l'enregistrement SOA qui permet d'établir la


correspondance entre 127.0.0.1 et localhost.
L'avant-dernier enregistrement consiste à le déclarer comme serveur de sa propre boucle
locale.
Le dernier enregistrement établit la résolution inverse de l'adresse 127.0.0.1 à l'aide du
dernier octet "1", le complément étant déclaré dans le nom de zone 0.0.127.in-addr.arpa.
Il faut noter dans le fichier la présence du point final dans toutes les adresses.
11/10/09 23243440.doc 32
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Une variante consiste à remplacer localhost par le nom de domaine complet du serveur.

3.1.9. Configuration de la base de données


La base de données se configure sous deux formes :
• La première chargée de la résolution simple de noms (nom de domaine  adresse IP)
• La deuxième chargée de la résolution inverse (mode reverse), résolution sollicitée par des
serveurs tels que les serveurs FTP, serveurs de news, serveurs IRC, serveurs WEB, etc…
L'exemple du fichier qui suit (/var/named/named.hosts) s'applique dans le cas d'une résolution
de noms simple (nota : le nom du fichier et son répertoire ont été définis dans le fichier
/etc/named.boot ou named.conf).
Il présente toujours la structure suivante : les caractéristiques de l'autorité de zone en la
personne du serveur DNS, puis la description des différents serveurs primaires et secondaires,
enfin la description de l'ensemble des stations de la zone.

; /var/named/named.hosts

; déclaration de l'autorité administrative


@ IN SOA lx1.esat.terre.def. root.lx1.esat.terre.def. (
16 ; numéro de série
86400 ; rafraîchissement journalier
3600 ; tentative toutes les heures
3600000 ; expiration au bout de 42 jours
604800 ; TTL minimale d'une semaine
)

; déclaration des serveurs de zone


@ IN MX 5 lx1
@ IN NS lx1.esat.terre.def.
@ IN A 160.192.11.112
@ IN NS svrsnx.esat.terre.def.
@ IN A 160.192.11.120
HINFO "Pentium" "Mandrake 6.0 "
TXT "Administrateur poste 007"

; déclaration des stations de la zone


lx1 IN A 160.192.11.112
svrsnx IN A 160.192.11.120
svr215 IN A 160.192.11.110 ; station ayant deux adresses IP
IN A 160.192.11.111
wks215 IN A 160.192.11.112
lx2 IN A 160.192.11.113

; déclaration des alias des stations


dns IN CNAME lx1
web IN CNAME svr215.esat.terre.def. ; variante de syntaxe

11/10/09 23243440.doc 33
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Cet exemple se veut relativement complet car il comporte une entrée MX au profit d'un
serveur de courrier, ainsi qu'un alias de nom du serveur.

SOA (Start of Authority) :


Dans l'exemple, le serveur lx1.esat.terre.def a autorité sur le domaine esat.terre.def.
root@lx1.esat.terre.def est l'adresse de courriel de l'administrateur du domaine (voire
du service).

NS (Name Server) :
Définition du serveur primaire de zone et des serveurs secondaires (ici
svrsnx.esat.terre.def est l'adresse d'un serveur DNS secondaire). Depuis la version
Bind-8, le processus démon "named" informe les autres serveurs mentionnés par NS.
TXT : Commentaires particuliers.
Les informations concernant ces options sont visibles à l'aide de la commande
nslookup utilisée en interactif (> ls –t HINFO).

3.1.10. Requêtes inverses


Cet exemple décrit le fichier /var/named/named.rev (nota : le nom du fichier et son répertoire
ont été définis dans le fichier /etc/named.boot ou named.conf).

; /var/named/named.rev

; déclaration de l'autorité administrative


@ IN SOA lx1.esat.terre.def. root.lx1.esat.terre.def. (
16 ; numéro de série
1D ; rafraîchissement journalier
1H ; tentative toutes les heures
42D ; expiration au bout de 42 jours
1W ; TTL minimale d'une semaine
)

; déclaration des serveurs de zone


@ IN NS lx1.esat.terre.def.
@ IN A 160.192.11.112

; déclaration des stations de la zone


112.11 IN PTR lx1.esat.terre.def.
120.11 IN PTR svrdmsisnx.esat.terre.def.
110.11 IN PTR svr215.esat.terre.def.
111.11 IN PTR wks215.esat.terre.def.
112.11 IN PTR lx2.esat.terre.def.

11/10/09 23243440.doc 34
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Il est à noter que l'autorité de zone est rappelée au début de tout fichier, ainsi que le nom du
serveur DNS primaire (et secondaire s'il existe).
Il faut veiller de plus, dans ce fichier, à la présence du point final (ou racine) dans toutes les
adresses de fin d'enregistrement.
Seuls les deux derniers octets inversés des adresses IP des stations du domaine débutent les
enregistrements. Cela sous-entend que le nom du domaine inverse décrit dans named.boot ou
named.conf comporte les deux premiers octets inversés suivi de in-addr.arpa.

3.2. Côté Clients

3.2.1. Client UNIX


La configuration du service DNS côté client se résume à la déclaration de l’adresse IP des
serveurs.
Le fichier /etc/resolv.conf est le principal fichier à configurer.
Une syntaxe particulière est utilisée pour définir le ou les serveurs de noms utilisés
(généralement jusqu'à 3).
La recherche s'effectue dans l'ordre des serveurs de noms.
Si aucune information est indiquée dans le fichier /etc/resolv.conf, la résolution s'effectue
exclusivement en utilisant le service DNS local à la machine cliente (fichier /etc/hosts).
Les mots réservés sont :
domain pour rappeler le nom de domaine d'appartenance,
search pour définir les ordres de recherche du (ou des) domaine(s),
nameserver suivi de l'adresse IP du serveur DNS local (ou de rattachement).

Exemple 1

;/etc/resolv.conf
search esat.terre.def
nameserver 160.192.11.112
nameserver 160.192.11.120

Il est possible d'indiquer plusieurs valeurs derrière l'entrée search, mais ceci dans l'ordre
hiérarchique inverse de l'espace nom de domaine DNS, comme dans l’exemple ci-dessous.

Exemple 2

;/etc/resolv.conf
search esat.terre.def terre.def

La ligne search ne doit pas contenir de domaine de premier niveau (TLD).

11/10/09 23243440.doc 35
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Il est conseillé de ne pas mettre trop de noms de domaine dans la ligne search car cela prend
du temps au resolver de tous les essayer.
Il existe un autre fichier de configuration, le fichier /etc/host.conf qui précise l'ordre de
priorité d'utilisation des différents services de résolution de noms.

;/etc/host.conf
order bind, nis, hosts
multi on
La station cliente ci-dessus utilise en priorité le service DNS BIND, puis le service NIS, et
enfin le fichier de résolution local /etc/hosts.
L'option multi autorise plusieurs enregistrements pour une même machine dans le fichier
/etc/hosts.

3.2.2. Client Windows


Sur un système Windows, il faut visualiser les propriétés du service TCP/IP de la station
cliente (Panneau de configuration / Réseau ou Voisinage Réseau / Propriétés).
Une fois la fenêtre lancée, il faut repérer l'onglet DNS, ou un bouton "Configuration
Avancée".
On retrouve alors les trois champs correspondants aux paramètres domain, search et
nameserver.

3.3. Débogage du Serveur

3.3.1. Fichiers journaux


En cas de problème de fonctionnement, il convient de consulter les fichiers journaux usuels
tels que /var/log/messages (commande tail pour visualiser les dernières lignes du fichier).

Exemple 1
merlin:/root # tail /var/log/messages
Oct 26 03:42:09 merlin named[2202]: starting
Oct 26 03:42:09 merlin named[2202]: cache zone "" loaded (serial 0)
Oct 26 03:42:09 merlin named[2202]: primary zone "1.168.192.IN-ADDR.ARPA" loaded
(serial 199810111)
Oct 26 03:42:09 merlin named[2202]: primary zone "esat.hosts" loaded (serial 199811301)
Oct 26 03:42:09 merlin named[2203]: Ready to answer queries.
Il n'y a pas d'erreurs dans le message ci-dessus.

Exemple 2
Oct 26 03:47:57 merlin named[2236]: esat.rev: Line 9: Unknown type: PT.
Oct 26 03:47:57 merlin named[2236]: esat.rev: line 9: database format error (PT)
Oct 26 03:47:57 merlin named[2236]: primary zone "1.168.192.IN-ADDR.ARPA" rejected

11/10/09 23243440.doc 36
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

due to errors (serial 199810111)


Une erreur concernant le fichier esat.rev est indiquée à la ligne 9. Il ne reste plus qu'à éditer le
fichier, le corriger, puis relancer le serveur DNS (/etc/rc.d/init.d/named restart ou ndc
restart).
Le contenu du fichier /var/log/messages, géré par le processus démon syslog, est paramétrable
à l'aide de son fichier de configuration, syslog.conf.

3.3.2. Commande nslookup


Le principal outil pour déboguer reste la commande TCP/IP nslookup accessible à tout
utilisateur comme la commande ping.
Il se peut que cette commande ne soit pas disponible sur la station : il faut pour cela installer
le paquetage bind-utils-…
L'aide en ligne sous UNIX (man nslookup) indique les deux modes de fonctionnement de la
commande : mode interactif ou non.
Le mode interactif consiste à lancer la commande sans arguments.
Le mode non interactif attend derrière le nom de la commande, soit le nom de domaine de la
station dont on veut connaître l'adresse IP, soit l'adresse IP de la station dont on veut
connaître le nom de domaine.
Quel que soit le mode, il faut saisir exit ou ^D pour quitter l'utilitaire.

Exemples de commandes nslookup

# nslookup Lancement de la commande en mode


interactif. Le serveur primaire configuré par
Default Server : svr2.esat.terre.def
défaut sur le poste client répond.
Address : 160.192.61.37
> 160.192.21.125
Server : svr2.esat.terre.def Requête de résolution inverse.
Address : 160.192.61.37 Le nom du serveur consulté est indiqué avant
la réponse à la requête.
Name : C201-101-1775.esat.terre.def
Address : 160.192.21.125
>^D Pour quitter la commande (ou exit).

# nslookup C201-101-1775.esat.terre.def Lancement de la commande en mode non


Server : svr1.esat.terre.def interactif.
Address : 160.192.15.31
Name : C201-101-1775.esat.terre.def
Address : 160.192.21.125
> set q=mx
> svrxchange La commande set q=mx (q pour query)
Server : svr1.esat.terre.def interroge le serveur sur ces enregistrements
Address : 160.192.15.31
11/10/09 23243440.doc 37
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

esat.terre.def preference = 10, mail MX (mail exchanger).


exchanger = svrxchange.esat.terre.def
svrxchange.esat.terre.def internet address =
160.192.15.33

> set all La commande set all permet d'afficher toutes


… les options de la commande et leurs valeurs
du moment.

La commande lance le transfert de la zone


> ls esat.terre.def

indiquée moyennant autorisation. Une
redirection vers un fichier est possible.

> server svresat.esat.terre.def Cette commande permet d'interroger un autre


> serveur que son serveur de rattachement
(commande lserver pour revenir au serveur
local).
> set q=ns Cette requête vise à connaître les serveurs de
noms (ns pour name server) d'une zone
donnée dans la requête suivante.
> terre.def.
Réponse de source secondaire :
terre.def nameserver = dns-bdx.terre.def
dns-bdx.terre.def = 208.5.120.85

> set q=any Cette requête permet de rechercher tout type


de données.
> cname
Server svr1.esat.terre.def Recherche d'alias.
Address 160.192.15.31
"cname" canonical name = ...
"domaine" "vrai nom"
nameserver = "vrai nom"
"vrai nom" internet-addr = 160...
> nslookup 160.192.61.37 Réponse de la commande nslookup cherchant
Non-authoritative answer : sa réponse dans le cache interne du client.
Name : C201-301-0458.esat.terre.def
Address : 160.192.61.37

> nslookup 160.192.61.37 Non-existent host/domain indique que le


domaine demandé n'existe pas.
*** svr1.esat.terre.def ne parvient pas à
trouver 160.192.61.37: Non-existent domain

Les erreurs renvoyées par la commande nslookup sont précédées par trois étoiles. Elles sont
définies par le protocole DNS.
 No <type> records available for <domaine> indique que le domaine existe mais aucun
enregistrement de ce type n'est enregistré pour ce domaine.
 Request to <serveur> timed-out indique que le serveur n'a pas répondu. Plusieurs
causes sont possibles:

11/10/09 23243440.doc 38
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

o Le serveur désigné ne peut être atteint (à tester avec la commande ping).


o Le serveur désigné n'a pas pu joindre les serveurs DNS nécessaires pour
obtenir l'information.
o Le serveur désigné est mal configuré.
o Server failure indique que la base de données d'un serveur interrogé est
incomplète.
La sous-commande set permet d'interroger tous les enregistrements des fichiers de zone du
serveur DNS. Les options de cette commande set sont listées dans le fichier de configuration
caché .nslookuprc.

3.3.3. Commande dig


En dehors de la commande nslookup, il existe d'autres commandes limitées au monde UNIX
dont la commande dig réservée à l'administrateur.
Celle-ci permet en premier lieu de télécharger la liste des serveurs racine, en deuxième
d’interroger les serveurs sur le contenu de leurs fichiers cache.

Exemples

dig Sans arguments, affiche le contenu du fichier "named.ca" du serveur


local.
dig nameserver Affiche le contenu du fichier « named.ca » du serveur indiqué.
dig @.root.servers.net Télécharge le fichier cache des serveurs racine d’Internet.

3.4. Sécurité
Un premier niveau de sécurité permet de filtrer les adresses IP :
 Pour n'autoriser les transferts de zone que vers les serveurs de noms secondaires désignés
 Pour n'autoriser que les requêtes en provenance des stations appartenant à la zone de
responsabilité du serveur
options {
directory "/var/named";
notify yes;
allow-transfer{
192.168.26.84;
};
allow-query{
192.168.0.0/24;
};
};

11/10/09 23243440.doc 39
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

3.5. Boîte à Outils


Sous Linux, l'utilitaire linuxconf (versions 6 et 7 de la distribution Mandrake) permet de
configurer le service DNS à la fois côté Serveur et côté Client.
Il existe actuellement un empaquetage logiciel graphique, présent dans toutes les distributions
Linux, qui aide l'administrateur dans toutes ses taches réseau : Webmin. L'annexe présente
les principaux écrans d'administration à distance.

Si la configuration comporte au préalable un fichier /etc/hosts , le programme hostcvt (fourni


avec BIND) permet de migrer vers un vrai service DNS en générant les fichiers de zone
(named.hosts et named.rev). Une attention particulière doit être portée lors de l'ajustement de
certains paramètres.
L'utilitaire h2n rend le même service.

4. CONCLUSION

Cette étude, relativement sommaire, permet à tous, de comprendre le service de noms de


domaine, et de mettre en œuvre un serveur sous UNIX.
La dernière version de BIND, la version 9.1.2 (ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz),
que l'on peut installer sous Windows (ftp.isc.org/isc/bind/contrib/ntbind-9.2.1/BIND9.2.1.zip)
apporte des améliorations majeures :
 La sécurité du monde DNS (ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz.asc sous
UNIX ou ftp.isc.org/isc/bind/contrib/ntbind-9.2.1/BIND9.2.1.zip.asc sous Windows),
mettant en œuvre DNSSEC pour la signature de zones, TSIG pour les requêtes
signées ;
 Le support d'IP v6 impliquant l'apparition d'enregistrements spécifiques ;
 D'autres améliorations dont la gestion du DDNS (Dynamic DNS) de plus en plus
prisé.

Quelques ouvrages de référence sont proposés :


1. DNS and BIND, Paul Albitz & Cricket Liu (Edition O’Reilly).
2. Documentation locale de LINUX (le DNS HOWTO de Nicolai Langfeldt).

11/10/09 23243440.doc 40
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Annexe 1 : Administration locale avec Linuxconf

Le programme
linuxconf se lance
depuis le menu
graphique démarrer ou
en ligne de
commandes.
Une fois cet utilitaire
lancé, on choisit le
bouton "Réseau" (ou
l'option réseau).
Sur l'onglet "Tâches
serveur" doit
apparaître la fonction
"Domain Name
Server".
Un clic sur cette option
lance la fenêtre
suivante.

Différents onglets sont


proposés :
• Configuration
du serveur lui-
même
• Ajouter/éditer
les stations
hôtes du
domaine
• Sécurité (non
traitée dans ce
document).
L’onglet Configuration
propose huit boutons.

Pour définir la (ou les) zone(s) gérées par le serveur, cliquons sur le bouton domaines.

11/10/09 23243440.doc 41
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Cette fenêtre indique


que le serveur est
primaire pour aucune
zone.
Pour déclarer une zone,
cliquons sur le bouton
Ajouter.

La fenêtre suivante
présente quatre
onglets : serveurs de
noms, serveurs de
courriers, adresses IP et
autres fonctionnalités.
Le premier onglet nous
permet de renseigner :
• Le nom de domaine
à gérer
• Le serveur primaire
du domaine ou de
la zone
• L’adresse de
courriel de
l’administrateur
• Les serveurs de
noms secondaires
Le deuxième onglet sert à désigner les serveurs de courrier du domaine, et leur ordre
d’importance.
Le troisième onglet permet d’affecter les adresses IP par défaut de chacun des serveurs.
Une fois les quatre onglets remplis, il faut cliquer sur le bouton Accepter.

11/10/09 23243440.doc 42
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

L’onglet
Ajouter/Editer permet
de configurer la liste
des stations hôtes
du(es) domaine(s).

Un clic sur le bouton


Information de
machine par domaine
lance la fenêtre
suivante.

Les seules informations


affichées concernent le
serveur précédemment
déclaré.
Dans l’onglet d’édition,
cliquons sur le bouton
Ajouter/Editer pour
déclarer une nouvelle
station.

La fenêtre qui apparaît


ci-contre propose deux
boutons : Nom et
Valeur.
Un clic sur le premier
lance la fenêtre
suivante.

11/10/09 23243440.doc 43
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Cette fenêtre permet de


déclarer le nom de
domaine complet de la
station.
Une fois celui-ci saisi,
il faut valider en
cliquant sur le bouton
Accepter.

La validation
précédente lance cette
nouvelle fenêtre où
l’on peut configurer
son (ses) adresse(s) IP,
son alias, etc…

Un clic sur le nouveau


bouton Accepter valide
l’ensemble des
données.

11/10/09 23243440.doc 44
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Annexe 2 : Administration distante avec Webmin


Le graticiel Webmin permet, via une interface web sécurisé, d'administrer à distance
l'ensemble des services UNIX.

Après le lancement de Webmin et l'authentification sécurisée franchie, l'onglet "servers" nous


présente les icônes d'accès à l'administration des services, en particulier des services BIND.
Etant donné la présence simultanée de plusieurs versions sur un parc donné, il est possible de
d’utiliser simultanément un serveur BIND 4 et un serveur BIND 8.
La suite de cette présentation ne traitera que la configuration d'un serveur BIND 8, à titre
d’exemple.

Ecran principal
L'écran suivant offre surtout des icônes (et liens) d'accès à ces principales options. Pour des
raisons pédagogiques, l'écran a été coupé en deux parties d'écran affichées ci-après.

La première partie présente les options globales du serveur :


 La première icône permet de définir les relations avec les autres serveurs : primaire et
secondaire.
 La deuxième icône permet d'accéder aux fichiers journaux ou d'erreurs.
11/10/09 23243440.doc 45
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

 La troisième gère les listes de contrôle d'accès au serveur.


 La quatrième permet de redéfinir l'emplacement des fichiers de zone ou autre.
 La cinquième, dans le cas d'un fonctionnement itératif, donne la liste des autres serveurs à
consulter.
 La sixième aide à remplir les fichiers de zone.
 La septième ajoute des options d'administration fine.
 La huitième configure l'interface.

La deuxième partie de l'écran est découpée en trois secteurs : une réservée à la gestion des
zones, une dédiée aux différentes vues que l' (ou les) administrateur(s) peuvent utiliser pour
surveiller le serveur, une troisième pour redémarrer le serveur après modification des
paramètres.
La première partie donne accès sous forme d'icônes aux zones déjà définies : la zone racine
(root zone ou fichier cache), et la zone locale (127…).
Les autres menus permettent de créer :
• une zone maître (le serveur sera DNS primaire de cette zone),
• une zone esclave (le serveur sera DNS secondaire de cette zone),
• une zone stub (ceci permet de désigner, dès le fichier de configuration, un
domaine enfant délégué et son serveur),
• une zone forward (le serveur local consultera le[s] serveur[s] retransmetteur[s]
désigné[s] avant de consulter les serveurs racine de son cache)

Ecrans secondaires

Zone "127.0.0.1"
Pour la zone locale, l'écran suivant s'affiche.

11/10/09 23243440.doc 46
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

On retrouve les différents types d'enregistrements évoqués dans le document : nom du


serveur, adresse inverse, alias, paramètres du serveur, enregistrements d'adresses, bloc à
options.

Zone maitre
Si l'on clique sur le premier menu, l'écran suivant nous permet de renseigner les différents
champs propres à l'enregistrement d'un serveur de noms.

Ces différents champs permettent de rajouter le bloc d'instructions nécessaire dans le fichier
de configuration /etc/named.conf, puis de créer le fichier de zone indiqué (records file) en
écrivant le squelette du fichier concernant l'enregistrement SOA.
Le nom du fichier de zone va de pair avec le rôle qu'il joue ; il faut d'abord préciser le type de
résolution : normale (forward) ou inverse (reverse).
Afin de faciliter le travail de l'administrateur, il est possible de définir et donc de réutiliser
des fichiers modèle (template).

11/10/09 23243440.doc 47
Systèmes Répartis SYSTEMES HETEROGENES Domain Name Server

Zone esclave
L'écran qui suit concerne le paramétrage d'une zone de serveur secondaire ou esclave.

Paramètres par défaut


Ce dernier écran permet à l'administrateur de fixer un certain nombre de valeurs par défaut
pour des paramètres techniques concernant l'ensemble des fichiers du serveur :
• les fichiers de zone dont le serveur est maître (dialogue avec le secondaire),
• les paramètres de sécurité (autorisation de transfert de zone, acceptation des requêtes,…)
• les paramètres de vérification de fonctionnement des serveurs (check).

11/10/09 23243440.doc 48