RFC: 1034
Statut : Standard
Retour à l'index français

2. INTRODUCTION

Cette RFC expose les styles admis pour les noms de domaines, leur utilisation dans le cadre de la messagerie par Internet et pour la recherche d'hôtes, et décrit les protocoles et serveurs utilisés pour les services réseaux liés aux noms de domaines.

2.1. Historique des noms de domaines

La motivation essentielle et impérieuse conduisant à la mise en œuvre du système de domaines a été la croissance exponentielle d'Internet :

• Au début, la transcription de noms d'hôtes en adresses Internet s'appuyait sur une table de correspondance maintenue par le Network Information Center (NIC) sous forme d'un unique fichier (HOSTS.TXT) lequel était transmis par FTP sur tous les hôtes [RFC-952, RFC-953]. La bande passante consommée par la distribution d'une remise à jour de cette base par cette méthode est proportionnelle au carré du nombre d'hôtes sur le réseau, et même lorsque plusieurs niveaux de retransmissions FTP étaient utilisés, le trafic sortant du serveur NIC restait considérable. La croissance explosive du nombre d'hôtes a fait rapidement exploser du même coup ce mécanisme.
  
  
• La population internaute changeait dans le même temps de nature. Les hôtes en temps partagé (mainframes) constituant l'ARPANET originel ont été remplacés par une architecture distribuée de stations connectées sur des réseaux et sous-réseaux locaux. Les organismes locaux ont commencé à administrer leurs propres noms et adresses, mais devaient attendre que le NIC reporte les changements dans le fichier HOSTS.TXT pour que ceux-ci soient visibles de l'ensemble de la communauté Internet. Les organisations souhaitaient néanmoins pouvoir conserver une certaine autonomie quant à la gestion de leur infrastructure locale.
  
  
• Les applications exploitant Internet sont devenues de plus en plus sophistiquées et ont créé le besoin d'un traitement plus généralisé des noms de domaines.

Le résultat de tout ceci ont fait émerger certaines idées sur l'espace des noms et sa gestion[IEN-116, RFC-799, RFC-819, RFC-830]. Les propositions ont été diverses, mais l'une des tendances émergentes a été celle d'un espace de noms hiérarchisé, et dont le principe hiérarchique s'appuierait autant que possible sur la structure des organismes eux-mêmes, et où les noms utiliseraient le caractère "." pour marquer la frontière entre deux niveaux hiérarchiques. Un design mettant en œuvre une base de données distribuée et des ressources généralisées a été décrit dans les [RFC-882, RFC-883]. Sur la base de nombreuses expérimentations, le système théorique des domaines a évolué vers celui qui est présenté dans ce mémo.

Les termes "domaine" ou "nom de domaine" sont utilisés dans de nombreux contextes tournant autour du DNS décrit ici. Très souvent, le terme "nom de domaine" est souvent utilisé pour décrire un nom écrit sous forme de chaîne de caractères reliées par des points, sans relation expresse au DNS. Ceci est particulièrement vrai pour ce qui concerne les adresses de messagerie [Quarterman 86].

2.2. Objectifs de la conception du DNS

Les objectifs dans lesquels a été conçu le DNS ont influencé sa structure. Ces objectifs sont les suivants :

• Le but premier est la création d'un espace de noms conséquent utilisables pour référencer des ressources. Pour éviter tout problème de transcodage ou d'encodage, les noms peuvent ne mentionner ou inclure aucun des identificateurs réseau, adresses, chemins, ou information similaire communément utilisés pour l'implémentation technique.
  
  
• La taille énorme de la base de données et sa fréquence de mise à jour suggère une maintenance distribuée, avec cache local pour une performance accrue. Toute approche qui tentera d'obtenir une copie intégrale de la base de donnée sera de plus en plus coûteuse et difficile à traiter, et de ce fait devra être écartée. Les mêmes principes courent pour la constitution de l'espace des noms, et en particulier les mécanismes pour créer et supprimer des noms ; ceux-ci devront être également distribués.
  
  
• Lorsque l'on doit composer entre le coût technique d'acquisition d'une donnée, la fréquence des mises à jour, et la validité des caches, c'est toujours la source première de données qui contrôle les priorités à donner.
  
  
• Le coût important inhérent à l'implémentation d'un tel service suppose qu'il a une utilité générale, qui n'est pas restreinte à une application particulière. Les noms ainsi constitués devront pouvoir servir à identifier des hôtes, récupérer des courriers dans des boîtes aux lettres, et toute autre information non encore identifiée. Toute donnée associée à un nom sera typée, et les requêtes sur ce nom seront limitées à ce seul type.
  
  
• Nous souhaitions que l'espace de noms puisse être utilisé sur des réseaux de nature différente, et pour cela, nous avons conçu ce système de telle sorte qu'il puisse s'appuyer sur plusieurs familles de protocoles. Par exemple, les adresses d'hôtes diffèrent dans leur forme suivant la nature des systèmes, bien que tous les protocoles utilisent une notion similaire. Le DNS attribue une classe aux données de la même façon qu'il attribue un type, ce qui nous permettra de pouvoir parallèlement utiliser plusieurs formats distincts pour des données de type adresse.
  
  
• Nous souhaitions de plus que les transactions avec les serveurs de nom soient indépendantes du système de communication utilisé. Certains systèmes utiliseront le format du datagramme pour les requêtes et les réponses, et n'établiront de circuit commuté virtuel que lorsque la transaction nécessite une certaine sécurité (ex., la mise à jour des bases de données, des transactions de longue durée); d'autres systèmes demanderont à n'utiliser que des circuits commutés virtuels.
  
  
• Le système doit être compatible avec une grande variété de plates-formes. Devront pouvoir utiliser ce système tant des micro-ordinateurs que des "mainframes", les méthodes d'utilisation pouvant être différentes.

2.3. Présupposés concernant l'utilisation

L'organisation du système de domaines découle de certains présupposés quant aux besoins et aux schémas d'exploitation de la communauté utilisatrice, et est conçue de sorte à éviter un grand nombre de problèmes classiques des grandes bases de données généralistes.

Les suppositions faites sont :

• La taille totale de la base de données sera initialement proportionnelle au nombre d'hôtes utilisant le système, mais pourra rapidement devenir proportionnelle au nombre d'utilisateurs utilisant ces machines dans la mesure où des informations telles que les boîtes aux lettres y seront intégrées.
  
  
• La fréquence de modification de la plupart des données de cette base sera assez basse (ex., les changements de boîtes aux lettres, les adresses d'hôtes), mais le système devra pouvoir traiter des sous ensembles de données nécessitant une période de remise à jour plus élevée (de l'ordre de quelques secondes à quelques minutes).
  
  
• Les limites administratives définies pour répartir la responsabilité de gestion de la base de données seront généralement associées à celles d'organisations possédant un ou plusieurs hôtes. Chaque organisation ayant la responsabilité d'un ensemble de domaines particulier devra mettre en œuvre plusieurs serveurs de domaines redondants, soit sur l'hôte même de l'organisme, ou sur d'autres hôtes dont l'organisme s'occupe ou exploite.
  
  
• Les clients du système de domaines devront pouvoir choisir le serveur qu'ils décident d'utiliser armi un ensemble de serveurs nommés et considérés comme sûrs avant d'accepter de s'appuyer sur un serveur hors de cet ensemble.
  
  
• L'accès à l'information est plus important que la garantie de remise à jour instantanée et d'une consistance permanente de la base. De ce fait le processus de remise à jour utilise un principe de diffusion de l'information de proche en proche plutôt qu'un mécanisme dont le but serait de remettre à jour simultanément toutes les copies d'une information. Lorsque les mises à jour sont indisponibles suite à une défaillance réseau ou de l'hôte, il sera d'usage de s'en remettre à l'information "ancienne", pendant que les efforts sont faits pour remettre à jour la base. Le modèle général précise que les copies d'informations sont faites tenant compte d'un certain délai de rafraîchissement. Le distributeur mentionne le délai et le récepteur des données est responsable de l'opération de remise à jour. Dans certains cas très particuliers, des délais très courts peuvent être spécifiées, ou encore la copie peut être interdite.
  
  
• Dans tout système possédant une base de données répartie, un serveur de nom pourra recevoir des requêtes auxquelles seuls d'autres serveurs peuvent répondre. Les deux approches principales pour contourner le problème sont soit la méthode "récursive", par laquelle le serveur reporte la requête vers un autre serveur pour le compte du client, soit la méthode "itérative", par laquelle le client est enjoint de requérir sur un autre serveur. Les deux approches ont leurs avantages et inconvénients, mais la méthode itérative reste toutefois préférée dans le cas où le mode de requête est le datagramme. Le système de domaines nécessitera l'implémentation de l'approche itérative, mais fournira la méthode récursive en option.

Le système de domaines suppose que toutes les données proviennent de fichiers maîtres éparpillés dans les hôtes parties prenantes de ce système. Ces fichiers maîtres de données sont maintenus par l'administrateur local. Les fichiers maîtres sont des fichiers texte lus par un serveur de domaines local, et qui deviennent de ce fait accessibles à tous les utilisateurs du système de domaines par l'intermédiaire de la chaîne de serveurs. Le programme de l'utilisateur accède à ces différents serveurs par l'intermédiaire d'une fonction logicielle de "résolution d'adresse".

Le format standardisé des fichiers maîtres leur permet d'être échangés entre hôtes différents (via FTP, mail, ou tout autre mécanisme); cette opportunité est utile lorsque par exemple, un organisme désire s'attribuer un domaine, mais ne souhaite pas supporter l'administration d'un serveur de domaines. L'organisme pourra maintenir localement le fichier maître avec un simple éditeur de texte, puis le transférer sur un hôte déporté sur lequel sont exécutés les serveurs de domaines, puis voir avec l'administrateur système pour savoir quel serveur de domaines ira lire les fichiers ainsi chargés.

Chaque hôte gérant un serveur de noms de domaines et une fonction de résolution d'adresse est configuré par un administrateur local [RFC-1033]. Pour un serveur de noms, cette configuration définit entre autres l'identité des fichiers maîtres locaux ainsi que des instructions pour savoir quels fichiers maîtres externes doivent être chargés et à partir de quels serveurs distants. Le serveur de noms utilise les fichiers principaux ou ses copies pour charger ces zones. Pour les programmes de résolution d'adresse, les données de configuration identifient les serveurs de noms qui seront les sources primaires d'information.

Le système de domaines définit des procédures pour accéder aux données oupour faire référence à d'autres serveurs de noms. Le système de domaines définit aussi des procédures pour stocker les données récupérées et pour rafraîchir périodiquement les données selon les voeux de l'administrateur système.

L'administrateur renseigne :

• La définition des limites de zones.
• Les fichiers principaux de données.
• La remise à jour des fichiers de données.
• Les spécifications de cette remise à jour.

Le système de domaines fournit :

• Des formats standard pour les ressources.
• Des méthodes standard d'accès à la base de données.
• Des méthodes standard à l'attention des serveurs de noms pour rafraîchir les données à partir de serveurs de noms distants.

2.4. Eléments du DNS

Le DNS a trois composants principaux :

• L'ESPACE DE NOMS DE DOMAINES et les ENREGISTREMENTS DE RESSOURCES, qui sont les spécifications d'un espace de noms structuré en arbre et des données associées à ces noms. Conceptuellement, chaque noeud et chaque feuille de l'arbre de l'espace de noms de domaines contient un ensemble d'informations ; les requêtes sont des tentatives pour extraire un type spécifique d'information dans cet ensemble. Une requête cite le nom du domaine d'intérêt et décrit le type d'information désiré quant aux ressources concernées. Par exemple, Internet utilise certains de ses noms de domaines pour identifier des hôtes ; une requête pour des adresses de ressources renverront l'adresse Internet de l'hôte.
  
  
• Les SERVEURS DE NOM sont des programmes serveurs qui détiennent l'information sur la structure arborescente et les informations de domaines. Un serveur de nom peut stocker momentanément en "cache" des informations de structure ou de ressources sur toute partie de l'espace de noms de domaines, mais en général, un serveur de nom n'accueillera que les informations relatives à un sous ensemble de l'espace, et des pointeurs vers d'autres serveurs de noms qui, par leur association, se répartissent la définition de l'ensemble de l'espace. Les serveurs de nom connaissent la partie de l'arbre des domaines pour laquelle il détiennent une information complète ; un serveur de noms est dit être AUTORISE pour cette partie de l'espace de noms. L'information "autorisée" est organisée en unités appelées ZONES, ces zones pouvant être automatiquement distribuées aux serveurs de noms faisant partie de la "sphère de redondance" pour la zone de données considérées.
  
  
• Les processus de résolution, ou RESOLVEURS sont des programmes qui extraient l'information des serveurs de noms en réponse aux requêtes clientes. Les résolveurs doivent pouvoir accéder à au moins un serveur de noms et utiliser l'information qu'ils y trouvent pour donner directement une réponse au client, ou utiliser les références à d'autres serveurs de nom contenues dans le serveur "visible" pour les contacter à leur tour et continuer la résolution. un résolveur sera habituellement une routine système qui peut être appelée directement par un programme utilisateur ; en général aucun protocole n'est nécessaire entre le résolveur et l'application utilisatrice.

Ces trois composants correspondent en gros aux trois "couches" ou points de vue sur le système de noms de domaines :

• Du point de vue de l'utilisateur, le système de noms de domaines est accessible via une procédure simple ou un appel système à un résolveur local. L'espace de domaines consiste en un arbre unique dont toutes les parties sont accessibles à l'utilisateur.
  
  
• Du point de vue du résolveur, le système de domaines est composé d'un nombre non connu de serveurs de noms. Chaque serveur de noms héberge une ou plusieurs pièces de l'ensemble des données constituant l'arbre des domaines, le résolveur considérant chacune de ces bases de données comme essentiellement statique.
  
  
• Du point de vue d'un serveur de noms, le système de domaines consiste en un regroupement d'ensembles de données locales séparées appelées zones. Le serveur de noms dispose d'une copie locale de certaines zones. Le serveur de noms doit rafraîchir périodiquement ses zones à partir de fichiers principaux locaux ou situés dans des serveurs de noms distants. Les serveurs de noms doivent traiter les requêtes arrivant des résolveurs de façon concurrente.

Pour une meilleure performance, les implémentations pourront coupler ces fonctions. Par exemple, un résolveur exécuté sur la même machine qu'un serveur de noms pourrait partager la base de données accueillant les zones gérées par le serveur de nom et le cache géré, lui, par le résolveur.