RFC 1034 novembre 1987
RFC rendues obsolètes : RFC882, RFC883, RFC973 version FR : avril 1998
Statut : Norme Traduction : Valéry G. FREMAUX
Serveur de noms de domaines : Concepts de base
Table des matières
1. Statut de ce mémoire...1
2. Introduction...2
2.1 Historique des noms de domaines...2
2.2 Objectifs de la conception du DNS...2
2.3 Hypothèses d''utilisation...3
2.4 Éléments du DNS...4
3. Espace de noms de domaines et enregistrements de ressourcex...5
3.1 Spécifications et terminologie des noms de domaines...5
3.2 Lignes directrices administratives sur l'utilisation...6
3.3 Conseils techniques d'utilisation...6
3.4 Exemple d'espace de noms...6
3.5 Syntaxe préférentielle pour les noms...7
3.6 Enregistrements de ressource...8
3.7 Interrogations...10
3.7.1 Interrogations standard...10
3.8 Interrogations d'état (expérimental)...12
3.9. Interrogations de fin de traitement (obsolète)...12
4. Serveurs de noms de domaine...12
4.1 Introduction...12
4.2 Comment la base de données est divisée en zones...12
4.2.2 Considérations d'administration...13
4.3 Serveur de noms - spécifications internes...14
5. Résolveurs...18
5.1 Introduction...18
5.2 Interface résolveur-client...18
5.3 Résolveurs - spécifications internes...19
5.3.3 Algorithme...20
6. Scénario...22
6.1 Serveur de nom C.ISI.EDU...22
6.2 Exemple d'interrogations standard...24
6.3 Exemple de résolution...28
7. Références et bibliographie...31
Index...32
1. Statut de ce mémoire
Cette RFC est une introduction au système de noms de domaines (DNS, Domain Name System) et passe sous silence de nombreux détails qui pourront être trouvés dans une RFC complémentaire, "Noms de domaines - mise en œuvre et spécification" [RFC1035]. Cette dernière suppose que le lecteur est déjà familiarisé avec les concepts énoncés dans la présente. Un sous-ensemble des fonctions DNS et des types de données associés constitue un protocole officiel. Le protocole officiel comprend la définition des interrogations standard et des réponses qui y sont faites ainsi que la plupart des formats de classes de données Internet (par exemple, adresses d'hôtes). Cependant, le système de domaines est intentionnellement extensible. Les chercheurs proposent continuellement, mettent en œuvre et expérimentent de nouveaux types de données, types d'interrogations, classes, fonctions, etc. De ce fait, alors que les constituants du protocole officiel sont supposés rester stables et pouvoir être utilisés en exploitation, des comportements expérimentaux pourront être observés au delà des limites de la définition officielle. Les RFC concernées mentionnent clairement les fonctions expérimentales, ou obsolètes, et l'information qui y est rapportée doit toujours être considérée avec précaution. Il est signalé au lecteur de ne jamais considérer les valeurs données à titre d'exemple comme opérationnelles ou complètes, dans la
mesure où leur utilisation n'est faite que dans un but pédagogique. La distribution de ce mémoire n'est soumise à aucune restriction.
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
L'Impulsion pour le développement du système de domaines a été la croissance de l'Internet :
- les transpositions de noms d'hôtes en adresses Internet étaient effectuées par le Centre d'informations du réseau (NIC, Network Information Center) dans un unique fichier (HOSTS.TXT) lequel était transmis par FTP sur tous les hôtes [RFC0952], [RFC0953]. La bande passante réseau totale consommée par la distribution d'une nouvelle version par ce schéma est proportionnelle au carré du nombre d'hôtes dans le réseau, et même lorsque plusieurs niveaux de retransmissions FTP étaient utilisés, la charge de trafic FTP sortant de l'hôte du NIC restait considérable. La croissance explosive du nombre d'hôtes ne présageait rien de bon pour l'avenir.
- La population du réseau changeait dans le même temps de nature. Les hôtes en temps partagé qui constituaient l'ARPANET originel ont été remplacés par des réseaux locaux de stations de travail. 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 aussi avoir une structure locale de l'espace de noms.
- Les applications sur l'Internet sont devenues de plus en plus sophistiquées et ont créé le besoin d'un service plus généraliste des noms de domaines.
Le résultat de tout ceci a fait émerger certaines idées sur les espaces de noms et leur gestion [IEN-116], [RFC0799], [RFC0819], [RFC0830]. Les propositions ont été diverses, mais l'un des traits communs a été l'idée d'un espace de noms hiérarchisé, dont le principe hiérarchique correspondrait en gros à la structure des organisations, et où les noms utiliseraient le caractère "." pour marquer la frontière entre les niveaux hiérarchiques. Un concept mettant en œuvre une base de données distribuée et des ressources généralisées a été décrit dans les [RFC0882], [RFC0883]. Sur la base de l'expérience de plusieurs mises en œuvre, le système a évolué vers celui qui est présenté dans ce mémoire.
Les termes "domaine" ou "nom de domaine" 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 se référer à un nom qui a une structure indiquée par des points, mais sans relation avec le DNS. Ceci est particulièrement vrai pour les adresses de messagerie [Quarterman 86].
2.2 Objectifs de la conception du DNS
Les objectifs de conçeption du DNS ont influencé sa structure. Ces objectifs sont :
- Le but premier est la création d'un espace de noms cohérent utilisable pour se référer aux ressources. Pour éviter les problèmes causés par un codage ad hoc, les noms ne devraient pas être obligés de contenir des étiquettes de réseau, adresses, chemins, ou informations similaire au titre du nom.
- La taille énorme de la base de données et sa fréquence de mise à jour suggèrent une maintenance distribuée, avec antémémoire locale pour améliorer les performances. Les approches qui tenteraient d'obtenir une copie cohérente de la base de donnée entière seront de plus en plus coûteuses et difficiles, et donc devraient évitées. Le même principe tient pour la structure de l'espace de noms, et en particulier les mécanismes pour créer et supprimer les noms ; ceux-ci devraient être également répartis.
- Lorsque on doit composer entre le coût d'acquisition des données, la fréquence des mises à jour, et la validité des antémémoires, c'est toujours la source des données qui devrait contrôler les priorités à donner.
- Les coûts de mise en œuvre d'une telle facilité imposent qu'elle ait une utilité générale, et qui ne soit pas restreinte à une application particulière. On devrait être capable d'utiliser les noms pour restituer les adresses des hôtes, les données des boîtes aux lettres, et d'autres informations non encore identifiées. Toutes les données associées à un nom sont étiquetées avec un type, et les interrogations peuvent être limitées à un seul type.
- Parce qu'on veut que l'espace de noms puisse être utilisé sur des réseaux et applications de natures différentes, nous fournissons la capacité d'utiliser le même espace de noms avec différentes familles ou systèmes de gestion de protocoles. Par exemple, les formats d'adresse d'hôte diffèrent selon les protocoles, bien que tous les protocoles utilisent
utilisation en parallèle de différents formats pour les données de type adresse.
- On veut que les transactions des serveurs de noms soient indépendantes du système de communication qui les porte.
Certains systèmes peuvent souhaiter utiliser des datagrammes pour les interrogations et les réponses, et établir seulement des circuits virtuels pour les transactions qui nécessitent une certaine fiabilité (par exemple, la mise à jour des bases de données, de longues transactions) ; d'autres systèmes vont n'utiliser que des circuits virtuels.
- Le système devrait être utile sur un large spectre de capacités d'hôtes. Aussi bien des micro-ordinateurs que de grands hôtes en temps partagé devraient être capables d'utiliser le système, bien que peut-être avec des méthodes différentes.
2.3 Hypothèses d'utilisation
L'organisation du système des domaines découle de certains présupposés quant aux besoins et aux schémas d'usage de la communauté utilisatrice, et est conçue de sorte à éviter un grand nombre de problèmes compliqués des systèmes de base de données généralistes.
Les hypothèses sont :
- La taille totale de la base de données sera initialement proportionnelle au nombre d'hôtes utilisant le système, mais pourra ensuite croître proportionnellement au nombre d'utilisateurs de ces hôtes lorsque des boîtes aux lettres et autres informations seront ajoutées au système des domaines.
- La fréquence de modification de la plupart des données de cette base sera assez basse (par exemple, les liens de boîtes aux lettres, les adresses d'hôtes) mais le système devrait être capable de 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 la base de données vont généralement correspondre aux organisations qui ont 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, sur l'hôte même de l'organisme, ou sur d'autres hôtes dont l'organisme s'occupe ou qu'elle s'arrange pour exploiter.
- Les clients du système de domaines devraient être capables d'identifier les serveurs de noms de confiance qu'ils préfèrent utiliser avant d'accepter des points de référence à des serveurs de noms en dehors de cet ensemble "de confiance".
- L'accès aux informations est plus critique que la mise à jour instantanée et la garantie de cohérence. De ce fait le processus de mise à jour permet que la mise à jour diffuse à travers les utilisateurs du système des domaines plutôt que de garantir que toutes les copies soient mises à jour simultanément. Lorsque les mises à jour sont indisponibles suite à une défaillance du réseau ou de l'hôte, le cours normal est de s'en remettre aux informations "anciennes" tout en poursuivant les efforts pour les mettre à jour. Le modèle général est que les copies sont distribuées avec des temporisations de rafraîchissement. Le distributeur règle la valeur de la temporisation et le receveur de la distribution est responsable de l'opération de mise à jour. Dans certains cas particuliers, des délais très courts peuvent être spécifiés, ou encore le propriétaire peut interdire la copie.
- Dans tout système possédant une base de données répartie, un serveur de noms particulier pourra recevoir des interrogations auxquelles seuls d'autres serveurs peuvent répondre. Les deux approches principales pour traiter le problème sont soit la méthode "récurrente", par laquelle le premier serveur fait suivre l'interrogation à un autre serveur pour le compte du client, soit la méthode "itérative", par laquelle le serveur renvoie le client sur un autre serveur et le laisse poursuivre l'interrogation. Les deux approches ont leurs avantages et inconvénients, mais l'approche itérative reste toutefois préférée dans le cas où le mode de interrogation est le datagramme. Le système des domaines exige la mise en œuvre de l'approche itérative, mais permet la méthode récurrente en option.
Le système des domaines suppose que toutes les données proviennent de fichiers maîtres éparpillés dans les hôtes qui utilisent le système des domaines. Ces fichiers maîtres sont mis à jour par les administrateurs de système local. Les fichiers maîtres sont des fichiers texte lus par un serveur de noms local, et qui deviennent donc accessibles à tous les utilisateurs du système de domaines par l'intermédiaire des serveurs de noms. Les programmes d'utilisateur accèdent à ces serveurs de noms par des programmes standard appelés "résolveurs".
Le format standard des fichiers maîtres leur permet d'être échangés entre les hôtes (via FTP, messagerie, ou tout autre mécanisme) ; cette facilité est utile lorsque un organisme désire un domaine, mais ne souhaite pas prendre en charge un serveur de domaines. L'organisme pourra maintenir localement les fichiers maîtres avec un éditeur de texte, puis les transférer sur un hôte déporté sur lequel sont exécutés les serveurs de noms, puis voir avec l'administrateur système du serveur de noms pour charger les fichiers.
Les serveurs de noms et résolveurs de chaque hôte sont configurés par un administrateur du système local [RFC1033]. Pour un serveur de noms, ces données de configuration incluent l'identité des fichiers maîtres locaux ainsi que des instructions pour savoir quels fichiers maîtres non locaux doivent être chargés à partir de serveurs distants. Le serveur de noms utilise
les fichiers maîtres ou des copies pour charger ses zones. Pour les résolveurs, les données de configuration identifient les serveurs de noms qui devraient être les sources principales d'information.
Le système des domaines définit des procédures pour accéder aux données et pour se référer à d'autres serveurs de noms.
Le système des domaines définit aussi des procédures pour mettre en antémémoire les données récupérées et pour les rafraîchissements périodiques des données selon la définition de l'administrateur système.
Les administrateurs système fournissent : La définition des limites de zones.
Les fichiers maîtres de données.
La mise à jour des fichiers maîtres.
Les spécifications des politiques de mise à jour désirées.
Le système des domaines fournit :
Les formats standard des ressources de données.
Les méthodes standard d'interrogation de la base de données.
Les méthodes standard pour que les serveurs de noms rafraîchissent les données locales à partir des serveurs de noms distants.
2.4 Élé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 arborescence et les données associées à ces noms. Conceptuellement, chaque nœud et chaque feuille de l'arborescence de l'espace de noms de domaines désigne un ensemble d'informations et les interrogations sont des tentatives pour extraire des types spécifiques d'informations d'un certain ensemble. Une interrogation désigne le nom du domaine qui l'intéresse et décrit le type d'informations de ressource désiré. Par exemple, l'Internet utilise certains de ses noms de domaines pour identifier des hôtes ; des interrogations sur des ressources d'adresses renveront les adresses d'hôtes Internet.
Les SERVEURS DE NOM sont des programmes serveurs qui détiennent les informations sur la structure de l'arborescence des domaines et les informations établies. Un serveur de noms peut mettre en antémémoire les structures ou informations établies sur toute partie de l'arborescence des domaines, mais en général, un certain serveur de noms a des informations complètes sur un sous ensemble de l'espace des domaines, et des pointeurs sur d'autres serveurs de noms qui peuvent être utilisés pour conduire aux informations de toutes les parties de l'arborescence des domaines. Les serveurs de noms connaissent les parties de l'arborescence des domaines pour lesquelles ils détiennent une information complète ; un serveur de noms est dit être une AUTORITÉ pour ces parties de l'espace de noms. Les informations d'autorité sont organisées en unités appelées ZONES, ces zones pouvant être automatiquement réparties aux serveurs de noms qui fournissent un service redondant pour les données d'une zone.
Les RÉSOLVEURS sont des programmes qui extraient les informations des serveurs de noms en réponse aux demandes des clients. Les résolveurs doivent pouvoir accéder à au moins un serveur de noms et utiliser les informations de ce serveur de noms pour donner directement une réponse, ou poursuivre l'interrogation en utilisant les points de référence à d'autres serveurs de noms. Un résolveur sera normalement un sous programme du système qui est directement accessible par un programme utilisateur ; donc aucun protocole n'est nécessaire entre le résolveur et le programme d'utilisateur.
Ces trois composants correspondent en gros aux trois "couches" ou vues du système des noms de domaines :
- Du point de vue de l'utilisateur, le système des domaines est accessible via une procédure simple ou un appel système à un résolveur local. L'espace de domaines consiste en une arborescence unique et l'utilisateur peut demander des informations provenant de toutes les sections de l'arborescence.
- 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 des données de l'arborescence totale des domaines, mais le résolveur voit chacune de ces bases de données comme essentiellement statiques.
- Du point de vue d'un serveur de noms, le système des domaines consiste en ensembles séparés d'informations locales appelés zones. Le serveur de noms a des copies locales de certaines des zones. Le serveur de noms doit rafraîchir périodiquement ses zones à partir de copies maîtresses des fichiers locaux ou des serveurs de noms distants. Les serveurs de noms doivent en même temps traiter les interrogations qui arrivent des résolveurs.
Pour de meilleures performances, les mises en œuvre 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 accueillant les zones gérées par le serveur de nom et l'antémémoire gérée par le résolveur.
3. Espace de noms de domaines et enregistrements de ressource
3.1 Spécifications et terminologie des noms de domaines
L'espace de noms de domaines est une structure arborescente. Chaque nœud et feuille de l'arborescence correspond à un ensemble de ressources (qui peut être vide). Le système des domaines ne fait aucune distinction entre l'utilisation des nœuds et des feuilles de l'intérieur, et le présent mémoire utilise le terme "nœud" pour se référer aux deux.
Chaque nœud dispose d'une étiquette, d'une longueur de zéro à 63 octets. Des nœuds "frères" ne peuvent pas avoir la même étiquette, bien que la même étiquette puisse se retrouver dans deux nœuds qui ne sont pas frères. L'étiquette nulle (c'est-à- dire, de longueur zéro) est réservée pour désigner la racine.
Le nom de domaine d'un nœud est la liste des étiquettes de tous les nœuds sur le chemin entre ce nœud et la racine de l'arborescence. Par convention, les étiquettes qui composent un nom de domaine seront exprimées ou lues de gauche à droite, du plus spécifique (le plus bas, le plus éloigné de la racine) au moins spécifique (le plus haut, le plus proche de la racine).
En interne, les programmes manipulant les noms de domaines devraient les représenter comme des séquences d'étiquettes, où chaque étiquette est un octet de longueur suivi d'une chaîne d'octets. Comme tous les noms de domaines se terminent par la racine, laquelle a une chaîne de longueur nulle comme étiquette, ces représentations internes peuvent utiliser un octet de longueur zéro pour terminer un nom de domaine.
Par convention, les noms de domaines peuvent être mémorisés avec une casse arbitraire, mais les comparaisons de noms de domaines pour toutes les fonctions actuelles des domaines sont faites indépendamment de la casse, en supposant l'usage du jeu de caractères ASCII, et le bit de poids fort à zéro dans chaque octet. Ceci signifie qu'on est libre de créer un nœud d'étiquette "A" ou encore "a", mais pas les deux en tant que frères l'un de l'autre ; ces deux domaines pourront être référencés par "a" ou "A" indistinctement. Cependant, lorsque on reçoit un nom de domaine ou une étiquette, il faut en préserver la casse. La raison en est qu'il sera peut être nécessaire, dans un futur proche, d'étendre les noms de domaines à une représentation binaire complète, dans le but d'accueillir de nouveaux services ; les services existants devant pouvoir rester inchangés.
Lorsqu'un utilisateur doit entrer un nom de domaine, la longueur de chaque étiquette est omise et les étiquettes sont séparées par des points ("."). Un nom de domaine complet se terminant toujours par la racine, la forme écrite exacte de tout domaine entièrement qualifié se termine par un point. On utilise cette propriété pour distinguer les cas :
- d'une chaîne de caractères représentant un nom de domaine complet (souvent appelé "absolu"). Par exemple,
"poneria.ISI.EDU."
- d'une chaîne de caractères représentant les premières étiquettes d'un nom de domaine incomplet (souvent appelé
"relatif"), et qui devrait être complété par le logiciel local en utilisant sa connaissance du domaine local. Par exemple,
"poneria", à utiliser relativement au domaine ISI.EDU.
Les noms relatifs sont exprimés soit par rapport à une origine bien connue, soit par rapport à une liste de domaines utilisée comme liste de recherche. Les noms relatifs apparaissent le plus souvent au niveau de l'interface utilisateur, où leur interprétation varie d'une mise en œuvre à l'autre, ainsi que dans les fichiers maîtres, où il se rapportent à un nom de domaine d'une seule origine. L'interprétation la plus courante utilise la racine "." soit comme seule origine, soit comme l'un des membres de la liste de recherche, et un nom relatif à étiquettes multiples est un nom où le point de fin a été omis pour économiser la frappe.
Pour simplifier les mises en œuvre, le nombre total d'octets qui réprésentent un nom de domaine (c'est à dire la somme de tous les octets d'étiquettes plus les longueurs d'étiquettes) est limité à 255.
Un domaine est identifié par un nom de domaine, et consiste en la portion de l'espace des noms de domainee située au niveau et en dessous du nom de domaine qui spécifie le domaine. Un domaine est un sous domaine d'un autre domaine s'il est contenu au sein de ce domaine. Cette relation peut être vérifiée en regardant si le nom du sous domaine se termine par le nom du domaine le contenant. Par exemple, A.B.C.D est un sous-domaine de B.C.D, C.D, D, et "".
3.2 Lignes directrices administratives sur l'utilisation
En matière de politique, les spécifications techniques du DNS n'imposent aucune structure d'arborescence particulière ni de règles pour le choix des étiquettes ; leur but est d'être les plus générales possible, afin qu'elles puissent servir à toutes sortes d'applications. En particulier, le système a été conçu de sorte que l'espace de noms n'ait pas à suivre les limites physiques de la constitution du réseau, des serveurs de noms, etc. La raison de ceci n'est pas que l'espace de noms n'implique pas une sémantique, mais plutôt que le choix d'une sémantique implicite devrait rester ouvert pour pouvoir s'adapter aux problèmes particuliers lorsqu'ils se présentent, et qu'il reste acceptable que certaines sous parties de l'arborescence puissent user de sémantiques différentes. Par exemple, le domaine IN-ADDR.ARPA est organisé et distribué en réseaux et adresses d'hôtes car son rôle est de traduire des numéros de réseau ou d'hôtes en noms ; les domaines NetBIOS [RFC1001[, [RFC1002] sont des domaines plats parce que c'est approprié pour cette application.
Cependant, il y a quelques lignes directrices qui s'appliquent aux parties "normales" de l'espace de noms utilisé pour les hôtes, boîtes aux lettres, etc., qui rendront l'espace de noms plus uniforme, préserveront sa capacité de croissance, et minimiseront les problèmes lorsque des logiciels sont convertis à partir du tableau ancien. Les décisions de politiques sur les niveaux supérieurs de l'arborescence ont été prises dans la [RFC0920]. La politique actuelle pour les niveaux supérieurs est discutée dans la [RFC1032]. Les problèmes de conversion pour l'espace MILNET sont couverts dans la [RFC1031].
Les domaines inférieurs qui peuvent à leur tour être subdivisés en zones multiples devraient pouvoir proposer des embranchements au sommet du domaine de telle sorte que d'éventuelles décompositions puissent se faire sans changement de noms. Les étiquettes de nœuds utilisant des caractères spéciaux, des chiffres en tête, etc., risquent de poser des problèmes à des programmes plus anciens fondés sur des choix plus restrictifs.
3.3 Conseils techniques d'utilisation
Avant que le DNS puisse être utilisé pour accueillir les informations de nommage de quelque catégorie d'objets que ce soit, deux besoins doivent être satisfaits :
- Une convention pour la transposition entre noms d'objets et noms de domaines. Cela décrit comment on accède aux informations sur un objet.
- Les types de RR et les formats de données pour la description des objets.
Ces règles peuvent être assez simples ou très complexes. Très souvent, le concepteur doit prendre en compte les formats existants et doit planifier une compatibilité ascendante pour les utilisations actuelles. Plusieurs conversions et niveaux de conversion peuvent devenir nécessaires.
Pour les hôtes, la conversion dépend de la syntaxe existante pour les noms d'hôtes, elle-même un sous ensemble de la représentation textuelle courante pour les noms de domaine, ainsi que des formats de RR décrivant les adresses des hôtes, etc.. Dans la mesure ou nous souhaitons pouvoir disposer d'une transposition inverse fiable des adresses d'hôtes vers les noms d'hôtes, une transposition particulière pour les adresses dans le domaine IN-ADDR.ARPA est aussi définie.
Pour les boîtes aux lettres, la transposition est légèrement plus complexe. L'adresse de messagerie habituelle <partie- locale>@<domaine-de-messagerie> est transposée en nom de domaine par la conversion de la <partie-locale> en une étiquette simple (sans tenir compte des points qu'elle contient), et en convertissant le <domaine-de-messagerie> en un nom de domaine conforme au format de texte usuel pour les noms de domaine (des points séparant les étiquettes) et à enchaîner les deux parties pour former un nom de domaine unique. Ainsi, la boîte aux lettres HOSTMASTER@SRI-NIC.ARPA est représentée comme nom de domaine par HOSTMASTER.SRI-NIC.ARPA. L'appréciation des raisons conduisant à ce dessin doit aussi prendre en compte le schéma des échanges de courrier [RFC0974].
L'utilisateur type n'est pas concerné par l'établissement de ces règles, mais devrait néanmoins comprendre qu'elles résultent de nombreux compromis entre des contraintes de compatibilité ascendante pour d'anciennes applications toujours en service, des interactions entre les différentes définitions d'objets, et l'incontournable urgence qu'il y a à développer de nouvelles fonctionnalités lorsque de nouvelles règles sont établies. La manière dont le DNS est exploité pour prendre en compte tel ou tel objet est souvent plus importante que les restrictions inhérentes au DNS.
3.4 Exemple d'espace de noms
La figure suivante montre une partie de l'espace de noms de domaines actuel, et sert de base d'exemple à de nombreuses reprises dans cette RFC. Notez que cette arborescence est un tout petit sous ensemble de l'espace des noms de domaines réel.
|
+---+---+
| | | MIL EDU ARPA | | | | | |
+---+---+ | +---+---+---+
| | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC |
+---+---+---+---+
| | | | | UCI MIT | UDEL YALE | ISI
| | +---+---+ | | | |
LCS ACHILLES +--+---+---+---+
| | | | | |
XX A C VAXA VENERA Mockapetris
Dans cet exemple, le domaine racine a trois sous domaines immédiats : MIL, EDU, et ARPA. Le domaine LCS.MIT.EDU a un sous domaine immédiat appelé XX.LCS.MIT.EDU. Toutes les feuilles sont également des domaines.
3.5 Syntaxe préférentielle pour les noms
Les spécifications du DNS tentent d'être aussi génériques que possible pour ce qui concerne les règles de construction des noms de domaines. L'idée est que le nom de tout objet existant puisse être exprimé comme un nom de domaine avec le minimum de changements. Cependant, au moment d'assigner un nom de domaine à un objet, l'utilisateur prudent choisira un nom qui d'une part respecte les règles du système de domaines et d'autre part respecte toutes les règles existantes pour l'objet, que ces règles aient été publiées ou qu'elles soient impliquées par les programmes existants.
Par exemple, pour nommer un domaine de courrier, l'utilisateur devrait respecter les règles du présent mémoire ainsi que celles établies par la [RFC0822]. Quand on crée un nouveau nom dhôte, les anciennes règles instaurées pour HOSTS.TXT devraient être suivies. Cela permet d'éviter des problèmes lorsque d'anciens programmes sont transformés pour prendre en compte les noms de domaine.
La syntaxe suivante diminuera le risque de problèmes avec beaucoup d'applications qui utilisent les noms de domaine (par exemple, mail, TELNET).
<domaine> ::= <sous-domaine> | " "
<sous-domaine> ::= <étiquette> | <sous-domaine> "." <étiquette>
<étiquette> ::= <lettre> [ [ <ch-ldh> ] <let-dig> ]
<ch-ldh> ::= <let-dig-hyp> | <let-dig-hyp> <ch-ldh>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <lettre> | <chiffre>
<lettre> ::= un des 52 caractères alphabétiques de "A" à "Z" (majuscules) ou de "a" à "z" (minuscules)
<chiffre> ::= un des dix chiffres de "0" à "9"
Noter que, bien que tant les majuscules que les minuscules soient autorisées dans des noms de domaines, aucune signification n'est accordée à la casse. C'est-à-dire, deux noms lexicographiquement identiques, mais écrits dans une casse différente seront considérés comme identiques.
Les étiquettes doivent suivre les règles définies pour les noms d'hôtes ARPANET. Ils doivent commencer par une lettre, se terminer par une lettre ou un chiffre, et n'avoir à l'intérieur que des lettres, des chiffres, et éventuellement le caractère trait d'union (-). Il y a aussi quelques restrictions sur la longueur. Une étiquette doit avoir au plus 63 caractères.
Par exemple, les chaînes suivantes identifient des hôtes d'Internet : A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
3.6 Enregistrements de ressource
Un nom de domaine identifie un nœud. A chaque nœud est attribué un ensemble d'informations sur des ressources, lequel peut être vide. L'ensemble d'informations de ressources associé à un nom particulier est composé d'enregistrements de ressources (RR) séparés. L'ordre des RR dans un ensemble n'est pas significatif, et n'a pas besoin d'être préservé par les serveurs de noms, les résolveurs, ou autres parties du DNS.
Lorsque on parle d'un RR spécifique, on suppose qu'il contient les éléments suivants : Propriétaire le nom de domaine où le RR se trouve.
Type valeur codée sur 16 bits spécifiant le type de la ressource dans cet enregistrement de ressource. Les types se réfèrent à des ressources abstraites.
Le présent mémoire définit les types suivants : A une adresse d'hôte
CNAME le nom canonique d'un alias
HINFO le CPU et le système d'exploitation (OS) d'un hôte
MX un schéma d'échange de courrier pour ce domaine. Voir les détails dans la [RFC0974].
NS le serveur de noms d'autorité pour le domaine
PTR un pointeur vers une autre partie de l'espace de noms de domaines SOA identifie le début d'une zone d'autorité
Classe une valeur codée sur 16 bits étiquette une famille de protocoles ou une instance d'un protocole.
Le présent mémoire définit les classes suivantes : IN le système Internet
CH le système Chaos
TTL la durée de vie du RR. Ce champ est un entier de 32 bits en unités de secondes, et est principalement utilisé par les résolveurs lorsqu'ils mettent leurs RR en antémémoire. Le TTL décrit combien de temps un RR peut être conservé en antémémoire avant de devoir être éliminé.
RDATA le type et parfois des données dépendantes de la classe décrivant la ressource : A pour la classe IN, une adresse IP sur 32 bits.
pour la classe CH, un nom de domaine suivi d'une adresse octale Chaos sur 16 bits.
CNAME un nom de domaine.
MX une valeur de préférence sur 16 bits (le plus bas est le préféré) suivie d'un nom d'hôte souhaitant servir d'échangeur de courrier pour le domaine du propriétaire.
NS un nom d'hôte.
PTR un nom de domaine.
SOA plusieurs champs.
Le nom du propriétaire (owner) est souvent implicite, plutôt que formant une partie intégrante du RR. Par exemple, de nombreux serveurs de noms représentent l'espace de nom en interne sous forme d'arborescence ou de tableaux associatifs, et enchaînent les RR hors des nœuds. Les parties restantes des RR sont l'en-tête fixe (type, classe, TTL) valable pour tous les RR, et une partie variable (RDATA) adaptée aux besoins de la ressource décrite.
La signification du champ TTL est la limite de durée pendant laquelle un RR peut être conservé dans une antémémoire.
Cette limite ne s'applique pas aux données d'autorité dans les zones ; celles-ci disposent aussi d'une temporisation, mais définie par la politique de rafraîchissement de la zone. La TTL est définie par l'administrateur pour la zone d'où provient cet enregistrement. Alors qu'une valeur faible de TTL peut être utilisée pour diminuer la durée en antémémoire, et qu'une valeur de zéro empêche tout stockage local, l'analyse réelle des performances d'Internet suggère que cette valeur devrait être de l'ordre de quelques jours pour un hôte type. Lorsque l'on peut anticiper une modification, la TTL pourra être réduite avant d'effectuer la modification pour optimiser la cohérence de l'information au moment du changement, puis être rétablie à sa valeur d'origine après le changement.
Les données dans la section RDATA des RR sont portées comme une combinaison de chaînes binaires et de noms de domaines. Les noms de domaines sont souvent utilisés comme "pointeurs" sur d'autres données du DNS.
3.6.1 Expression textuelle des RR
Les RR sont représentés sous forme binaire dans les paquets du protocole DNS, et sont habituellement représentés sous une forme fortement compactée lorsque stockés par un serveur de noms ou un résolveur. Dans ce document, nous adoptons un style similaire à celui utilisé dans les fichiers maîtres afin de montrer le contenu des RR. Dans ce format, la plupart des RR sont monrés sur une seule ligne, bien qu'une extension sur plusieurs lignes soit possible par l'utilisation de parenthèses.
Au début de la ligne est mentionné le propriétaire du RR. Si une ligne commence par une espace, le propriétaire de l'enregistrement est supposé être le même que celui du RR précédent. Des lignes vides sont souvent insérées pour augmenter la lisibilité.
Après le propriétaire, on fait figurer la TTL, le type, et la classe du RR. Classe et type utilisent les mnémoniques définis ci- avant, la TTL étant un entier qui apparaît avant le champ type. Afin d'éviter les ambiguïtés à l'analyse, les mnémoniques du type et de la classe sont disjoints, les TTL sont des entiers, et le mnémonique de type est toujours en dernier. La classe IN et les valeurs de TTL sont souvent omises dans les exemples par souci de clarté.
La section Données de ressource ou RDATA du RR est exprimée en utilisant la connaissance de la représentation normale pour les données.
Par exemple, on peut montrer les RR portés par un message sous la forme suivante : ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33
Les RR MX ont une section RDATA consistant en un nombre de 16 bits suivi par un nom de domaine. L'adresse des RR utilise un format standard d'adresse IP pour contenir une adresse Internet de 32 bits.
Cet exemple montre six RR, répartis en groupes de deux RR pour chacun des trois noms de domaines.
De la même manière nous pourrions voir :
XX.LCS.MIT.EDU. IN A 10.0.0.44 CH A MIT.EDU. 2420
représentant deux adresses pour l'hôte XX.LCS.MIT.EDU, chacune d'une classe différente.
3.6.2 Alias et expression canonique des noms
Dans des systèmes existants, les hôtes et autres ressources ont souvent plusieurs noms qui identifinet la même ressource.
Par exemple, les noms C.ISI.EDU et USC-ISIC.ARPA identifient le même hôte. De la même manière, dans le cas de boîtes aux lettres, de nombreuses organisations fournissent de nombreux noms qui pointent sur la même boîte aux lettres ; par exemple Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU, et PVM@ISI.EDU pointent toutes la même boîte aux lettres (bien que le mécanisme derrière tout cela soit légèrement plus compliqué).
La plupart de ces systèmes utilisent une notion selon laquelle un des noms de l'ensemble est le nom canonique ou nom principal, et tous les autres sont des alias.
Le système de domaines dispose d'une telle fonctionnalité par l'utilisation du RR nom canonique (CNAME). Un RR CNAME identifie son nom de propriétaire comme étant un alias, et spécifie le nom canonique correspondant dans la section RDATA du RR. Si un RR CNAME est présent dans un nœud, aucune autre donnée ne devrait y être présente ; cette restriction garantit que les données pour un nom canonique et ses alias ne peuvent pas être différents. Cette règle assure de plus qu'un CNAME en antémémoire peut être utilisé sans vérifier auprès un serveur d'autorité les autres types de RR.
Les RR CNAME provoquent des actions particulières dans un logiciel de DNS. Lorsqu'un serveur de noms échoue à trouver un enregistrement désiré dans l'ensemble de ressource associé au nom de domaine, il vérifie si l'ensemble de
ressources consiste en un enregistrement CNAME avec une classe correspondante. Si c'est le cas, le serveur de noms inclut l'enregistrement CNAME dans la réponse et recommence l'interrogation au nom de domaine spécifié dans le champ Données de l'enregistrement CNAME. La seule exception à cette règle est que les interrogations qui corrrespondent au type CNAME ne sont pas recommencées.
Par exemple, supposons qu'un serveur de noms traite une interrogation sur le domaine USC-ISIC.ARPA, pour un type d'information A, et dispose des enregistrements de ressource suivants :
USC-ISIC.ARPA IN CNAME C.ISI.EDU C.ISI.EDU IN A 10.0.0.52
Les deux RR seraient retournés dans une réponse à une interrogation de type A, tandis qu'une interrogation sur le type CNAME ou * retournetrait juste le CNAME.
Les noms de domaine dans les RR pointant sur un autre nom devraient toujours pointer sur un nom principal et non sur un alias. Ceci évitera une multiplication inutile des informations d'accès. Par exemple, l'adresse pour désignr les RR pour l'hôte ci-dessus devrait être :
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
plutôt que de pointer sur USC-ISIC.ARPA. Bien sûr, selon le principe de robustesse, les logiciels de domaines ne devraient pas échouer face à des chaînes ou des boucles de CNAME. Les enchaînements de CNAME devraient être suivis et les boucles de CNAME signalées comme erreur.
3.7 Interrogations
Les interrogations sont des messages qui peuvent être envoyés à un serveur de noms pour provoquer une réponse. Dans l'Internet, les interrogations sont portées dans des datagrammes UDP ou sur des connexions TCP. La réponse du serveur de nom peut répondre à la question posée par l'interrogation, renvoyer le demandeur vers un autre ensemble de serveurs de noms, ou signaler une condition d'erreur.
En général, l'utilisateur ne génère pas directement des interrogations, mais fait plutôt une demande à un résolveur qui à son tour envoie une ou plusieurs interrogations à des serveurs de noms et traite les conditions d'erreur ou les points de référence qui peuvent en résulter. Bien sûr, les questions possibles qui peuvent être posées dans une interrogation doivent correspondre au type de service pour lequel le résolveur est conçu.
Les interrogations et réponses DNS sont transportées dans un format de message standard. Le format de message a un en- tête contenant un certain nombre de champs fixes toujours présents, et quatre sections qui portent les paramètres d'interrogation et les RR.
Le champ le plus important dans l'en-tête est un champ de 4 bits appelé opcode (code d'opération) qui sépare les différentes interrogations. Parmi les 16 valeurs possibles, une (interrogation standard) fait partie du protocole officiel, deux autres (interrogation inverse et interrogation d'état) sont des options, une autre (fin de traitement) est obsolète, les autres restant non allouées à l'heure actuelle.
Les quatre sections sont :
Question contient le nom de l'interrogation et les autres paramètres de l'interrogation.
Réponse contient les RR qui répondent directement à l'interrogation.
Autorité contient les RR décrivant d'autres serveurs d'autorité. Peut aussi contenir le RR SOA pour les données d'autorité dans la section réponse.
Additionnel contient des RR qui peuvent aider à exploiter les RR contenus dans les autres sections.
Noter que le contenu, (mais pas le format) de ces sections varie selon le opcode de l'en-tête.
3.7.1 Interrogations standard
Une interrogation standard contient un nom de domaine cible (QNAME), un type d'interrogation (QTYPE), et une classe d'interrogation (QCLASS) et appelle les RR qui correspondent. Ce type d'interrogation représente une telle majorité des interrogations au DNS qu'on utilise le terme "interrogation" pour signifier interrogation standard sauf mention contraire.
Les champs QTYPE et QCLASS font chacun 16 bits de long, et sont un surensemble des types et classes définis.
Le champ QTYPE peut contenir :
<tout type> correspond juste à ce type. (par exemple, A, PTR).
AXFRQ QTYPE spécial pour transfert de zone.
MAILB correspond pour tous les RR de boîtes aux lettres (par exemple, MB et MG).
* correspond pour tous les types de RR.
Le champ QCLASS peut contenir :
<toute classe> correspond juste sur cette classe (par exemple, IN, CH).
* correspond pour toutes les classes de RR.
En utilisant le nom de domaine cible de l'interrogation, le QTYPE, et la QCLASS, le serveur de noms recherche les RR qui correspondent. En plus des enregistrements pertinents, le serveur de noms peut retourner des RR pointant vers un serveur de noms qui détient les informations désirées ou des RR qui pourraient aider à l'interprétation des RR pertinents. Par exemple, un serveur de noms qui ne dispose pas des informations demandées peut connaître un autre serveur de nom qui les détient ; un serveur de noms qui retourne un nom de domaine dans un RR pertinent peut aussi retourner le RR qui lie ce nom de domaine à une adresse.
Par exemple, un agent de courrier tentant d'envoyer un message dans la boîte aux lettres Mockapetris@ISI.EDU peut demander à son résolveur des informations sur le serveur de courrier de ISI.EDU, résultant en une interrogation sur QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. La section réponse renvoyée serait :
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
et la section additionnelle :
VAXA.ISI.EDU. A 10.2.0.27 A 128.9.0.33 VENERA.ISI.EDU. A 10.1.0.52 A 128.9.0.32
Comme le serveur suppose que si le requérant désire des informations sur un échange de courrier, il désirera probablement obtenir les adresses de ces échanges peu après.
Notez que l'écriture QCLASS=* nécessite une interprétation particulière notamment concernant l'autorité. Dans la mesure où un serveur de noms ne connaît pas nécessairement toutes les classes disponibles dans le système de domaines, il ne peut jamais savoir si il est d'autorité pour toutes les classes. Donc les réponses aux interrogations QCLASS=* ne peuvent jamais être d'autorité.
3.7.2 Interrogations inverses (facultatif)
Les serveurs de noms peuvent également supporter des interrogations inverses qui transposent une ressource particulière en un ou des noms de domaine qui ont cette ressource. Par exemple, alors qu'une interrogation standard peut tranposer un nom de domaine en un RR SOA, l'interrogation inverse correspondante peut retransposer ce RR SOA en le nom de domaine.
La mise en œuvre de ce service est facultative dans un serveur de noms de domaines, mais tous les serveurs de noms doivent au moins être capables de comprendre un message d'interrogation inverse et de retourner une réponse d'erreur "non mis en œuvre". Le système des domaines ne peut pas garantir la complétude ou l'unicité des interrogations inverses parce que le système des domaines est organisé par noms de domaines, et non sur l'adresse d'hôte ou autre type de ressource. Les interrogations inverses sont principalement utiles pour des fonctions de débogage et de maintenance des bases de données.
Les interrogations inverses peuvent ne pas renvoyer la TTL appropriée, et n'indiquent pas les cas où le RR identifié fait partie d'un ensemble (par exemple, une adresse d'un hôte disposant de plusieurs adresses). De ce fait, les RR retournés par des interrogations inverses ne devraient jamais être mises en antémémoire.
Les interrogations inverses NE sont PAS une méthode acceptable pour transposer les adresses d'hôtes en noms d'hôtes ; il faut plutôt utiliser le domaine IN-ADDR.ARPA. Une discussion détaillée sur les interrogations inverses se trouve dans la [RFC1035].
3.8 Interrogations d'état (expérimental) À définir.
3.9. Interrogations de fin de traitement (obsolète)
Le service optionnel de mention de fin de traitement défini dans les RFC 882 et 883 a été supprimé. Un service de ce type complètement rénové sera peut être rétabli à l'avenir, ou bien les codes d'opération réservés pour cette ancienne fonctionnalité seront réaffectés.
4. Serveurs de noms de domaine
4.1 Introduction
Les serveurs de noms sont les dépositaires des informations qui constituent la base de données des domaines. La base de données est divisée en sections appelées zones, qui sont réparties entre les serveurs de noms. Comme les serveurs de noms peuvent avoir plusieurs fonctions et sources de données facultatives, la tâche essentielle d'un serveur de noms est de répondre aux interrogations en utilisant les données qui sont dans ses zones. Par conception, les serveurs de noms peuvent répondre à ces interrogations d'une manière simple ; la réponse peut toujours être générée à partir des seules données locales, et contenir soit la réponse à la question posée, soit un point de référence à d'autres serveurs de noms "plus proches"
des informations désirées.
Une zone donnée pourra être accessible à partir de plusieurs serveurs de noms afin d'assurer sa disponibilité même en cas de défaillance du serveur ou des liaisons de communication. Par décision "administrative", on impose que toute zone soit accessible au moins par deux serveurs, et de nombreuses zones sont encore plus redondantes.
Un serveur de noms donné va normalement prendre en charge une ou plusieurs zones, mais ceci ne lui donne des informations d'autorité que pour une petite partie de l'arborescence des domaines. Il peut aussi détenir une certaine quantité de données non d'autorité dans son antémémoire sur d'autres parties de l'arborescence. Le serveur de noms marque ses réponses aux interrogations de telle sorte que le demandeur puisse dire si les informations proviennent de données d'autorité ou non.
4.2 Comment la base de données est divisée en zones
La base de données de domaines est divisée selon deux méthodes : par classes, et par "coupures" faites dans l'espace des noms entre les nœuds.
La partition en classes est simple. La base de données pour toute classe est organisée, déléguée, et maintenue séparément de toutes les autres classes. Comme par convention, l'espace de noms est le même pour toutes les classes, la séparation par classe peut être vue comme une matrice d'arborescences de noms parallèles. Noter que les données attachées aux nœuds des arborescences seront différentes pour ces différentes classes parallèles. Les raisons les plus courantes pour créer une nouvelle classe sont la nécessité d'un nouveau format de données pour des types existants, ou le désir d'une version gérée séparément de l'espace de noms existant.
Dans une classe, des "coupures" dans l'espace de noms peuvent être faites entre deux nœuds adjacents quelconques. Une fois toutes les coupures définies, chaque groupe de l'espace de noms connectés devient une zone séparée. La zone est dite être d'autorité pour tous les noms dans la région connectée. Noter que les "coupures" dans l'espace de noms peuvent être à des endroits différents pour des classes différentes, que les serveurs de noms peuvent être différents, etc.
Ces règles signifient que chaque zone a au moins un nœud, et donc un nom de domaine, pour lequel il est d'autorité, et que tous les nœuds d'une zone particulière sont connectés. Du fait de la structure arborescente, chaque zone a un nœud de plus haut niveau qui est plus proche de la racine que tous les autres nœuds de cette zone. Le nom de ce nœud est souvent utilisé pour identifier la zone.
Il serait possible, bien que pas forcément utile, de partitionner l'espace de noms de telle façon que chaque nom de domaine se trouve dans une zone séparée ou au contraire que tous les nœuds se retrouvent dans une zone unique. Au lieu de cela, la base de données est partitionnée aux points où une organisation particulière accepte de gérer la sous arborescence inférieure au point de coupure. Une fois qu'une organisation contrôle sa propre zone, elle peut modifier les données dans cette zone de façon unilatérale, créer des nouvelles sous arborescences à l'intérieur de la zone, supprimer des nœuds existants, ou déléguer la gestion de nouvelles sous zones à d'autres organisations plus locales.
Si l'organisation a elle même une sous structure, elle peut souhaiter créer des partitions internes pour réaliser des délégations incorporées du contrôle de l'espace de noms. Dans certains cas, de telles divisions ne sont faites que pour rendre plus maniable la maintenance de la base de données.
4.2.1 Considérations techniques
Les données décrivant une zone ont quatre parties majeures : - Les données d'autorité pour tous les nœuds dans la zone.
- Les données qui définissent le nœud de niveau supérieur de la zone (peuvent être considérées comme faisant partie des données d'autorité).
- Les données qui décrivent les sous zones déléguées, c'est-à-dire, les points de coupure dans les étages inférieurs de la zone.
- Les données qui permettent l'accès aux serveurs de noms pour les sous-zones (parfois appelées "données glu").
Toutes ces données sont exprimées sous forme de RR, et donc une zone peut être entièrement décrite comme un ensemble de RR. Des zones entières peuvent être transférées de serveur à serveur par le transfert des RR, par une suite de messages, ou en transférant les RR, soit portés dans une série de messages, soit en envoyant par FTP un fichier maître qui en est une représentation textuelle.
Les données d'autorité pour une zone sont simplement tous les RR rattachés à tous les nœuds depuis le nœud du sommet de la zone jusqu'aux nœuds feuilles les plus bas, ou aux nœuds immédiatement au-dessus d'un point de coupure autour du bord inférieur de la zone.
Bien que faisant logiquement partie des données d'autorité, les RR qui décrivent le nœud supérieur sont d'une importance toute particulière pour la gestion de la zone. Ces RR sont de deux types : les RR de serveurs de noms qui font la liste, à raison de un par RR, de tous les serveurs pour la zone, et un RR SOA unique qui décrit les paramètres de gestion de la zone.
Les RR qui décrivent les coupures vers le bas de la zone sont des RR NS qui pointent sur les serveurs de noms auxquels ont été déléguées les sous-zones. Comme les coupures se font entre des nœuds, ces RR NE font PAS partie des données d'autorité de la zone, et devraient être exactement les mêmes que les RR correspondants dans le nœud de tête de la sous- zone. Comme les serveurs de noms sont toujours associés aux limites de zones, les RR NS ne se trouvent que dans des nœuds qui sont le nœud supérieur d'une zone. Dans les données qui constituent une zone, les RR NS se trouvent au nœud supérieur de la zone (et sont d'autorité) et aux coupures autour du fond de la zone (où ils ne sont pas d'autorité) mais jamais entre.
L'un des objectifs de cette structure en zones est que toute zone puisse disposer de toutes les données nécessaires pour établir des communications avec les serveurs de noms de chacune de ses sous-zones. En d'autres termes, que les zones parentes disposent de toutes les informations requises pour accéder aux serveurs de leurs zones filles. Les RR NS qui désignent ces serveurs pour les sous-zones ne suffisent pas toujours à cette tâche car si ils désignent le serveur, ils n'en donnent pas l'adresse. En particulier, si le nom du serveur de noms est lui-même dans la sous-zone, on pourrait être confronté à la situation où le RR NS nous dit que pour connaître l'adresse d'un serveur de noms, on devrait contacter le serveur en utilisant l'adresse que nous souhaitons justement apprendre. Pour régler ce problème, une zone contient des RR
"glu" qui ne font pas partie des données d'autorité, et sont des RR d'adresses pour les serveurs. Ces RR ne sont nécessaires que si le nom du serveur de nom se situe "en dessous" de la coupure, et ne sont utilisés qu'au titre d'une réponse de point de référence.
4.2.2 Considérations d'administration
Lorsque une organisation veut contrôler son propre domaine, la première étape est d'identifier la bonne zone parente, et obtenir des "propriétaires" de la zone parente un accord sur la délégation de contrôle. Bien qu'il n'y ait aucune contrainte technique particulière qui détermine où dans l'arborescence cela peut être effectué, certains regroupements administratifs sont exposés dans la [RFC1032] concernant l'organisation des niveaux supérieurs, les zones médianes restant libres de créer leurs propres règles. Par exemple, une université pourrait choisir de n'utiliser qu'une seule zone, tandis qu'une autre pourrait choisir de s'organiser en sous-zones, dédiées chacune à un département ou une école. La [RFC1033] fait un catalogue des logiciels de DNS disponibles et expose les procédures administratives.
Une fois choisi le nom approprié pour la sous zone, les nouveaux propriétaires devraient être requis de démontrer leur capacité à prendre en charge des serveurs de domaines redondants. Noter qu'il n'y a pas d'obligation que les serveurs pour
une zone soient implantés sur une machine disposant d'un nom dans ce domaine. Dans de nombreux cas, une zone sera plus accessible à l'Internet au sens large si les serveurs qui la gèrent sont répartis, plutôt que concentrés sur le site physique contrôlé par l'organisation qui gère la zone. Par exemple, dans le DNS actuel, un des serveurs de noms pour Royaume UNi, ou domaine UK, est situé aux États-Unis. Ceci permet aux hôtes américains d'obtenir les données "UK" sans être limités par la bande passante transatlantique.
Dans la dernière étape d'installation, les RR NS de délégation et les RR "glu" nécessaires pour rendre effective la délégation devraient être ajoutés à la zone parente. Les administrateurs des deux zones devraient s'assurer que les RR NS et
"glu" situés de chaque côté de la coupure sont cohérents et le restent.
4.3 Serveur de noms - spécifications internes 4.3.1 Interrogations et réponses
La principale activité d'un serveur de noms est de répondre aux interrogations standard. L'interrogation et sa réponse sont toutes deux portées par un message de format standard décrit dans la [RFC1035]. L'interrogation contient un QTYPE, QCLASS, et QNAME, qui décrivent les types et classes de l'information souhaitée, et le nom concerné.
La manière dont le serveur de noms répond à l'intérrogation dépend de si il fonctionne en mode récurrent ou non :
- Le mode le plus simple pour le serveur est le mode non récurrent, dans la mesure où il peut répondre à l'interrogation en utilisant seulement ses informations locales : la réponse contient une erreur, la réponse demandée, ou un point de référence à un autre serveur plus "proche" de la réponse. Tous les serveurs de noms doivent mettre en œuvre les interrogations non récurrentes.
- Le mode le plus simple pour le client est le mode récurrent, car dans ce mode, le serveur de noms agit comme résolveur et retourne soit un message d'erreur, soit une réponse valide, mais jamais de point de référence. Ce service est facultatif dans un serveur de noms, ce dernier peut aussi choisir de restreindre l'utilisation par les clients du mode récurrent.
Le service récurrent est utile dans plusieurs situations :
- un demandeur relativement simple qui n'a pas la capacité d'utiliser autres chose qu'une réponse directe à la question.
- une interrogation qui doit passer à travers d'autres protocoles ou autres "frontières" et peut être envoyée à un serveur jouant le rôle d'intermédiaire.
- un réseau dans lequel on veut concentrer l'antémémoire plutôt qu'avoir une antémémoire pour chaque client.
Le service non récurrent est approprié si le demandeur est capable de suivre les points de référence et est intéressé par les informations qui l'aideront pour des demandes futures.
L'utilisation du mode récurrent est limitée aux cas où le client et le serveur s'accordent sur son usage. Cet accord est négocié par l'utilisation de deux bits des messages d'interrogation et de réponse :
- Le bit RA (Récurrence disponible) est mis à un ou à zéro par un serveur de noms dans toutes les réponses. Ce bit est vrai si le serveur accepte de fournir le service récurrent au client, que ce dernier l'ait demandé ou non. Autrement dit, le bit RA signale la disponibilité du service plutôt que son utilisation.
- Les interrogations disposent d'un bit RD (récurrence désirée). Ce bit spécifie si le demandeur veut utiliser le service récurrent pour cette interrogation. Les clients peuvent demander le service récurrent à n'importe quel serveur de noms, bien que ce service ne puisse leur être fourni que par les serveurs qui auront déjà établi (à 1) leur bit RA, ou des serveurs qui auront donné leur accord pour ce service par un accord privé ou tout autre moyen hors du champ du protocole DNS.
Le mode récurrent se produit lorsqu'une interrogation arrive avec un bit RD établi sur un serveur qui accepte de fournir le service récurrent ; le client peut vérifier si le mode récurrent a été utilisé en vérifiant que les deux bits RA et RD ont été établis dans la réponse. Noter que le serveur de noms ne devrait jamais utiliser le service récurrent s'il n'a pas été explicitement demandé par un bit RD, car cela interfère avec la maintenance des serveurs de noms et de leurs bases de données.
Si le service récurrent est demandé et est disponible, la réponse récurrente à une interrogation doit être l'une des suivantes : - La réponse à l'interrogation, éventuellement préfacée par un ou plusieurs RR CNAME qui indiquent les alias trouvés
pendant la recherche de la réponse.
- Une erreur de nom indiquant que le nom n'existe pas. Cela peut inclure des RR CNAME qui indiquent que le nom de l'interrogation originale était un alias pour un nom qui n'existe pas.
- Une indication d'erreur temporaire.
Si le service récurrent n'est pas demandé, ou n'est pas disponible, la réponse non récurrente sera l'une des suivantes : - Une réponse d'erreur d'autorité indiquant que le nom n'existe pas.
- Une indication temporaire d'erreur.
- Une combinaison :
- de RR qui répondent à la question, en indiquant si les données sont extraites d'une zone ou d'une antémémoire.
- d'un point de référence à des serveurs de noms qui sont des plus proches ancêtres du nom demandé que le serveur qui envoie la réponse.
- Les RR que le serveur de nom pense être utiles au demandeur pour continuer sa recherche.
4.3.2 Algorithme
L'algorithme réel utilisé par le serveur de noms va dépendre du système d'exploitation local et des structures de données utilisées pour mémoriser les RR. L'algorithme suivant suppose que les RR sont organisés en plusieurs structures d'arborescence, une pour chaque zone, et une autre pour l'antémémoire :
1. Mettre à 1 ou zéro la valeur de "récurrence admissible" (RA) dans la réponse suivant que le serveur de noms souhaite proposer le service récurrent ou non. Si le service récurrent est disponible et demandé par le bit RD dans l'interrogation, passer à l'étape 5, autrement continuer à l'étape 2.
2. Chercher dans les zones disponibles celle qui est l'ancêtre le plus proche du QNAME. Si une telle zone existe, aller à l'étape 3, sinon sauter à l'étape 4.
3. Commencer la recherche dans la zone, étiquette par étiquette. Le processus de confrontation peut s'achever de plusieurs manières :
a. Si le nom QNAME est trouvé entièrement, le nœud a été trouvé.
Si les données au nœud sont un CNAME, et si le QTYPE ne correspond pas au CNAME, copier le RR CNAME dans la section "réponse" de la réponse, changer le QNAME en le nom canonique dans le RR CNAME, et retourner à l'étape 1.
Autrement, copier tous les RR qui correspondent au QTYPE dans la section "réponse" et passer à l'étape 6.
b. Si une correspondance nous amènerait hors des données d'autorité, il s'agit d'un point de référence. Ceci arrive quand on rencontre un nœud contenant des RR NS qui marquent des coupures le long d'un fond de zone.
Copier les RR NS pour la sous-zone dans la section Autorité de la réponse. Mettre toute adresse disponible dans la section additionnelle, en utilisant des RR "glu" si ces adresses ne sont pas disponibles à partir des données d'autorité ou de l'antémémoire. Passer à l'étape 4.
c. Si pour une étiquette du nom, aucune correspondance n'est possible (c'est-à-dire, l'étiquette correspondante n'existe pas) voir si une étiquette "*" existe.
Si l'étiquette "*" n'existe pas, vérifier si le nom qu'on cherche est le QNAME original de l'interrogation ou un nom suivi à cause d'un CNAME. Si le nom est l'original, établir une réponse d'erreur d'autorité et sortir. Sinon on sort de l'algorithme sans autre action.
Si l'étiquette "*" existe, confronter les RR de ce nœud au QTYPE. Si il y a correspondance, les copier dans la section "réponse", mais en requalifiant le propriétaire des RR comme étant QNAME, et non celui du RR contenant l'étiquette "*". Passer en 6.
4. Commencer la recherche dans l'antémémoire. Si le QNAME y est trouvé, copier dans la section "réponse" tous les RR qui y sont rattachés et dont le QTYPE est conforme. Si il n'y avait pas de délégation de la part de données d'autorité, chercher dans l'antémémoire les meilleures, et les placer dans la section Autorité. Passer à l'étape 6.
5. En utilisant le résolveur local ou une copie de son algorithme (voir la section "Résolveur" du présent mémoire) pour répondre à l'interrogation. Mémoriser les résultats, y compris tout CNAME intermédiaire, dans la section réponse de la réponse.
6. En utilisant seulenent les données locales, tenter d'ajouter d'autres RR qui pourraient être utiles dans la section additionnelle de la réponse et sortir.
4.3.3 Caractères génériques
Dans l'algorithme précédant, un traitement spécial a été fait sur les RR dont le nom de propriétaire commence par l'étiquette
"*". De tels RR sont appelés "enregistrements génériques". Les enregistrements génériques peuvent être vus comme des instructions pour des RR de synthèse. Lorsque les conditions appropriées sont remplies, le serveur de noms crée des RR dont le nom de propriétaire est égal au nom d'interrogation et contenu récupérés des RR génériques.
Cette facilité est très souvent utilisée pour créer une zone qui sera utilisée à transmettre des messages de l'Internet vers d'autres systèmes de messagerie. L'idée générale est que tout nom dans cette zone qui est présenté au serveur dans une interrogation sera supposé exister, doté de certaines propriétés, sauf si une évidence explicite conduit à l'affirmation du contraire. Noter que l'utilisation du terme zone dans ce cas, plutôt que domaine, est intentionnel ; un tel usage "par défaut"
ne se propage pas au delà d'une limite de zone, bien qu'une sous-zone puisse elle aussi présenter ce fonctionnement en mettant en place un usage par défaut similaire.
Le contenu des RR génériques suit les règles et formats usuels des RR. Les enregistrements génériques dans une zone ont un nom de propriétaire qui contrôle les noms d'interrogation auxquels ils vont correspondre. Le nom de propriétaire des RR génériques est de la forme "*. <toutdomaine> ", où <toutdomaine> est n'importe quel nom de domaine. <toutdomaine> ne devrait pas contenir d'autre étiquette "*", et devrait être dans les données d'autorité de la zone. Les enregistrements génériques s'appliquent potentiellement aux descendants de <toutdomaine>, mais pas à <toutdomaine> lui-même. Une autre façon de voir cela est que l'étiquette "*" correspond toujours à au moins une étiquette complète ou parfois plus, mais jamais à toutes les étiquettes.
Les RR génériques ne s'appliquent pas :
- Lorsque l'interrogation porte sur une autre zone. C'est-à-dire que la délégation de gestion annule les enregistrements génériques par défaut.
- Lorsque le nom d'interrogation d'un nom entre le domaine générique et le nom d'interrogation est connu pour exister.
Par exemple, si un RR générique a un nom de propriétaire de "*.X", et si la zone contient aussi des RR rattachés à B.X, les enregistrements génériques s'appliqueraient à des interrogations sur le nom Z.X (à supposer qu'aucune information explicite n'existe pour Z.X) mais pas à B.X, à A.B.X, ni à X.
Une étiquette "*" apparaissant dans un nom d'interrogation n'a pas d'effet particulier, mais peut être utilisée pour vérifier les enregistrements génériques dans une zone d'autorité ; une telle interrogation est la seule manière d'obtenir une réponse contenant des RR avec un nom de propriétaire incluant un "*". Le résultat de telles interrogations ne devra pas être mis en antémémoire.
On note que le contenu des RR génériques n'est pas modifié lorsque ils sont utilisés pour synthétiser des RR.
Pour illustrer l'usage des RR génériques, on suppose qu'une grande société disposant d'un réseau étendu, non fondé sur TCP/IP, désire créer une passerelle de messagerie. Si la compagnie s'appelle X.COM, et la passerelle vers TCP/IP, A.X.COM, les RR suivants pourraient être entrés dans la zone COM :
X.COM MX 10 A.X.COM *.X.COM MX 10 A.X.COM A.X.COM A 1.2.3.4
A.X.COM MX 10 A.X.COM *.A.X.COM MX 10 A.X.COM
Cela aurait pour résultat que toute interrogation de type MX pour tout domaine se terminant par X.COM retournera un RR MX pointant sur A.X.COM. Pour obtenir cet effet, deux RR génériques sont nécessaires car l'effet du RR générique à
*.X.COM est inhibé dans la sous arborescence A.X.COM par les données explicites pour A.X.COM. On note de plus que les données MX explicites pour X.COM et A.X.COM sont exigées, et qu'aucun des RR ci-dessus ne corespond à un nom d'interrogation de XX.COM.
4.3.4 Mise en antémémoire de réponse négative (facultatif)
Le DNS définit un service facultatif qui permet aux serveurs de nom de distribuer, et aux résolveurs de mémoriser en antémémoire, les résultats négatifs avec des TTL. Par exemple, un serveur de noms peut distribuer un TTL associé à une indication d'erreur de nom et un résolveur qui reçoit de telles informations peut en déduire que le nom demandé n'existe pas pendant la période du TTL sans être obligé de consulter des données d'autorité. De même, un résolveur peut émettre une interrogation avec un QTYPE qui correspond à plusieurs types, et conserver dans l'antémémoire le fait que certains des types ne sont pas présents.
Cette caractéristique peut être particulièrement importante dans un système mettant en œuvre des raccourcis de dénomination qui utilisent des listes de recherche parce que c'est un raccourci populaire qui se trouve exiger un suffixe vers la fin de la liste de recherche, qui va générer de multiples erreurs de noms chaque fois qu'il est utilisé.
La méthode est qu'un serveur de noms peut ajouter un RR SOA dans la section additionnelle d'une réponse lorsque celle-ci est d'autorité. Le SOA doit être celui de la zone qui était la source des données d'autorité dans la section réponse, ou d'une erreur de nom si applicable. Le champ MINIMUM de l'enregistrement SOA contrôle le temps pendant lequel la réponse négative peut être gardée dans l'antémémoire.
