Module 12 : DNS (Domain Name System)

Module 12 : DNS (Domain Name System)

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 59: #3UpVHQWDWLRQ#JpQpUDOH 'RQQHU#XQ#DSHUoX#GHV VXMHWV#HW#GHV#REMHFWLIV#GH#FH PRGXOH1 &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 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 sere à 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.

59;# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, 6\VWqPH#GH#QRP#GH#GRPDLQH#+'16, 'pilqlu#oh#v\vwqph#gh#qrp GH#GRPDLQH#+'16,1 /H#'16#+'RPDLQ#1DPH 6\VWHP,#HVW#XQH#EDVH#GH GRQQpHV#GLVWULEXpH#TXL V*DSSXLH#VXU#XQH#VWUXFWXUH GH#QRPV#KLpUDUFKLVpH1 Vert Bleu Rouge Jaune Orange Violet FTP Orange SRI-NIC Hosts.txt 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 3RXU#YRWUH#LQIRUPDWLRQ /H#'16#HVW#GpFULW#GDQV#OHV 5)&#4367#HW#43681#9RXV WURXYHUH]#XQH#FRSLH#GH#FHV 5)&#GDQV#OD#SDJH#:HE &RXUVH#0DWHULDOV1 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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 59< 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é). 5HPDUTXH Le système de nom de domaine (DNS) est décrit dans les RFC 1034 et 1035. Vous trouvere une copie de ces RFC dans la page Web Course Materials, enregistrée sur le CD-ROM du cours.

5:3# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, )RQFWLRQQHPHQW#GX#'16 'pfuluh#o*dufklwhfwxuh#gx '161 '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 Sockets Application Transport Internet Internet Réseau Réseau Solveur DNS Application Transport Internet Internet Réseau Réseau Serveur de nom &RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#H[SOLTXHU#OHV U{OHV#MRXpV#SDU#OHV#VROYHXUV HW#OHV#VHUYHXUV#GH#QRPV1 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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5:4 (VSDFH#GH#QRPV#GH#GRPDLQH 'pfuluh#od#vwuxfwxuh#gx V\VWqPH#GH#QRP#GH GRPDLQH1 /*HVSDFH#GH#QRPV#GH GRPDLQH#UHJURXSH#OHV#QRPV GH#PDQLqUH#KLpUDUFKLVpH/#DX VHLQ#G*XQH#VWUXFWXUH VHPEODEOH#j#XQ#DUEUH LQYHUVp1 Domaine de niveau racine Pays Domaine de niveau supérieur Nouvelle-Zélande (NZ) COM EDU ORG Domaine de second niveau Seattle microsoft compaq purdue Etudiant &RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#GpFULUH#OHV GLIIpUHQWV#QLYHDX[#GH GRPDLQH1 '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.

5:5# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, '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 sousdomaines 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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5:6 =RQHV#G*DXWRULWp 'pilqlu#oh#frqfhsw#ghv ]RQHV/#HW#FRPPHQW#HOOHV VRQW#XWLOLVpHV1 Zone 1 com 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 Microsoft CORP Serveurs de nom Zone 2 Serveur de nom Zone 3 MKTG R&D Serveur de nom Une one 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 one. Il répond aux requêtes émanant des clients et se rapportant à ces noms. La one d'autorité d'un serveur de nom recouvre au moins un domaine. Celui-ci est appelé domaine racine de la one. La one d'autorité peut également inclure des sous-domaines du domaine racine de cette one. Cependant, une one 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 one unique. Une partie du domaine relève d'un fichier de one distinct, pour mktg.microsoft.com et R&D.microsoft.com. La répartition d'un domaine sur plusieurs fichiers de one 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 one. Chaque one est rattachée à un nœud de domaine spécifique, appelé domaine racine de la one.

5:7# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, 5{OHV#GHV#VHUYHXUV#GH#QRPV ([SOLTXHU#OHV#GLIIpUHQWV#U{OHV TXH#SHXW#MRXHU#XQ#VHUYHXU GH#QRP1 /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 Serveurs de nom principaux Informations de one dans des fichiers gérés localement Serveurs de nom secondaires Informations de one téléchargées à partir d un serveur de noms maître Serveurs de nom maîtres Source d informations pour un serveur secondaire (peut être un serveur principal ou secondaire) Serveurs cache Ne conservent aucune information de one 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 one. 6HUYHXUV#GH#QRPV#SULQFLSDX[ Le serveur de nom principal obtient les données de one à partir de fichiers locaux. Les modifications apportées à une one, 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 one via le réseau, à partir d'un autre serveur de nom qui détient l'autorité pour la one considérée. L'obtention des informations de one via le réseau est appelée transfert de one. L'existence des serveurs de noms secondaires est justifiée par trois raisons : Redondance : dans chaque one, 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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5:8 Dans la mesure où les informations relatives à chaque one sont stockées dans un fichier distinct, cette distinction principal/secondaire est définie au niveau de la one. En d'autres termes, un serveur de nom spécifique peut jouer le rôle de serveur de nom principal pour certaines ones, et de serveur de nom secondaire pour d'autres ones. 6HUYHXUV#GH#QRPV#PDvWUHV Lorsque vous définisse une one secondaire sur un serveur de nom, vous deve désigner un autre serveur de nom à partir duquel le serveur secondaire pourra obtenir ses informations de one. 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 one. Un serveur de nom maître peut être soit un serveur de nom secondaire, soit un serveur de nom principal pour la one considérée. Quand un serveur de nom secondaire démarre, il contacte son serveur de nom maître et entame un transfert de one 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 one 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, garde à 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 one. Ceci peut se révéler important si vous deve exploiter une liaison lente entre des sites.

5:9# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, 5pVROXWLRQ#GHV#QRPV ([SOLTXHU#OH#IRQFWLRQQHPHQW GHV#UHTXrWHV#UpFXUVLYHV#HW GHV#UHTXrWHV#LWpUDWLYHV1 Serveur de nom local Requêtes itératives 2 3 Serveur de nom racine 8Q#FOLHQW#+VROYHXU,#SHXW DGUHVVHU#WURLV#W\SHV#GH UHTXrWHV#j#XQ#VHUYHXU#'16#= UpFXUVLYHV/#LWpUDWLYHV#HW LQYHUVHV1 1 Requête récursive 8 4 6 5 7 Serveur de nom gov Client DNS Serveur de nom whitehouse.gov &RQVHLO#SpGDJRJLTXH 8WLOLVH]#OD#UHSUpVHQWDWLRQ JUDSKLTXH#SRXU#H[SOLTXHU#OH FRQFHSW#GH#UHTXrWH UpFXUVLYH#HW#GH#UHTXrWH LWpUDWLYH1 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 ones, 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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5:: 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.

5:;# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, 5HTXrWHV#LQYHUVHV ([SOLTXHU#OH#IRQFWLRQQHPHQW G*XQH#UHTXrWH#LQYHUVH1 /HV#UHTXrWHV#LQYHUVHV SHUPHWWHQW#j#O*DSSOLFDWLRQ#GH UHWURXYHU#OH#QRP#G*XQ#K{WH GRQW#HOOH#FRQQDvW#GpMj O*DGUHVVH#,31 Domaine spécial pour les requêtes inverses in-addr.arpa Les adresses IP sont converties par inversion pour générer la requête DNS inverse 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 inaddr.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.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5:< 0LVH#HQ#FDFKH#HW#77/ ([SOLTXHU#FRPPHQW#XQ VHUYHXU#GH#QRP#PHW#HQ FDFKH#OHV#UHTXrWHV UpVROXHV/#HW#WLHQW#FH#FDFKH#j MRXU1 #PHVXUH#TXH#OHV#UHTXrWHV VRQW#UpVROXHV#SDU#OH#VHUYHXU GH#QRP/#OHV#LQIRUPDWLRQV VRQW#SODFpHV#GDQV#XQ#FDFKH/ SRXU#UpSRQGUH#j#GH#IXWXUHV UHTXrWHV1 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 one 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.

5;3# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, &RQILJXUDWLRQ#GHV#ILFKLHUV#'16 'pfuluh#ohv#ilfklhuv#xwlolvpv SDU#XQ#VHUYHXU#GH#QRP '161 /HV#TXDWUH#ILFKLHUV#VXLYDQWV VRQW#OHV#ILFKLHUV#GH FRQILJXUDWLRQ#XWLOLVpV#SDU#XQ VHUYHXU#GH#QRP#'161 Fichier de base de données (Zone.dns) Contient les enregistrements de ressource pour la one 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) Mappe des adresses IP sur des noms d hôte Fichier de cache (Cache.dns) Noms et adresses des serveurs de noms du domaine racine Fichier d'amorçage Utilisé pour le mode d initialisation manuelle Les fichiers décrits ci-dessous sont associés à la grande majorité des serveurs DNS : Nom Fichier de base de données (Zone.dns) Fichier de recherche inverse (Z.Y.W.X.in-addr.arpa) Fichier de cache (Cache.dns) Fichier d'amorçage Description Le fichier de base de données contient les enregistrements de ressource pour un domaine. Si votre one 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 pouve 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 one qu'il représente. C'est ce fichier qui sera dupliqué entre les serveurs maîtres et les serveurs secondaires. 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. 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. 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é.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5;4 )LFKLHU#GH#EDVH#GH#GRQQpHV 'pfuluh#oh#ilfklhu#gh#edvh#gh GRQQpHV#HW#H[SOLTXHU FKDTXH#W\SH G*HQUHJLVWUHPHQW#GH UHVVRXUFH1 /H#ILFKLHU#GH#EDVH#GH GRQQpHV#FRQWLHQW#OHV HQUHJLVWUHPHQWV#GH UHVVRXUFH#UHODWLIV#DX GRPDLQH1 Stocke les enregistrements de ressource Conformes à la RFC 1034 SOA, A, NS, PTR, CNAME, MX, HINFO Spécifiques à Microsoft WINS, WINS-R,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)&#4367/ 4368#HW#44;61#9RXV WURXYHUH]#XQH#FRSLH#GH#FHV 5)&#GDQV#OD#SDJH#:HE &RXUVH#0DWHULDOV1 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 one 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 one». 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 ( ()).

5;5# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, (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 one. 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 5HPDUTXH Les types d'enregistrement de base de données sont définis dans les RFC 1034, 1035 et 1183. Vous trouvere une copie de ces RFC dans la page Web Course Materials située sur le CD-ROM du cours.

0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP,# # 5;6 )LFKLHU#GH#UHFKHUFKH#LQYHUVH ([SOLTXHU#OH#U{OH#GX#ILFKLHU GH#UHFKHUFKH#LQYHUVH1 3RXU#SRXYRLU#UpVRXGUH#OHV UHTXrWHV#LQYHUVHV/#OH VHUYHXU#GH#QRP#GRLW GLVSRVHU#G*XQ#ILFKLHU#GH UHFKHUFKH#LQYHUVH1 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é : Db.57.157.in-addr.arpa Exemple d'entrée d'enregistrement de ressource : 51.200.55.157.in-addr.arpa. IN IN PTR 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 one, en fonction de la one 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 one 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 one 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ï

5;7# # 0RGXOH#45#=#'16#+'RPDLQ#1DPH#6\VWHP, )LFKLHU#GH#FDFKH ([SOLTXHU#OH#U{OH#GX#ILFKLHU GH#FDFKH1 /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 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 3600000 IN IN NS NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 3600000 A 198.41.0.4 198.41.0.4 3RXU#YRWUH#LQIRUPDWLRQ 6L#YRXV#VRXKDLWH]#REWHQLU#XQ ILFKLHU#GH#FDFKH#,QWHUQHW#j MRXU/#FRQQHFWH]0YRXV#j IWS=22UV1LQWHUQLF1QHW 2GRPDLQ2QDPHG1URRW1 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é. 5HPDUTXH Si vous souhaite obtenir un fichier de cache Internet à jour, connecte-vous à ftp://rs.internic.net/domain/named.root.