System)
‹ ‹# 3UpVHQWDWLRQ#JpQpUDOH
„ Système de nom de domaine (DNS)
„ Résolution des noms
„ Configuration des fichiers DNS
„ Planification de la mise en œuvre du DNS
2EMHFWLIV
À la fin de ce module, vous serez à même d'effectuer les tâches suivantes :
„ Décrire la structure et l'architecture du système de nom de domaine (DNS, Domain Name System).
„ Définir les composants du système de nom de domaine.
„ Expliquer de quelle manière DNS est utilisé pour résoudre les noms et les adresses IP.
„ Décrire le contenu des fichiers de base de données DNS.
„ Inscrire un serveur DNS auprès de son domaine parent.
2EMHFWLI#GH#OD GLDSRVLWLYH 'RQQHU#XQ#DSHUoX#GHV VXMHWV#HW#GHV#REMHFWLIV#GH#FH PRGXOH1
,QWURGXFWLRQ
&H#PRGXOH#FRQVWLWXH#XQH YXH#G*HQVHPEOH#GH#OD VWUXFWXUH#HW#GHV#FRPSRVDQWV GX#V\VWqPH#GH#QRP#GH GRPDLQH#+'16/#'RPDLQ 1DPH#6\VWHP,1#1RXV pWXGLHURQV#OHV#PpFDQLVPHV GH#UpVROXWLRQ#7&32,3/#OD FRQILJXUDWLRQ#GHV#ILFKLHUV '16#HW#O*LQVFULSWLRQ#G*XQ VHUYHXU#'16#DXSUqV#GH#VRQ GRPDLQH#SDUHQW1
6\VWqPH#GH#QRP#GH#GRPDLQH#+'16,
Vert
Bleu
Rouge
Jaune
Orange
Violet
SRI-NIC
Vert 191.105.6.10 Bleu 195.200.90.2 Rouge 202.131.6.200 Jaune 159.166.99.67 Orange 121.17.6.22 Violet 212.191.7.45
Hosts.txt FTP Orange
Avant 1980, l'ARPANET ne comportait que quelques centaines d'ordinateurs en réseau. Le mappage nom d'ordinateur/adresse IP était contenu dans un fichier unique nommé Hosts.txt. Ce fichier était stocké à Menlo Park
(Californie), dans l'ordinateur hôte du centre d'informations réseau du Stanford Research Institute (SRI-NIC, Stanford Research Institute's Network Information Center). Quand cela était nécessaire, les autres ordinateurs hôtes de
l'ARPANET copiaient le fichier Hosts.txt sur leurs sites à partir du SRI-NIC.
À l'origine, ce mécanisme fonctionnait de manière satisfaisante dans la mesure où la liste contenue dans le fichier Hosts.txt ne devait être mise à jour qu'une ou deux fois par semaine. Cependant, en quelques années, des problèmes ont surgi du fait de l'accroissement constant de la taille de l'ARPANET :
„ Le fichier Hosts.txt était devenu trop volumineux.
„ Le fichier devait être actualisé plusieurs fois par jour.
„ Dans la mesure où tout le trafic réseau devait être routé via le SRI-NIC, la maintenance de Hosts.txt représentait un goulet d'étranglement pour l'ensemble du réseau.
„ Au niveau de l'hôte SRI-NIC, le trafic réseau était devenu pratiquement impossible à gérer.
„ Hosts.txt utilisait une structure de dénomination à plat (espace de noms).
C'est pourquoi chaque nom d'ordinateur devait être unique par rapport à l'ensemble du réseau.
2EMHFWLI#GH#OD GLDSRVLWLYH
'pILQLU#OH#V\VWqPH#GH#QRP GH#GRPDLQH#+'16,1 ,QWURGXFWLRQ /H#'16#+'RPDLQ#1DPH 6\VWHP,#HVW#XQH#EDVH#GH GRQQpHV#GLVWULEXpH#TXL V*DSSXLH#VXU#XQH#VWUXFWXUH GH#QRPV#KLpUDUFKLVpH1
3RXU#YRWUH#LQIRUPDWLRQ /H#'16#HVW#GpFULW#GDQV#OHV 5)ᄏ#HW#43681#9RXV WURXYHUH]#XQH#FRSLH#GH#FHV 5)&#GDQV#OD#SDJH#:HE
&RXUVH#0DWHULDOV1
Ces problèmes, et d'autres, ont amené l'instance dirigeante de l'ARPANET à rechercher une solution pouvant remplacer le mécanisme mis en place autour du fichier Hosts.txt. Cette décision a conduit à la création d'un système de nom de domaine, le DNS (Domain Name System). Ce dernier est une base de données distribuée qui s'appuie sur une structure de noms hiérarchisée (espace de noms hiérarchisé).
Le système de nom de domaine (DNS) est décrit dans les RFC 1034 et 1035. Vous trouverez une copie de ces RFC dans la page Web Course Materials, enregistrée sur le CD-ROM du cours.
5HPDUTXH
)RQFWLRQQHPHQW#GX#'16
Application Application
Transport Transport
Internet Internet
Réseau Réseau
Application Application
Transport Transport
Internet Internet
Réseau Réseau Solveur
DNS
Serveur de nom
Sockets
Le système de nom de domaine (DNS) est un système de gestion de base de données (SGBD) client-serveur distribué et hiérarchisé. DNS fonctionne au niveau de la couche application et utilise UDP et TCP en tant que protocoles sous-jacents.
Le rôle de la base de données DNS consiste à traduire les noms d'ordinateurs en adresses IP. Dans DNS, les clients sont appelés solveurs (resolvers) ; ils adressent leur requête à des serveurs de nom (name servers).
Il est possible de faire une analogie entre le système de nom de domaine et l'annuaire téléphonique. L'utilisateur recherche le nom de la personne ou de l'organisation qu'il veut contacter, et opère une référence croisée entre ce nom et un numéro de téléphone. De même, la machine hôte cherche à contacter un ordinateur par son nom, et un serveur de nom de domaine effectue une référence croisée entre ce nom et une adresse IP.
Les solveurs envoient tout d'abord des requêtes UDP aux serveurs, afin d'améliorer les performances de l'opération. Ils ne recourent à TCP que si les données renvoyées sont tronquées.
6ROYHXUV
La fonction des solveurs consiste à faire transiter les demandes de nom entre les applications et les serveurs de noms. La demande de nom contient une requête.
Cette requête peut, par exemple, demander l'adresse IP d'un site WWW. Le plus souvent, le solveur est intégré à l'application ou s'exécute sur l'ordinateur hôte en tant que routine de bibliothèque.
6HUYHXUV#GH#QRPV
Les serveurs de noms réceptionnent les requêtes de nom émanant des solveurs.
Ensuite, ils résolvent les noms d'ordinateur (ou de domaine) en adresses IP. Si le serveur de nom n'est pas en mesure de satisfaire à la requête, il peut la renvoyer à un autre serveur de nom susceptible d'y répondre. Les serveurs de noms sont regroupés dans différents niveaux appelés domaines.
2EMHFWLI#GH#OD GLDSRVLWLYH
'pFULUH#O*DUFKLWHFWXUH#GX '161
,QWURGXFWLRQ 'DQV#OH#FDV#G*XQH
FRPPXQLFDWLRQ#'16#VLPSOH/
XQ#FOLHQW#'16/#RX#VROYHXU/
HQYRLH#GHV#UHTXrWHV#j#XQ VHUYHXU#GH#QRP1#/H#VHUYHXU UHQYRLH#OHV#LQIRUPDWLRQV GHPDQGpHV/#RX#XQ#SRLQWHXU VXU#XQ#DXWUH#VHUYHXU#GH QRP/#RX#HQFRUH#XQ#PHVVDJH G*pFKHF#VL#OD#UHTXrWH#QH SHXW#rWUH#VDWLVIDLWH1
&RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#H[SOLTXHU#OHV U{OHV#MRXpV#SDU#OHV#VROYHXUV HW#OHV#VHUYHXUV#GH#QRPV1
(VSDFH#GH#QRPV#GH#GRPDLQH
Domaine de niveau racine
Nouvelle-Zélande (NZ) COM EDU ORG
microsoft compaq purdue
Etudiant Seattle
Domaine de niveau supérieur
Domaine de second niveau Pays
'RPDLQHV#GH#QLYHDX#UDFLQH
Les domaines définissent différents niveaux d'autorité à l'intérieur d'une structure hiérarchisée. Le plus haut niveau de cette hiérarchie est appelé domaine racine, représenté par le label null. Cependant, les références à ce domaine peuvent être exprimées par un point (. ).
'RPDLQHV#GH#QLYHDX#VXSpULHXU
Actuellement, les domaines de niveau supérieur sont les suivants :
„ com : organisations commerciales
„ edu : universités et institutions éducatives
„ org : organisations à but non-lucratif
„ net : réseaux (structure dorsale de l'Internet)
„ gov : organisations gouvernementales autres que militaires
„ mil : organisations gouvernementales militaires
„ num : numéros de téléphone
„ arpa : DNS inverse
„ xx : code de deux lettres correspondant à un pays
Les domaines de niveau supérieur peuvent contenir des hôtes et des domaines de second niveau.
2EMHFWLI#GH#OD GLDSRVLWLYH 'pFULUH#OD#VWUXFWXUH#GX V\VWqPH#GH#QRP#GH GRPDLQH1
,QWURGXFWLRQ /*HVSDFH#GH#QRPV#GH GRPDLQH#UHJURXSH#OHV#QRPV GH#PDQLqUH#KLpUDUFKLVpH/#DX VHLQ#G*XQH#VWUXFWXUH VHPEODEOH#j#XQ#DUEUH LQYHUVp1
&RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#GpFULUH#OHV GLIIpUHQWV#QLYHDX[#GH GRPDLQH1
'RPDLQHV#GH#VHFRQG#QLYHDX
Les domaines de second niveau peuvent contenir à la fois des hôtes et d'autres domaines, appelés sous-domaines. Le domaine Microsoft (microsoft.com), par exemple, peut contenir des ordinateurs tels que ftp.microsoft.com et des sous- domaines tels que dev.microsoft.com. À son tour, le sous-domaine
dev.microsoft.com peut contenir des hôtes tels que ntserver.dev.microsoft.com.
1RPV#G*K{WH
Les noms d'hôtes au sein d'un domaine sont ajoutés au début du nom de ce domaine. La combinaison nom d'hôte et nom de domaine est souvent appelée nom de domaine complet, ou « pleinement qualifié » (il s'agit du FQDN, Fully Qualified Domain Name). Par exemple, un hôte nommé fileserver et situé dans le domaine microsoft.com est affecté du nom de domaine complet (FQDN) suivant : fileserver.microsoft.com.
=RQHV#G*DXWRULWp
CORP
R&D
MKTG com
Microsoft
Serveurs de nom
Serveur de nom
Serveur de nom Zone 1
Zone 3
Zone 2
Une zone d'autorité est une portion de l'espace de noms de domaine placée sous la responsabilité d'un serveur de nom particulier. Ce serveur de nom stocke tous les mappages d'adresse correspondant à la partie de l'espace de noms de
domaine qui relève de sa zone. Il répond aux requêtes émanant des clients et se rapportant à ces noms.
La zone d'autorité d'un serveur de nom recouvre au moins un domaine. Celui-ci est appelé domaine racine de la zone. La zone d'autorité peut également inclure des sous-domaines du domaine racine de cette zone. Cependant, une zone ne contient pas obligatoirement tous les sous-domaines de son propre domaine racine.
Dans la représentation graphique, microsoft.com est un domaine, mais il n'est pas contrôlé en totalité par un fichier de zone unique. Une partie du domaine relève d'un fichier de zone distinct, pour mktg.microsoft.com et
R&D.microsoft.com. La répartition d'un domaine sur plusieurs fichiers de zone peut être nécessaire afin de répartir la gestion de ce domaine sur différents groupes, ou pour améliorer la duplication des données.
Un serveur DNS unique peut être configuré pour gérer un ou plusieurs fichier(s) de zone. Chaque zone est rattachée à un nœud de domaine spécifique, appelé domaine racine de la zone.
2EMHFWLI#GH#OD GLDSRVLWLYH 'pILQLU#OH#FRQFHSW#GHV ]RQHV/#HW#FRPPHQW#HOOHV VRQW#XWLOLVpHV1
,QWURGXFWLRQ
8QH#]RQH#G*DXWRULWp#HVW#OD SRUWLRQ#G*HVSDFH#GH#QRPV GH#GRPDLQH#TXL#HVW#SODFpH VRXV#OD#UHVSRQVDELOLWp#G*XQ VHUYHXU#GH#QRP#VSpFLILTXH1
5{OHV#GHV#VHUYHXUV#GH#QRPV
„ Serveurs de nom principaux
z Informations de zone dans des fichiers gérés localement
„ Serveurs de nom secondaires
z Informations de zone téléchargées à partir d’un serveur de noms maître
„ Serveurs de nom maîtres
z Source d’informations pour un serveur secondaire (peut être un serveur principal ou secondaire)
„ Serveurs cache
z Ne conservent aucune information de zone
Les serveurs DNS peuvent stocker et tenir à jour leur base de données de noms de différentes manières. Chacun des rôles décrit ci-dessous correspond à une configuration particulière du serveur de nom DNS du point de vue du stockage des données de zone.
6HUYHXUV#GH#QRPV#SULQFLSDX[
Le serveur de nom principal obtient les données de zone à partir de fichiers locaux. Les modifications apportées à une zone, telles que l'ajout de domaines ou d'hôtes, sont effectuées au niveau du serveur de nom principal.
6HUYHXUV#GH#QRPV#VHFRQGDLUHV
Un serveur de nom secondaire obtient les données de zone via le réseau, à partir d'un autre serveur de nom qui détient l'autorité pour la zone considérée.
L'obtention des informations de zone via le réseau est appelée transfert de zone.
L'existence des serveurs de noms secondaires est justifiée par trois raisons :
„ Redondance : dans chaque zone, il est nécessaire de mettre en place au moins un serveur de nom principal et un serveur de nom secondaire. Les ordinateurs impliqués doivent être aussi indépendants que possible.
„ Rapidité d'accès aux emplacements distants : s'il existe de nombreux clients dans des emplacements distants, le fait de disposer de serveurs de noms secondaires (ou d'autres serveurs de noms principaux pour les sous-domaines) évite à ces clients de communiquer sur des liaisons lentes pour effectuer la résolution des noms.
„ Réduction de charge : les serveurs de noms secondaires permettent de réduire la charge de travail du serveur principal.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#OHV#GLIIpUHQWV#U{OHV TXH#SHXW#MRXHU#XQ#VHUYHXU GH#QRP1
,QWURGXFWLRQ
/HV#VHUYHXUV#GH#QRPV#'16 SHXYHQW#rWUH#FRQILJXUpV SRXU#MRXHU#GHV#U{OHV GLIIpUHQWV1#&HV#U{OHV GpSHQGHQW#GX#PRGH#GH VWRFNDJH#GHV#GRQQpHV#GH ]RQH1
Dans la mesure où les informations relatives à chaque zone sont stockées dans un fichier distinct, cette distinction principal/secondaire est définie au niveau de la zone. En d'autres termes, un serveur de nom spécifique peut jouer le rôle de serveur de nom principal pour certaines zones, et de serveur de nom secondaire pour d'autres zones.
6HUYHXUV#GH#QRPV#PDvWUHV
Lorsque vous définissez une zone secondaire sur un serveur de nom, vous devez désigner un autre serveur de nom à partir duquel le serveur secondaire pourra obtenir ses informations de zone. Dans une hiérarchie DNS, on appelle serveur de nom maître la source à partir de laquelle un serveur de nom
secondaire obtient ses informations de zone. Un serveur de nom maître peut être soit un serveur de nom secondaire, soit un serveur de nom principal pour la zone considérée. Quand un serveur de nom secondaire démarre, il contacte son serveur de nom maître et entame un transfert de zone avec ce serveur.
6HUYHXUV#FDFKH
Bien que tous les serveurs de noms DNS mettent en cache les requêtes qu'ils ont résolues, les serveurs cache présentent une particularité : il s'agit de serveurs de noms DNS qui se contentent de répondre aux requêtes, de mettre les réponses en cache, et de renvoyer les résultats. En d'autres termes, ils ne sont investis d'aucune autorité, pour quelque domaine que ce soit (aucune donnée de zone n'est conservée localement). Ils ne contiennent que les informations qu'ils ont placées en cache à l'occasion de la résolution des requêtes.
Pour décider de l'opportunité d'utiliser un serveur de ce type, gardez à l'esprit que lorsqu'il démarre, il ne dispose d'aucune information en cache et qu'il doit rassembler ces informations peu à peu, à mesure qu'il répond aux requêtes.
Cette solution génère beaucoup moins de trafic sur des liaisons lentes, puisque ce serveur n'effectue pas de transfert de zone. Ceci peut se révéler important si vous devez exploiter une liaison lente entre des sites.
5pVROXWLRQ#GHV#QRPV
Serveur de nom local
Serveur de nom racine
Serveur de nom gov
Serveur de nom whitehouse.gov Client
DNS Requête
récursive
Requêtes itératives
11
2 2 33
44
55 66
7 8 7
8
Les requêtes envoyées par un client (solveur) à un serveur DNS peuvent être de trois types : récursives, itératives et inverses.
5HTXrWHV#UpFXUVLYHV
Dans une requête récursive, le serveur de nom interrogé doit renvoyer soit l'information demandée, soit un message d'erreur indiquant qu'il n'existe pas de données du type demandé, ou que le nom de domaine spécifié n'existe pas. Le serveur de nom ne peut pas soumettre la requête à un autre serveur de nom.
5HTXrWHV#LWpUDWLYHV
Dans le cas d'une requête itérative, le serveur de nom interrogé renvoie au demandeur la meilleure réponse qu'il peut lui apporter actuellement. Il peut s'agir du nom résolu, ou d'un renvoi vers un autre serveur de nom qui sera peut- être en mesure de satisfaire la demande initiale.
La représentation graphique présente un exemple de requête récursive et de requête itérative. Un client situé au sein de Microsoft Corporation demande à son serveur DNS l'adresse IP de www.whitehouse.gov.
1. Le solveur envoie une requête DNS récursive à son serveur DNS local en lui demandant l'adresse IP de www.whitehouse.gov. Le serveur de nom local assume seul la responsabilité de la résolution des noms, et ne peut pas référer le solveur à un autre serveur de nom.
2. Le serveur de nom local analyse ses zones, et n'en trouve aucune qui corresponde au nom de domaine demandé. Il envoie alors une requête itérative portant sur www.whitehouse.gov à un serveur de nom racine.
3. Le serveur de nom racine fait autorité pour le domaine racine, et va répondre en renvoyant l'adresse IP d'un serveur de nom desservant le domaine de niveau supérieur gov.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#OH#IRQFWLRQQHPHQW GHV#UHTXrWHV#UpFXUVLYHV#HW GHV#UHTXrWHV#LWpUDWLYHV1 ,QWURGXFWLRQ 8Q#FOLHQW#+VROYHXU,#SHXW DGUHVVHU#WURLV#W\SHV#GH UHTXrWHV#j#XQ#VHUYHXU#'16#=
UpFXUVLYHV/#LWpUDWLYHV#HW LQYHUVHV1
&RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#H[SOLTXHU#OH FRQFHSW#GH#UHTXrWH UpFXUVLYH#HW#GH#UHTXrWH LWpUDWLYH1
4. Le serveur de nom local envoie à son homologue du domaine gov une requête itérative portant sur www.whitehouse.gov.
5. Le serveur de nom du domaine gov répond en renvoyant l'adresse IP du serveur de nom desservant le domaine whitehouse.gov.
6. Le serveur de nom local envoie à son homologue du domaine
whitehouse.gov une requête itérative portant sur www.whitehouse.gov.
7. Le serveur de nom du domaine whitehouse.gov répond en renvoyant l'adresse IP correspondant à www.whitehouse.gov.
8. Le serveur de nom local renvoie l'adresse IP de www.whitehouse.gov au solveur initial.
5HTXrWHV#LQYHUVHV
„ Domaine spécial pour les requêtes inverses
z in-addr.arpa
„ Les adresses IP sont converties par inversion pour générer la requête DNS inverse
z 157.55.200.51 donne une requête portant sur 51.200.55.157.in-addr.arpa
Dans le cas d'une requête inverse, le solveur envoie une requête à un serveur de nom afin que celui-ci renvoie le nom d'hôte associé à une adresse IP connue.
Dans l'espace de dénomination DNS, il n'existe pas de corrélation entre les noms d'hôte et les adresses IP. Par conséquent, seule une recherche approfondie portant sur tous les domaines peut garantir l'obtention d'une réponse exacte.
Pour répondre aux requêtes inverses en évitant des recherches exhaustives dans tous les domaines, un domaine spécial appelé in-addr.arpa a été créé. Les nœuds du domaine in-addr.arpa sont nommés sur la base des nombres de la
représentation des adresses IP en notation décimale pointée. Cependant, la spécificité des adresses IP augmente à mesure de leur lecture de la gauche vers la droite, à l'inverse des noms de domaines, qui se précisent de plus en plus par une lecture de la droite vers la gauche. C'est pourquoi il est nécessaire d'inverser l'ordre des octets des adresses IP pour construire le domaine in-addr.arpa. Grâce à ce mécanisme, l'administration de segments inférieurs du domaine in-
addr.arpa peut être confiée aux organisations lorsqu'elles se voient affecter leurs adresses IP de classe A, B ou C.
Une fois le domaine in-addr.arpa construit, des enregistrements de ressource spéciaux sont ajoutés pour associer les adresses IP aux noms d'hôte qui leur correspondent. Il s'agit des enregistrements pointeurs (PTR), ou enregistrements de référence. Par exemple, pour trouver le nom d'hôte associé à l'adresse IP 157.55.200.51, le solveur demande au serveur DNS un enregistrement pointeur pour 51.200.55.157.in-addr.arpa. L'enregistrement pointeur trouvé contient le nom d'hôte et l'adresse IP correspondante, 157.55.200.51. Ces informations sont renvoyées au solveur. L'administration d'un serveur de nom DNS consiste, en partie, à assurer la création d'enregistrements pointeurs pour les hôtes.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#OH#IRQFWLRQQHPHQW G*XQH#UHTXrWH#LQYHUVH1 ,QWURGXFWLRQ /HV#UHTXrWHV#LQYHUVHV SHUPHWWHQW#j#O*DSSOLFDWLRQ#GH UHWURXYHU#OH#QRP#G*XQ#K{WH GRQW#HOOH#FRQQDvW#GpMj O*DGUHVVH#,31
0LVH#HQ#FDFKH#HW#77/
„ Les serveurs DNS mettent en cache les requêtes itératives
„ Chaque entrée mise en cache est affectée d’une durée de vie (TTL, Time to Live)
„ Lorsque la durée de vie expire, l'entrée est supprimée du cache
„ La durée de vie restante est envoyée au solveur dans la réponse récursive
Lorsqu'un serveur de nom traite une requête récursive, il peut être amené à envoyer de nombreuses requêtes pour obtenir une réponse. Le serveur de nom place dans un cache toutes les informations qu'il reçoit au cours de cette procédure, et les conserve pendant une durée spécifiée dans les données renvoyées. Cette période de maintien dans le cache est appelée durée de vie (TTL, Time to Live). La durée de vie des données est définie par
l'administrateur du serveur de nom de la zone contenant ces données. Des valeurs de TTL relativement faibles assurent, au sein du réseau, une plus grande cohérence des données relatives au domaine, notamment si ces données sont modifiées fréquemment. Cependant, elles imposent aux serveurs de noms une charge de travail plus importante.
Dès lors qu'un serveur DNS a placé des données en cache, il doit débuter la décrémentation du TTL, à partir de sa valeur d'origine. Ainsi, il peut déterminer à quel moment ces données devront être supprimées du cache. Si le serveur répond à une nouvelle requête en s'appuyant sur des données du cache, le TTL renvoyé avec ces données équivaut au TTL restant avant suppression des données du cache. Les solveurs clients comportent également des caches de données, et contrôlent les valeurs TTL afin de supprimer les données lorsqu'elles sont arrivées à expiration.
2EMHFWLI#GH#OD GLDSRVLWLYH ([SOLTXHU#FRPPHQW#XQ VHUYHXU#GH#QRP#PHW#HQ FDFKH#OHV#UHTXrWHV UpVROXHV/#HW#WLHQW#FH#FDFKH#j MRXU1
,QWURGXFWLRQ
¬#PHVXUH#TXH#OHV#UHTXrWHV VRQW#UpVROXHV#SDU#OH#VHUYHXU GH#QRP/#OHV#LQIRUPDWLRQV VRQW#SODFpHV#GDQV#XQ#FDFKH/
SRXU#UpSRQGUH#j#GH#IXWXUHV UHTXrWHV1
&RQILJXUDWLRQ#GHV#ILFKLHUV#'16
„ Fichier de base de données (Zone.dns)
z Contient les enregistrements de ressource pour la zone
z Pour l’essentiel, il mappe des noms d’hôte sur des adresses IP
„ Fichier de recherche inverse (Z.Y.W.X.in-addr.arpa)
z Mappe des adresses IP sur des noms d’hôte
„ Fichier de cache (Cache.dns)
z Noms et adresses des serveurs de noms du domaine racine
„ Fichier d'amorçage
z Utilisé pour le mode d’initialisation manuelle
Les fichiers décrits ci-dessous sont associés à la grande majorité des serveurs DNS :
Nom Description
Fichier de base de données
(Zone.dns)
Le fichier de base de données contient les enregistrements de ressource pour un domaine. Si votre zone est
microsoft.com, par exemple, ce fichier sera nommé Microsoft.com.dns. Windows NT 4.0 comporte un exemple de fichier de base de données de ce type, nommé Place.dns.
Il s'agit d'un modèle sur lequel vous pouvez travailler. Ce fichier doit être édité et renommé avant d'être utilisé sur un serveur DNS de production. Généralement, il est judicieux d'attribuer à ce fichier un nom correspondant à la zone qu'il représente. C'est ce fichier qui sera dupliqué entre les serveurs maîtres et les serveurs secondaires.
Fichier de recherche inverse
(Z.Y.W.X.in-addr.arpa)
Le fichier de recherche inverse mappe les adresses IP sur les noms d'hôte. Par exemple, si votre réseau est affecté de l'adresse réseau de classe C 192.138.154.0, ce fichier sera nommé 154.138.192.IN-ADDR.ARPA.
Fichier de cache (Cache.dns)
Pour l'essentiel, le fichier de cache est identique sur tous les serveurs de noms, et doit être présent. Ce fichier contient le nom et l'adresse des serveurs de noms qui gèrent le domaine racine.
Fichier d'amorçage Généralement, le fichier d'amorçage est utilisé par un serveur DNS pour établir sa configuration au démarrage. Ce fichier contient les informations d'hôte nécessaires pour résoudre des noms situés en dehors des domaines pour lesquels il détient l'autorité.
2EMHFWLI#GH#OD GLDSRVLWLYH
'pFULUH#OHV#ILFKLHUV#XWLOLVpV SDU#XQ#VHUYHXU#GH#QRP '161
,QWURGXFWLRQ
/HV#TXDWUH#ILFKLHUV#VXLYDQWV VRQW#OHV#ILFKLHUV#GH FRQILJXUDWLRQ#XWLOLVpV#SDU#XQ VHUYHXU#GH#QRP#'161
)LFKLHU#GH#EDVH#GH#GRQQpHV
„ Stocke les enregistrements de ressource
z Conformes à la RFC 1034
SOA, A, NS, PTR, CNAME, MX, HINFO
z Spécifiques à Microsoft WINS, WINS-R
Le fichier de base de données contient des enregistrements de ressource relevant d'un domaine particulier. Différents types d'enregistrement de ressource sont définis au sein du DNS. La RFC 1034 définit les types d'enregistrement SOA, A, NS, PTR, CNAME, MX et HINFO. Microsoft a ajouté des types d'enregistrement qui lui sont spécifiques : WINS et WINS-R.
(QUHJLVWUHPHQW#62$
Dans tout fichier de base de données, le premier enregistrement doit être l'enregistrement de début d'autorité (SOA, Start Of Authority). Il définit les paramètres généraux pour la zone DNS. L'enregistrement ci-dessous est un exemple d'enregistrement SOA :
#ý,1ý62$ýQDPHVHUYHUìïPLFURVRIWïFRPïýJOHQQZRïPLFURVRIWïFRPïýõ ì âýVHULDOýQXPEHU
ìíåíí âýUHIUHVKý>êýKRXUV@
êçíí âýUHWU\ý>ìýKRXU@
çíéåíí âýH[SLUHý>æýGD\V@
åçéííýô âýWLPHýWRýOLYHý>ìýGD\@
Les règles suivantes s'appliquent à tous les enregistrements SOA :
„ Dans un fichier de base de données, le symbole « at » (@) signifie
« domaine racine de la zone ».
„ IN indique un enregistrement Internet.
„ Tout nom d'hôte ne se terminant pas par un point (. ) sera suivi du domaine racine.
„ Le symbole @ est remplacé par un point ( . ) dans l'adresse électronique de l'administrateur.
„ Si l'enregistrement s'étend sur plusieurs lignes, il doit être compris entre parenthèses ( ( ) ).
2EMHFWLI#GH#OD GLDSRVLWLYH
'pFULUH#OH#ILFKLHU#GH#EDVH#GH GRQQpHV#HW#H[SOLTXHU FKDTXH#W\SH G*HQUHJLVWUHPHQW#GH UHVVRXUFH1 ,QWURGXFWLRQ /H#ILFKLHU#GH#EDVH#GH GRQQpHV#FRQWLHQW#OHV HQUHJLVWUHPHQWV#GH UHVVRXUFH#UHODWLIV#DX GRPDLQH1
,O#H[LVWH#GH#QRPEUHX[#W\SHV G*HQUHJLVWUHPHQWV#GH UHVVRXUFH#'161#&HV HQUHJLVWUHPHQWV#VRQW#GpFULWV GDQV#GLYHUVHV#5)&1
3RXU#YRWUH#LQIRUPDWLRQ /HV#W\SHV#G*HQUHJLVWUHPHQW GH#EDVH#GH#GRQQpHV#VRQW GpILQLV#GDQV#OHV#5)ᄏ/
4368#HW#44;61#9RXV WURXYHUH]#XQH#FRSLH#GH#FHV 5)&#GDQV#OD#SDJH#:HE
&RXUVH#0DWHULDOV1
(QUHJLVWUHPHQW#16
Un enregistrement de serveur de nom (NS, Name Server) permet de répertorier un autre serveur de nom. Un fichier de base de données peut contenir plusieurs enregistrements de serveur de nom. La ligne suivante est un exemple
d'enregistrement de ce type :
#ý,1ý16ýQDPHVHUYHUëïPLFURVRIWïFRP
(QUHJLVWUHPHQW#$
Un enregistrement d'hôte (A) associe de manière statique un nom d'hôte à l'adresse IP correspondante. Les enregistrements d'hôte constituent l'essentiel du fichier de base de données. Ils permettent de répertorier tous les hôtes situés au sein de la zone. Les lignes suivantes sont des exemples d'enregistrements d'hôte :
UKLQR ,1ý$ýìèæïèèïëííïìéê ORFDOKRVW ,1ý$ýìëæïíïíïì
(QUHJLVWUHPHQW#&1$0(
Un enregistrement CNAME (Canonical Name) permet d'associer plusieurs noms d'hôte à une même adresse IP. L'utilisation de cet enregistrement est parfois appelé aliasing. Les lignes suivantes constituent un exemple d'enregistrement CNAME :
)LOH6HUYHUì &1$0(ýUKLQR ZZZ &1$0(ýUKLQR IWS &1$0(ýUKLQR
Les types d'enregistrement de base de données sont définis dans les RFC 1034, 1035 et 1183. Vous trouverez une copie de ces RFC dans la page Web Course Materials située sur le CD-ROM du cours.
5HPDUTXH
)LFKLHU#GH#UHFKHUFKH#LQYHUVH
„ Permet de répondre aux requêtes inverses
„ Pour les requêtes inverses portant sur le réseau IP 157.57.28.0, le fichier créé est nommé :
z Db.57.157.in-addr.arpa
„ Exemple d'entrée d'enregistrement de ressource :
51.200.55.157.in-addr.arpa. IN PTR mailsrv3.microsoft.com.
51.200.55.157.in-addr.arpa. IN PTR mailsrv3.microsoft.com.
Le fichier de recherche inverse (reverse lookup) permet au solveur de demander le nom d'hôte correspondant à l'adresse IP qu'il fournit. Ce fichier est nommé comme un fichier de zone, en fonction de la zone in-addr.arpa pour laquelle il prend en charge les recherches inverses. Par exemple, pour permettre des recherches inverses sur le réseau IP 157.57.28.0, un fichier de recherche inverse est créé et affecté du nom 57.157.in-addr.arpa. Ce fichier contient des
enregistrements de début d'autorité (SOA, Start Of Authority) et de serveur de nom (NS, Name Server), comme tous les autres fichiers de zone des bases de données DNS, ainsi que des enregistrements pointeurs.
Cette fonctionnalité de recherche DNS inverse est importante. En effet,
certaines applications offrent la possibilité de mettre en œuvre des dispositifs de sécurité sur la base du nom des hôtes se connectant au système. Par exemple, si un client tente de se relier à un volume NFS (Network File System, système de fichiers réseau) dans ce contexte de sécurité, le serveur NFS va contacter le serveur DNS et demander une recherche inverse pour obtenir le nom du client en fonction de son adresse IP. Si le nom d'hôte renvoyé par le serveur DNS ne figure pas dans la liste d'accès configurée pour le volume NFS, ou si le nom d'hôte n'est pas retrouvé par le serveur DNS, la requête NFS est rejetée.
(QUHJLVWUHPHQW#SRLQWHXU
Les enregistrements pointeurs (PTR), ou de référence, assurent le mappage adresse sur nom au sein d'une zone de recherche inverse donnée. Un enregistrement pointeur est constitué des numéros de l'adresse IP, écrits de manière inversée, suivis du nom de domaine in-addr.arpa. Par exemple, pour rechercher le nom d'hôte correspondant à l'adresse IP 157.55.200.51, le client doit formuler une requête de pointeur pour le nom 51.200.55.157.in-addr.arpa.
([HPSOH
èìïëííïèèïìèæïLQðDGGUïDUSDïý,1ý375ýPDLOVHUYHUìïPLFURVRIWïFRPï 2EMHFWLI#GH#OD
GLDSRVLWLYH
([SOLTXHU#OH#U{OH#GX#ILFKLHU GH#UHFKHUFKH#LQYHUVH1 ,QWURGXFWLRQ
3RXU#SRXYRLU#UpVRXGUH#OHV UHTXrWHV#LQYHUVHV/#OH VHUYHXU#GH#QRP#GRLW GLVSRVHU#G*XQ#ILFKLHU#GH UHFKHUFKH#LQYHUVH1
)LFKLHU#GH#FDFKH
„ Contient les noms et adresses des serveurs du domaine racine
„ Le fichier de cache pour Internet est fourni avec Windows NT 4.0
„ Exemple d'entrée :
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
Le fichier de cache contient des informations d'hôte nécessaires pour résoudre les noms relevant de domaines qui ne sont pas situés sous l'autorité du serveur.
Ce fichier comporte le nom et l'adresse des serveurs de noms racine. Le fichier par défaut fourni avec le serveur DNS de Microsoft Windows NT version 4.0 contient des enregistrements recouvrant la totalité des serveurs racine d'Internet.
Dans le cas d'installations non-connectées à Internet, le contenu du fichier de cache doit être modifié. En effet, il doit contenir les références aux serveurs détenant l'autorité sur le domaine racine du réseau privé.
Si vous souhaitez obtenir un fichier de cache Internet à jour, connectez-vous à ftp://rs.internic.net/domain/named.root.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#OH#U{OH#GX#ILFKLHU GH#FDFKH1
,QWURGXFWLRQ /H#ILFKLHU#&$&+(1'16 FRQWLHQW#OHV#HQUHJLVWUHPHQWV GHV#VHUYHXUV#GX#GRPDLQH UDFLQH1#/RUVTXH#OH#VHUYHXU GH#QRP#UHoRLW#XQH#UHTXrWH GpSDVVDQW#OHV#OLPLWHV#GH#VD ]RQH/#LO#HQWDPH#OD#SURFpGXUH GH#UpVROXWLRQ#HQ#VROOLFLWDQW FHV#VHUYHXUV#GH#GRPDLQH UDFLQH1
3RXU#YRWUH#LQIRUPDWLRQ 6L#YRXV#VRXKDLWH]#REWHQLU#XQ ILFKLHU#GH#FDFKH#,QWHUQHW#j MRXU/#FRQQHFWH]0YRXV#j IWS=22UV1LQWHUQLF1QHW 2GRPDLQ2QDPHG1URRW1
5HPDUTXH
)LFKLHU#G*DPRUoDJH
„ Pas défini par une RFC, aspect de la mise en œuvre BIND
„ Contrôle le comportement de démarrage des serveurs DNS compatibles BIND
„ Le serveur DNS de Microsoft peut être configuré afin d'utiliser ce fichier d'amorçage
„ Commandes du fichier d'amorçage :
z Directory
z Cache
z Primary
z Secondary
Le fichier d'amorçage n'est pas défini par une RFC, et son existence n'est pas requise pour que le serveur de nom soit compatible RFC. Ce fichier est un des aspects de l'implémentation BIND (Berkeley Internet Name Daemon) du DNS.
Le serveur DNS de Microsoft Windows NT version 4.0 peut être configuré afin d'utiliser un fichier d'amorçage, si l'administration doit être effectuée par modification de fichiers texte, et non par le biais du Gestionnaire DNS (ou Gestionnaire de service de nom de domaine).
Ce fichier contrôle le comportement du serveur DNS au démarrage. Les commandes doivent figurer en début de ligne, et ne doivent pas être précédées d'espace. Les commandes reconnues sont les suivantes : directory, cache, primary et secondary.
La syntaxe de ce fichier est décrite ci-dessous :
Commande Description
Directory Spécifie un répertoire où sont situés d'autres fichiers auxquels le fichier d'amorçage fait référence.
Cache Spécifie le fichier utilisé pour permettre au service DNS de contacter les serveurs de noms du domaine racine. Cette commande, et le fichier auquel elle fait référence, doivent être présents. Windows NT 4.0 est livré avec un fichier de cache utilisable sur Internet.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#FH#TX*HVW#OH#ILFKLHU G*DPRUoDJH#HW#j#TXHO PRPHQW#LO#HVW#XWLOLVp1 ,QWURGXFWLRQ /H#ILFKLHU#G*DPRUoDJH FRQVWLWXH#OH#ILFKLHU#GH FRQILJXUDWLRQ#GH#GpPDUUDJH GHV#VHUYHXUV#'16#GH#W\SH
%HUNHOH\#,QWHUQHW#1DPH 'DHPRQ#'161#,O#Q*HVW#SDV UHTXLV#SDU#OH#V\VWqPH#'16/
QL#SDU#OH#VHUYLFH#'16#GH 0LFURVRIW1#7RXWHIRLV/#LO#HVW PLV#j#OD#GLVSRVLWLRQ#GH#FHX[
TXL#YRXGUDLHQW#O*XWLOLVHU1
(suite)
Commande Description
Primary Spécifie un domaine pour lequel ce serveur de nom détient l'autorité, et un fichier de base de données contenant les enregistrements de ressource pour ce domaine (exemple, le fichier de zone). Le fichier d'amorçage peut comporter plusieurs enregistrements de commande Primary.
Secondary Spécifie un domaine pour lequel ce serveur de nom détient l'autorité, et la liste des adresses IP correspondant aux serveurs maîtres à partir desquels il sera possible de télécharger les informations de zone, au lieu de les lire dans un fichier. Elle définit également le nom du fichier local utilisé pour mettre en cache cette zone. Le fichier d'amorçage peut comporter plusieurs enregistrements de commande Secondary.
Le tableau suivant contient quelques exemples de commandes d'un fichier d'amorçage.
Syntaxe Exemple
directory [répertoire] directory c:\winnts\system32\dns cache.[nom_fichier] cache.cache
primary [domaine]
[nom_fichier]
primary microsoft.com microsoft.dns primary dev.microsoft.com dev.dns secondary [domaine]
[liste_hôtes]
[nom_fichier_local]
secondary test.microsoft.com 157.55.200.100 test.dns
3ODQLILFDWLRQ#GH#OD#PLVH#HQ#±XYUH#GX#'16
„ Petites entreprises
z Elles peuvent utiliser les serveurs DNS d’un fournisseur de services Internet pour répondre aux requêtes et stocker leur nom de domaine
„ Grandes entreprises
z Elles gèrent leurs propres serveurs DNS
„ Deux serveurs DNS recommandés
z Un serveur de nom principal
z Un serveur de nom secondaire
Dans le cas d'une petite organisation exploitant un réseau de taille réduite, la gestion directe d'un serveur DNS n'est pas toujours une solution appropriée. Il peut être plus simple, et plus efficace, de configurer les clients DNS pour qu'ils interrogent un serveur de nom DNS pris en charge par un fournisseur de services Internet (ISP, Internet Service Provider). Pour la plupart, les ISP proposent un service de maintenance des informations de domaine moyennant une contribution financière. Les organisations qui souhaitent contrôler leur domaine, ou éviter les coûts liés aux prestations d'un ISP, doivent gérer leurs propres serveurs DNS.
Quelle que soit sa taille, une organisation voulant se connecter à Internet doit prendre contact avec l'InterNIC. Cet organisme doit être informé du nom de domaine du demandeur, et des adresses IP d'au moins deux serveurs DNS qui desserviront ce domaine. Néanmoins, toute organisation peut mettre en place ses propres serveurs DNS, de manière interne, sans relation avec Internet.
Pour des questions de fiabilité et de redondance des données, Microsoft recommande de configurer au moins deux serveurs DNS par domaine — un serveur de nom principal, et un serveur de nom secondaire. Le serveur de nom principal tient à jour la base de données, qui est dupliquée sur le serveur de nom secondaire. Cette duplication permet de répondre aux requêtes de nom même si l'un des serveurs de noms n'est plus opérationnel. Il est possible de configurer le déclenchement de la duplication en fonction de la fréquence à laquelle les noms changent au sein du domaine. La duplication doit être effectuée à un rythme suffisant pour que les deux serveurs aient connaissance des modifications.
Cependant, une fréquence de duplication excessive peut surcharger sans raison le réseau et les serveurs de noms.
2EMHFWLI#GH#OD GLDSRVLWLYH
3UpVHQWHU#EULqYHPHQW#DX[
VWDJLDLUHV#GH#TXHOOH#IDoRQ#LOV SHXYHQW#FRQILJXUHU#OH#'16 GDQV#OHXU#VLWH1
,QWURGXFWLRQ /D#FRQILJXUDWLRQ#GH#YRV VHUYHXUV#'16#GpSHQG#GH IDFWHXUV#WHOV#TXH#OD#WDLOOH#HW OD#UpSDUWLWLRQ#JpRJUDSKLTXH GH#YRWUH#HQWUHSULVH/#RX#VHV EHVRLQV#HQ#WHUPH#GH WROpUDQFH#DX[#SDQQHV1
,QVFULSWLRQ#DXSUqV#GX#GRPDLQH#SDUHQW
microsoft.com compaq.com purdue.edu
Etudiant Seattle
Domaine de second niveau
Contacter l’administrateur de domaine Contacter InterNIC
Une fois que vos serveurs DNS sont installés et configurés, vous devez les enregistrer (ou les inscrire) auprès du serveur DNS qui leur est immédiatement supérieur au sein de la structure de dénomination hiérarchisée du DNS. Le système parent doit connaître les noms et adresses de vos serveurs de noms, et peut demander d'autres informations, telles que la date à laquelle le domaine sera disponible et les noms et adresses des personnes pouvant être contactées à des fins d'administration.
Si vous inscrivez vos serveurs de noms auprès d'un serveur parent situé en dessous du second niveau de domaine, prenez contact avec l'administrateur de ce système pour déterminer les informations que vous devez fournir.
Si vous procédez à une inscription au niveau du sous-domaine, ou à un niveau supérieur, connectez-vous aux services d'inscription en ligne
d'InterNIC, à l'adresse http://internic.net. Si vous avez des questions, appelez leur service d'aide à l'inscription au (00-1-703) 742-477.
2EMHFWLI#GH#OD GLDSRVLWLYH
([SOLTXHU#FRPPHQW#LQVFULUH XQ#VHUYHXU#DXSUqV#GX GRPDLQH#SDUHQW1 ,QWURGXFWLRQ
3RXU#TXH#YRWUH#VHUYHXU#'16 IRQFWLRQQH#FRUUHFWHPHQW/
YRXV#GHYH]#O*HQUHJLVWUHU/#RX O*LQVFULUH/#DX#QLYHDX#GH GRPDLQH#TXL#OXL#HVW LPPpGLDWHPHQW#VXSpULHXU1
5HPDUTXH
$WHOLHU#49#=#3ODQLILFDWLRQ#GH#OD#PLVH#HQ#±XYUH#GX#'16
2EMHFWLI#GH#OD GLDSRVLWLYH ,QGLTXHU#DX[#VWDJLDLUHV O*DWHOLHU#DSSURSULp#HW#HQ H[SOLTXHU#OHV#REMHFWLIV1 ,QWURGXFWLRQ
'DQV#FHW#DWHOLHU/#YRXV#DOOH]
WUDYDLOOHU#VXU#WURLV#VFpQDULRV GH#PLVH#HQ#°XYUH#GX#'161
&RQVHLOV#SpGDJRJLTXHV 3DVVH]#HQ#UHYXH#OHV LQIRUPDWLRQV#FRQWHQXHV GDQV#OD#VHFWLRQ
©#3UpSDUDWLRQ#ª#GH#O*DWHOLHU1 )DLWHV#XQ#ELODQ#GH#O*DWHOLHU1 0HQH]#XQH#GLVFXVVLRQ RXYHUWH#DYHF#OHV#VWDJLDLUHV HW#JXLGH]0OHV#WRXW#DX#ORQJ GHV#WURLV#VFpQDULRV#GH#FHW DWHOLHU1
'HPDQGH]#DX[#VWDJLDLUHV V*LOV#RQW#UHQFRQWUp#GHV SUREOqPHV1
'HPDQGH]#DX[#VWDJLDLUHV V*LOV#RQW#GHV#TXHVWLRQV#j SRVHU1
3RXU#YRWUH#LQIRUPDWLRQ 9RXV#WURXYHUH]#OD#VROXWLRQ GHV#H[HUFLFHV#G*DWHOLHU#GDQV OD#SDJH#:HE#&RXUVH 0DWHULDOV1
&RQWU{OH#GHV#DFTXLV
„ Système de noms de domaine (DNS)
„ Résolution des noms
„ Configuration des fichiers DNS
„ Planification de la mise en œuvre du DNS
1. Citez les trois composants du système de nom de domaine.
L'espace de noms de domaine, les serveurs de noms et les solveurs (resolvers).
2. En quoi les serveurs de noms principaux, secondaires et maîtres sont-ils différents ?
Un serveur de nom principal dispose d'informations de zone qui sont enregistrées dans des fichiers de zone tenus à jour au niveau local. Un serveur de nom secondaire doit télécharger ses informations de zone.
Un serveur de nom maître joue le rôle de source de téléchargement vis- à-vis d'un serveur de nom secondaire. Le serveur de nom maître peut être un serveur de nom principal ou secondaire.
3. Quelles sont les trois raisons justifiant l'existence d'un serveur de nom secondaire ?
Il assure une fonction de serveur de nom redondant (il est fortement recommandé de mettre en place au moins un serveur de nom redondant pour chaque zone). (2) Si des clients sont situés dans des emplacements distants, un serveur de nom secondaire leur évite de recourir à des communications sur des liaisons lentes. (3) Un serveur de nom secondaire réduit la charge de travail du serveur de nom principal.
2EMHFWLI#GH#OD GLDSRVLWLYH
5HYHQLU#VXU#OHV#REMHFWLIV#GX PRGXOH#HQ#UpYLVDQW#GHV VXMHWV#LPSRUWDQWV1 ,QWURGXFWLRQ (Q#UpVXPp/#QRXV#DYRQV pWXGLp#DX#FRXUV#GH#FH PRGXOH111
3UHQH]#TXHOTXHV#PLQXWHV SRXU#UpSRQGUH#DX[
TXHVWLRQV#FRQWHQXHV#GDQV YRWUH#PDQXHO1#(QVXLWH/#QRXV OHV#FRPPHQWHURQV HQVHPEOH1
&RQVHLOV#SpGDJRJLTXHV 8WLOLVH]#OHV#TXHVWLRQV#GH FHWWH#VHFWLRQ#SRXU#UpYLVHU OHV#VXMHWV#GX#PRGXOH1
$YDQW#GH#SRXUVXLYUH/
GHPDQGH]#DX[#VWDJLDLUHV V*LOV#RQW#G*DXWUHV#TXHVWLRQV#j SRVHU1
4. Décrivez la différence existant entre un domaine et une zone.
Un domaine est une « branche » de l'espace de noms DNS. Une zone est une portion de domaine concrétisée par un fichier distinct contenant des enregistrements de ressource.
5. Décrivez la différence existant entre une requête récursive et une requête itérative.
Dans le cas d'une requête récursive, le client demande au serveur DNS de lui renvoyer soit l'information dont il a besoin, soit un message d'erreur indiquant que cette information n'a pas pu être trouvée. Si la requête est itérative, le serveur DNS renvoie la meilleure réponse possible, généralement une référence à un autre serveur de nom susceptible de contribuer à la résolution de la requête.
6. Répertoriez les fichiers requis pour mettre en œuvre le DNS sous Windows NT.
Fichier de base de données, fichier de cache et fichier de recherche inverse.
7. Décrivez la fonction du fichier d'amorçage.
Le fichier d'amorçage est utilisé dans l'implémentation BIND pour démarrer et configurer le serveur DNS.
