Aller au contenu principal

2. Introduction

Ce RFC introduit les noms de style domaine (Domain Style Names), leur utilisation pour le courrier Internet et le support d'adresses d'hôtes, ainsi que les protocoles et serveurs utilisés pour implémenter les fonctionnalités de noms de domaine.

2.1. L'histoire des noms de domaine (The history of domain names)​

L'impulsion pour le développement du système de domaine était la croissance d'Internet :

  • Les correspondances nom d'hôte vers adresse (Host name to address mappings) étaient maintenues par le Network Information Center (NIC) dans un seul fichier (HOSTS.TXT) qui était téléchargé par FTP par tous les hôtes [RFC-952, RFC-953]. La bande passante réseau totale consommée pour distribuer une nouvelle version selon ce schéma est proportionnelle au carré du nombre d'hôtes sur le réseau, et même lorsque plusieurs niveaux de FTP sont utilisés, la charge FTP sortante sur l'hôte NIC est considérable. La croissance explosive du nombre d'hôtes n'augurait rien de bon pour l'avenir.

  • La population du réseau (The network population) changeait également de caractère. Les hôtes à temps partagé qui composaient l'ARPANET d'origine étaient remplacés par des réseaux locaux de stations de travail. Les organisations locales administraient leurs propres noms et adresses, mais devaient attendre que le NIC modifie HOSTS.TXT pour rendre les changements visibles à l'Internet dans son ensemble. Les organisations voulaient également une certaine structure locale sur l'espace de noms.

  • Les applications sur Internet (The applications) devenaient plus sophistiquées et créaient un besoin de service de noms à usage général.

Le résultat fut plusieurs idées sur les espaces de noms et leur gestion [IEN-116, RFC-799, RFC-819, RFC-830]. Les propositions variaient, mais un fil conducteur commun était l'idée d'un espace de noms hiérarchique, avec la hiérarchie correspondant grossièrement à la structure organisationnelle, et les noms utilisant "." comme caractère pour marquer la limite entre les niveaux hiérarchiques. Une conception utilisant une base de données distribuée et des ressources généralisées a été décrite dans [RFC-882, RFC-883]. Sur la base de l'expérience avec plusieurs implémentations, le système a évolué vers le schéma décrit dans ce mémo.

Les termes « domaine (Domain) » ou « nom de domaine (Domain Name) » sont utilisés dans de nombreux contextes au-delà du DNS décrit ici. Très souvent, le terme nom de domaine est utilisé pour désigner un nom avec une structure indiquée par des points, mais sans relation avec le DNS. Cela est particulièrement vrai dans l'adressage du courrier [Quarterman 86].

2.2. Objectifs de conception du DNS (DNS design goals)​

Les objectifs de conception du DNS influencent sa structure. Ils sont :

  • Espace de noms cohérent (Consistent name space) : L'objectif principal est un espace de noms cohérent qui sera utilisé pour faire référence aux ressources. Afin d'éviter les problèmes causés par les encodages ad hoc, les noms ne doivent pas être obligés de contenir des identifiants de réseau, des adresses, des routes ou des informations similaires dans le cadre du nom.

  • Maintenance distribuée (Distributed maintenance) : La taille considérable de la base de données et la fréquence des mises à jour suggèrent qu'elle doit être maintenue de manière distribuée, avec une mise en cache locale pour améliorer les performances. Les approches qui tentent de collecter une copie cohérente de l'ensemble de la base de données deviendront de plus en plus coûteuses et difficiles, et doivent donc être évitées. Le même principe s'applique à la structure de l'espace de noms, et en particulier aux mécanismes de création et de suppression de noms ; ceux-ci doivent également être distribués.

  • Contrôle des compromis par la source (Source control of tradeoffs) : Lorsqu'il existe des compromis entre le coût d'acquisition des données, la vitesse des mises à jour et la précision des caches, la source des données doit contrôler le compromis.

  • Utilité générale (General utility) : Les coûts de mise en œuvre d'une telle installation dictent qu'elle soit généralement utile et ne soit pas limitée à une seule application. Nous devons être capables d'utiliser des noms pour récupérer des adresses d'hôtes, des données de boîtes aux lettres et d'autres informations encore indéterminées. Toutes les données associées à un nom sont marquées avec un type, et les requêtes peuvent être limitées à un seul type.

  • Indépendance du protocole (Protocol independence) : Parce que nous voulons que l'espace de noms soit utile dans des réseaux et applications dissemblables, nous fournissons la capacité d'utiliser le même espace de noms avec différentes familles de protocoles ou gestion. Par exemple, les formats d'adresse d'hôte diffèrent entre les protocoles, bien que tous les protocoles aient la notion d'adresse. Le DNS marque toutes les données avec une classe ainsi que le type, de sorte que nous puissions permettre une utilisation parallèle de différents formats pour les données de type adresse.

  • Indépendance du transport (Transport independence) : Nous voulons que les transactions du serveur de noms soient indépendantes du système de communication qui les transporte. Certains systèmes peuvent souhaiter utiliser des datagrammes pour les requêtes et les réponses, et n'établir des circuits virtuels que pour les transactions nécessitant la fiabilité (par exemple, mises à jour de base de données, longues transactions) ; d'autres systèmes utiliseront exclusivement des circuits virtuels.

  • Large gamme de capacités d'hôte (Wide host capability range) : Le système doit être utile sur un large spectre de capacités d'hôte. Les ordinateurs personnels et les grands hôtes à temps partagé doivent tous deux pouvoir utiliser le système, bien que peut-être de différentes manières.

2.3. Hypothèses sur l'utilisation (Assumptions about usage)​

L'organisation du système de domaine découle de certaines hypothèses sur les besoins et les modèles d'utilisation de sa communauté d'utilisateurs et est conçue pour éviter de nombreux problèmes compliqués trouvés dans les systèmes de base de données à usage général.

Les hypothèses sont :

  • Taille de la base de données (Database size) : La taille de la base de données totale sera initialement proportionnelle au nombre d'hôtes utilisant le système, mais finira par croître proportionnellement au nombre d'utilisateurs sur ces hôtes à mesure que les boîtes aux lettres et d'autres informations seront ajoutées au système de domaine.

  • Fréquence de mise à jour (Update frequency) : La plupart des données du système changeront très lentement (par exemple, liaisons de boîtes aux lettres, adresses d'hôtes), mais le système doit être capable de traiter des sous-ensembles qui changent plus rapidement (de l'ordre de secondes ou minutes).

  • Limites administratives (Administrative boundaries) : Les limites administratives utilisées pour distribuer la responsabilité de la base de données correspondront généralement aux organisations qui ont un ou plusieurs hôtes. Chaque organisation ayant la responsabilité d'un ensemble particulier de domaines fournira des serveurs de noms redondants, soit sur les propres hôtes de l'organisation, soit sur d'autres hôtes que l'organisation arrange d'utiliser.

  • Serveurs de confiance (Trusted servers) : Les clients du système de domaine doivent être capables d'identifier les serveurs de noms de confiance qu'ils préfèrent utiliser avant d'accepter des références à des serveurs de noms en dehors de cet ensemble « de confiance ».

  • Disponibilité vs cohérence (Availability vs consistency) : L'accès à l'information est plus critique que les mises à jour instantanées ou les garanties de cohérence. Par conséquent, le processus de mise à jour permet aux mises à jour de se propager à travers les utilisateurs du système de domaine plutôt que de garantir que toutes les copies sont mises à jour simultanément. Lorsque les mises à jour ne sont pas disponibles en raison d'une panne de réseau ou d'hôte, le cours habituel est de croire aux anciennes informations tout en continuant les efforts pour les mettre à jour. Le modèle général est que les copies sont distribuées avec des délais d'attente pour le rafraîchissement. Le distributeur définit la valeur du délai d'attente et le destinataire de la distribution est responsable de l'exécution du rafraîchissement. Dans des situations spéciales, des intervalles très courts peuvent être spécifiés, ou le propriétaire peut interdire les copies.

  • Approches de résolution de requête (Query resolution approaches) : Dans tout système possédant une base de données distribuée, un serveur de noms particulier peut se voir présenter une requête à laquelle seul un autre serveur peut répondre. Les deux approches générales pour traiter ce problème sont « récursive (Recursive) », dans laquelle le premier serveur poursuit la requête pour le client auprès d'un autre serveur, et « itérative (Iterative) », dans laquelle le serveur renvoie le client à un autre serveur et laisse le client poursuivre la requête. Les deux approches ont des avantages et des inconvénients, mais l'approche itérative est préférée pour le style d'accès par datagramme. Le système de domaine exige la mise en œuvre de l'approche itérative, mais autorise l'approche récursive en option.

Origine et gestion des données (Data origin and management)​

Le système de domaine suppose que toutes les données proviennent de fichiers maîtres (Master Files) dispersés parmi les hôtes qui utilisent le système de domaine. Ces fichiers maîtres sont mis à jour par les administrateurs système locaux. Les fichiers maîtres sont des fichiers texte qui sont lus par un serveur de noms local, et deviennent ainsi disponibles via les serveurs de noms pour les utilisateurs du système de domaine. Les programmes utilisateur accèdent aux serveurs de noms via des programmes standard appelés résolveurs (Resolvers).

Le format standard des fichiers maîtres permet de les échanger entre hôtes (via FTP, courrier ou un autre mécanisme) ; cette facilité est utile lorsqu'une organisation veut un domaine, mais ne veut pas supporter un serveur de noms. L'organisation peut maintenir les fichiers maîtres localement à l'aide d'un éditeur de texte, les transférer vers un hôte étranger qui exécute un serveur de noms, puis s'arranger avec l'administrateur système du serveur de noms pour faire charger les fichiers.

Les serveurs de noms et résolveurs de chaque hôte sont configurés par un administrateur système local [RFC-1033]. Pour un serveur de noms, ces données de configuration incluent l'identité des fichiers maîtres locaux et les instructions sur quels fichiers maîtres non locaux doivent être chargés depuis des serveurs étrangers. Le serveur de noms utilise les fichiers maîtres ou les copies pour charger ses zones. Pour les résolveurs, les données de configuration identifient les serveurs de noms qui doivent être les sources principales d'information.

Le système de domaine définit des procédures pour accéder aux données et pour les références à d'autres serveurs de noms. Le système de domaine définit également des procédures pour mettre en cache les données récupérées et pour le rafraîchissement périodique des données définies par l'administrateur système.

Division des responsabilités (Division of responsibilities)​

Les administrateurs système fournissent :

  • La définition des limites de zone
  • Les fichiers maîtres de données
  • Les mises à jour des fichiers maîtres
  • Les déclarations des politiques de rafraîchissement souhaitées

Le système de domaine fournit :

  • Des formats standard pour les données de ressource
  • Des méthodes standard pour interroger la base de données
  • Des méthodes standard pour que les serveurs de noms rafraîchissent les données locales depuis des serveurs de noms étrangers

2.4. Éléments du DNS (Elements of the DNS)​

Le DNS comporte trois composants principaux :

ESPACE DE NOMS DE DOMAINE et ENREGISTREMENTS DE RESSOURCES (DOMAIN NAME SPACE and RESOURCE RECORDS)​

L'ESPACE DE NOMS DE DOMAINE et les ENREGISTREMENTS DE RESSOURCES sont des spécifications pour un espace de noms structuré en arbre et des données associées aux noms. Conceptuellement, chaque nœud et feuille de l'arbre de l'espace de noms de domaine nomme un ensemble d'informations, et les opérations de requête sont des tentatives d'extraire des types spécifiques d'informations d'un ensemble particulier. Une requête nomme le nom de domaine d'intérêt et décrit le type d'information de ressource souhaitée. Par exemple, Internet utilise certains de ses noms de domaine pour identifier les hôtes ; les requêtes pour les ressources d'adresse renvoient les adresses d'hôte Internet.

SERVEURS DE NOMS (NAME SERVERS)​

Les SERVEURS DE NOMS sont des programmes serveurs qui détiennent des informations sur la structure de l'arbre de domaine et les informations d'ensemble. Un serveur de noms peut mettre en cache la structure ou les informations d'ensemble sur n'importe quelle partie de l'arbre de domaine, mais en général, un serveur de noms particulier a des informations complètes sur un sous-ensemble de l'espace de domaine, et des pointeurs vers d'autres serveurs de noms qui peuvent être utilisés pour mener aux informations de n'importe quelle partie de l'arbre de domaine. Les serveurs de noms connaissent les parties de l'arbre de domaine pour lesquelles ils ont des informations complètes ; un serveur de noms est dit être une AUTORITÉ (AUTHORITY) pour ces parties de l'espace de noms. Les informations autoritatives sont organisées en unités appelées ZONES, et ces zones peuvent être automatiquement distribuées aux serveurs de noms qui fournissent un service redondant pour les données d'une zone.

RÉSOLVEURS (RESOLVERS)​

Les RÉSOLVEURS sont des programmes qui extraient des informations des serveurs de noms en réponse aux demandes des clients. Les résolveurs doivent être capables d'accéder à au moins un serveur de noms et utiliser les informations de ce serveur de noms pour répondre directement à une requête, ou poursuivre la requête en utilisant des références à d'autres serveurs de noms. Un résolveur sera généralement une routine système directement accessible aux programmes utilisateur ; par conséquent, aucun protocole n'est nécessaire entre le résolveur et le programme utilisateur.

Trois vues du système de domaine (Three views of the domain system)​

Ces trois composants correspondent approximativement aux trois couches ou vues du système de domaine :

  • Du point de vue de l'utilisateur (From the user's point of view), le système de domaine est accessible via une simple procédure ou un appel OS à un résolveur local. L'espace de domaine se compose d'un seul arbre et l'utilisateur peut demander des informations de n'importe quelle section de l'arbre.

  • Du point de vue du résolveur (From the resolver's point of view), le système de domaine est composé d'un nombre inconnu de serveurs de noms. Chaque serveur de noms a une ou plusieurs parties des données de l'ensemble de l'arbre de domaine, mais le résolveur considère chacune de ces bases de données comme essentiellement statique.

  • Du point de vue d'un serveur de noms (From a name server's point of view), le système de domaine se compose d'ensembles séparés d'informations locales appelées zones. Le serveur de noms a des copies locales de certaines zones. Le serveur de noms doit périodiquement rafraîchir ses zones à partir de copies maîtres dans des fichiers locaux ou des serveurs de noms étrangers. Le serveur de noms doit traiter simultanément les requêtes qui arrivent des résolveurs.

Dans l'intérêt des performances, les implémentations peuvent coupler ces fonctions. Par exemple, un résolveur sur la même machine qu'un serveur de noms pourrait partager une base de données composée des zones gérées par le serveur de noms et du cache géré par le résolveur.

Dernière mise à jour le