RFC 1034 : DNSRFC 1034 : Serveur de noms de domaines ...

RFC 1034 Serveur de noms de domaines : Concepts de base MockapetrisSTD 13

Groupe de travail Réseau P. Mockapetris, ISI RFC 1034 novembre 1987RFC rendues obsolètes : RFC882, RFC883, RFC973 version FR : avril 1998Statut : Norme Traduction : Valéry G. FREMAUX

Serveur de noms de domaines : Concepts de base

Table des matières

1. Statut de ce mémoire..............................................................................................................................................................12. Introduction............................................................................................................................................................................2

2.1 Historique des noms de domaines..................................................................................................................................22.2 Objectifs de la conception du DNS................................................................................................................................22.3 Hypothèses d''utilisation.................................................................................................................................................32.4 Éléments du DNS...........................................................................................................................................................4

3. Espace de noms de domaines et enregistrements de ressourcex............................................................................................53.1 Spécifications et terminologie des noms de domaines...................................................................................................53.2 Lignes directrices administratives sur l'utilisation..........................................................................................................63.3 Conseils techniques d'utilisation.....................................................................................................................................63.4 Exemple d'espace de noms.............................................................................................................................................63.5 Syntaxe préférentielle pour les noms..............................................................................................................................73.6 Enregistrements de ressource.........................................................................................................................................83.7 Interrogations................................................................................................................................................................103.7.1 Interrogations standard..............................................................................................................................................103.8 Interrogations d'état (expérimental)..............................................................................................................................123.9. Interrogations de fin de traitement (obsolète)..............................................................................................................12

4. Serveurs de noms de domaine..............................................................................................................................................124.1 Introduction..................................................................................................................................................................124.2 Comment la base de données est divisée en zones.......................................................................................................124.2.2 Considérations d'administration................................................................................................................................134.3 Serveur de noms - spécifications internes....................................................................................................................14

5. Résolveurs............................................................................................................................................................................185.1 Introduction..................................................................................................................................................................185.2 Interface résolveur-client..............................................................................................................................................185.3 Résolveurs - spécifications internes..............................................................................................................................195.3.3 Algorithme.................................................................................................................................................................20

6. Scénario................................................................................................................................................................................226.1 Serveur de nom C.ISI.EDU..........................................................................................................................................226.2 Exemple d'interrogations standard................................................................................................................................246.3 Exemple de résolution..................................................................................................................................................28

7. Références et bibliographie..................................................................................................................................................31Index.........................................................................................................................................................................................32

1. Statut de ce mémoireCette RFC est une introduction au système de noms de domaines (DNS, Domain Name System) et passe sous silence denombreux détails qui pourront être trouvés dans une RFC complémentaire, "Noms de domaines - mise en œuvre etspécification" [RFC1035]. Cette dernière suppose que le lecteur est déjà familiarisé avec les concepts énoncés dans laprésente. Un sous-ensemble des fonctions DNS et des types de données associés constitue un protocole officiel. Leprotocole officiel comprend la définition des interrogations standard et des réponses qui y sont faites ainsi que la plupartdes formats de classes de données Internet (par exemple, adresses d'hôtes). Cependant, le système de domaines estintentionnellement extensible. Les chercheurs proposent continuellement, mettent en œuvre et expérimentent de nouveauxtypes de données, types d'interrogations, classes, fonctions, etc. De ce fait, alors que les constituants du protocole officielsont supposés rester stables et pouvoir être utilisés en exploitation, des comportements expérimentaux pourront êtreobservés au delà des limites de la définition officielle. Les RFC concernées mentionnent clairement les fonctionsexpé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

page - 1 -


mesure où leur utilisation n'est faite que dans un but pédagogique. La distribution de ce mémoire n'est soumise à aucunerestriction.

2. IntroductionCette RFC expose les styles admis pour les noms de domaines, leur utilisation dans le cadre de la messagerie par Internet etpour 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 ceschéma est proportionnelle au carré du nombre d'hôtes dans le réseau, et même lorsque plusieurs niveaux deretransmissions FTP étaient utilisés, la charge de trafic FTP sortant de l'hôte du NIC restait considérable. La croissanceexplosive 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 constituaientl'ARPANET originel ont été remplacés par des réseaux locaux de stations de travail. Les organismes locaux ontcommencé à administrer leurs propres noms et adresses, mais devaient attendre que le NIC reporte les changementsdans le fichier HOSTS.TXT pour que ceux-ci soient visibles de l'ensemble de la communauté Internet. Lesorganisations 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 plusgé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 nomshiérarchisé, dont le principe hiérarchique correspondrait en gros à la structure des organisations, et où les noms utiliseraientle caractère "." pour marquer la frontière entre les niveaux hiérarchiques. Un concept mettant en œuvre une base dedonnées distribuée et des ressources généralisées a été décrit dans les [RFC0882], [RFC0883]. Sur la base de l'expériencede 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èssouvent, le terme "nom de domaine" est utilisé pour se référer à un nom qui a une structure indiquée par des points, maissans 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 lesproblè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, avecantémémoire locale pour améliorer les performances. Les approches qui tenteraient d'obtenir une copie cohérente de labase de donnée entière seront de plus en plus coûteuses et difficiles, et donc devraient évitées. Le même principe tientpour la structure de l'espace de noms, et en particulier les mécanismes pour créer et supprimer les noms ; ceux-cidevraient ê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é desanté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 à uneapplication particulière. On devrait être capable d'utiliser les noms pour restituer les adresses des hôtes, les données desboîtes aux lettres, et d'autres informations non encore identifiées. Toutes les données associées à un nom sont étiquetéesavec 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, nousfournissons la capacité d'utiliser le même espace de noms avec différentes familles ou systèmes de gestion deprotocoles. Par exemple, les formats d'adresse d'hôte diffèrent selon les protocoles, bien que tous les protocoles utilisent

page - 2 -


la notion d'adresse. Le DNS marque toutes les données avec une classe ainsi qu'un type, ce qui peut permettre uneutilisation 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 établirseulement des circuits virtuels pour les transactions qui nécessitent une certaine fiabilité (par exemple, la mise à jour desbases 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 grandshô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 lacommunauté utilisatrice, et est conçue de sorte à éviter un grand nombre de problèmes compliqués des systèmes de base dedonné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 autresinformations 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îtesaux lettres, les adresses d'hôtes) mais le système devrait être capable de traiter des sous ensembles de donnéesné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éralementcorrespondre aux organisations qui ont un ou plusieurs hôtes. Chaque organisation ayant la responsabilité d'un ensemblede domaines particulier devra mettre en œuvre plusieurs serveurs de domaines redondants, sur l'hôte même del'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'ilspréfèrent utiliser avant d'accepter des points de référence à des serveurs de noms en dehors de cet ensemble "deconfiance".

- L'accès aux informations est plus critique que la mise à jour instantanée et la garantie de cohérence. De ce fait leprocessus de mise à jour permet que la mise à jour diffuse à travers les utilisateurs du système des domaines plutôt quede 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 enpoursuivant les efforts pour les mettre à jour. Le modèle général est que les copies sont distribuées avec destemporisations de rafraîchissement. Le distributeur règle la valeur de la temporisation et le receveur de la distributionest 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 desinterrogations auxquelles seuls d'autres serveurs peuvent répondre. Les deux approches principales pour traiter leproblème sont soit la méthode "récurrente", par laquelle le premier serveur fait suivre l'interrogation à un autre serveurpour le compte du client, soit la méthode "itérative", par laquelle le serveur renvoie le client sur un autre serveur et lelaisse poursuivre l'interrogation. Les deux approches ont leurs avantages et inconvénients, mais l'approche itérative restetoutefois 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 quiutilisent le système des domaines. Ces fichiers maîtres sont mis à jour par les administrateurs de système local. Les fichiersmaîtres sont des fichiers texte lus par un serveur de noms local, et qui deviennent donc accessibles à tous les utilisateurs dusystème de domaines par l'intermédiaire des serveurs de noms. Les programmes d'utilisateur accèdent à ces serveurs denoms 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 autremécanisme) ; cette facilité est utile lorsque un organisme désire un domaine, mais ne souhaite pas prendre en charge unserveur de domaines. L'organisme pourra maintenir localement les fichiers maîtres avec un éditeur de texte, puis lestransférer sur un hôte déporté sur lequel sont exécutés les serveurs de noms, puis voir avec l'administrateur système duserveur 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]. Pourun serveur de noms, ces données de configuration incluent l'identité des fichiers maîtres locaux ainsi que des instructionspour savoir quels fichiers maîtres non locaux doivent être chargés à partir de serveurs distants. Le serveur de noms utilise

page - 3 -


les fichiers maîtres ou des copies pour charger ses zones. Pour les résolveurs, les données de configuration identifient lesserveurs 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 lesrafraî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 nomsdistants.

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'unespace de noms structuré en arborescence et les données associées à ces noms. Conceptuellement, chaque nœud et chaquefeuille de l'arborescence de l'espace de noms de domaines désigne un ensemble d'informations et les interrogations sont destentatives pour extraire des types spécifiques d'informations d'un certain ensemble. Une interrogation désigne le nom dudomaine qui l'intéresse et décrit le type d'informations de ressource désiré. Par exemple, l'Internet utilise certains de sesnoms de domaines pour identifier des hôtes ; des interrogations sur des ressources d'adresses renveront les adresses d'hôtesInternet.

Les SERVEURS DE NOM sont des programmes serveurs qui détiennent les informations sur la structure de l'arborescencedes 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 informationscomplètes sur un sous ensemble de l'espace des domaines, et des pointeurs sur d'autres serveurs de noms qui peuvent êtreutilisés pour conduire aux informations de toutes les parties de l'arborescence des domaines. Les serveurs de nomsconnaissent les parties de l'arborescence des domaines pour lesquelles ils détiennent une information complète ; un serveurde noms est dit être une AUTORITÉ pour ces parties de l'espace de noms. Les informations d'autorité sont organisées enunités appelées ZONES, ces zones pouvant être automatiquement réparties aux serveurs de noms qui fournissent un serviceredondant 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 demandesdes clients. Les résolveurs doivent pouvoir accéder à au moins un serveur de noms et utiliser les informations de ce serveurde noms pour donner directement une réponse, ou poursuivre l'interrogation en utilisant les points de référence à d'autresserveurs de noms. Un résolveur sera normalement un sous programme du système qui est directement accessible par unprogramme 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 desinformations 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 leré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 localesappelés zones. Le serveur de noms a des copies locales de certaines des zones. Le serveur de noms doit rafraîchirpériodiquement ses zones à partir de copies maîtresses des fichiers locaux ou des serveurs de noms distants. Lesserveurs 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êmemachine qu'un serveur de noms pourrait partager une base de données accueillant les zones gérées par le serveur de nom etl'antémémoire gérée par le résolveur.

page - 4 -


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 à unensemble de ressources (qui peut être vide). Le système des domaines ne fait aucune distinction entre l'utilisation desnœ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 del'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 laracine).

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 parla racine, laquelle a une chaîne de longueur nulle comme étiquette, ces représentations internes peuvent utiliser un octet delongueur 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 dedomaines pour toutes les fonctions actuelles des domaines sont faites indépendamment de la casse, en supposant l'usage dujeu 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œudd'étiquette "A" ou encore "a", mais pas les deux en tant que frères l'un de l'autre ; ces deux domaines pourront êtreréférencés par "a" ou "A" indistinctement. Cependant, lorsque on reçoit un nom de domaine ou une étiquette, il faut enpré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 pouvoirrester inchangés.

Lorsqu'un utilisateur doit entrer un nom de domaine, la longueur de chaque étiquette est omise et les étiquettes sontséparées par des points ("."). Un nom de domaine complet se terminant toujours par la racine, la forme écrite exacte de toutdomaine 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éecomme liste de recherche. Les noms relatifs apparaissent le plus souvent au niveau de l'interface utilisateur, où leurinterprétation varie d'une mise en œuvre à l'autre, ainsi que dans les fichiers maîtres, où il se rapportent à un nom dedomaine d'une seule origine. L'interprétation la plus courante utilise la racine "." soit comme seule origine, soit comme l'undes 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 detous 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 auniveau et en dessous du nom de domaine qui spécifie le domaine. Un domaine est un sous domaine d'un autre domaine s'ilest contenu au sein de ce domaine. Cette relation peut être vérifiée en regardant si le nom du sous domaine se termine par lenom du domaine le contenant. Par exemple, A.B.C.D est un sous-domaine de B.C.D, C.D, D, et "".

page - 5 -


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 derègles pour le choix des étiquettes ; leur but est d'être les plus générales possible, afin qu'elles puissent servir à toutes sortesd'applications. En particulier, le système a été conçu de sorte que l'espace de noms n'ait pas à suivre les limites physiquesde 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 unesémantique, mais plutôt que le choix d'une sémantique implicite devrait rester ouvert pour pouvoir s'adapter aux problèmesparticuliers lorsqu'ils se présentent, et qu'il reste acceptable que certaines sous parties de l'arborescence puissent user desémantiques différentes. Par exemple, le domaine IN-ADDR.ARPA est organisé et distribué en réseaux et adresses d'hôtescar son rôle est de traduire des numéros de réseau ou d'hôtes en noms ; les domaines NetBIOS [RFC1001[, [RFC1002] sontdes 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 leshôtes, boîtes aux lettres, etc., qui rendront l'espace de noms plus uniforme, préserveront sa capacité de croissance, etminimiseront les problèmes lorsque des logiciels sont convertis à partir du tableau ancien. Les décisions de politiques surles niveaux supérieurs de l'arborescence ont été prises dans la [RFC0920]. La politique actuelle pour les niveaux supérieursest 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 desembranchements au sommet du domaine de telle sorte que d'éventuelles décompositions puissent se faire sans changementde noms. Les étiquettes de nœuds utilisant des caractères spéciaux, des chiffres en tête, etc., risquent de poser desproblè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 formatsexistants et doit planifier une compatibilité ascendante pour les utilisations actuelles. Plusieurs conversions et niveaux deconversion 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 larepré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 lesnoms 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 nomde domaine conforme au format de texte usuel pour les noms de domaine (des points séparant les étiquettes) et à enchaînerles deux parties pour former un nom de domaine unique. Ainsi, la boîte aux lettres [email protected] estreprésentée comme nom de domaine par HOSTMASTER.SRI-NIC.ARPA. L'appréciation des raisons conduisant à cedessin 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ésultentde nombreux compromis entre des contraintes de compatibilité ascendante pour d'anciennes applications toujours enservice, des interactions entre les différentes définitions d'objets, et l'incontournable urgence qu'il y a à développer denouvelles fonctionnalités lorsque de nouvelles règles sont établies. La manière dont le DNS est exploité pour prendre encompte 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 nombreusesreprises dans cette RFC. Notez que cette arborescence est un tout petit sous ensemble de l'espace des noms de domainesréel.

page - 6 -


| | +---------------------+------------------+ | | | 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.EDUa 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 desnoms de domaines. L'idée est que le nom de tout objet existant puisse être exprimé comme un nom de domaine avec leminimum de changements. Cependant, au moment d'assigner un nom de domaine à un objet, l'utilisateur prudent choisiraun nom qui d'une part respecte les règles du système de domaines et d'autre part respecte toutes les règles existantes pourl'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 quecelles établies par la [RFC0822]. Quand on crée un nouveau nom dhôte, les anciennes règles instaurées pour HOSTS.TXTdevraient être suivies. Cela permet d'éviter des problèmes lorsque d'anciens programmes sont transformés pour prendre encompte les noms de domaine.

La syntaxe suivante diminuera le risque de problèmes avec beaucoup d'applications qui utilisent les noms de domaine (parexemple, 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, aucunesignification n'est accordée à la casse. C'est-à-dire, deux noms lexicographiquement identiques, mais écrits dans une cassediffé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, seterminer par une lettre ou un chiffre, et n'avoir à l'intérieur que des lettres, des chiffres, et éventuellement le caractère traitd'union (-). Il y a aussi quelques restrictions sur la longueur. Une étiquette doit avoir au plus 63 caractères.

page - 7 -


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, lequelpeut être vide. L'ensemble d'informations de ressources associé à un nom particulier est composé d'enregistrements deressources (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 lesserveurs 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ôteCNAME le nom canonique d'un aliasHINFO le CPU et le système d'exploitation (OS) d'un hôteMX 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 domainePTR un pointeur vers une autre partie de l'espace de noms de domainesSOA 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 InternetCH 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é parles résolveurs lorsqu'ils mettent leurs RR en antémémoire. Le TTL décrit combien de temps un RR peut êtreconservé 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, denombreux 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 tousles 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, maisdéfinie par la politique de rafraîchissement de la zone. La TTL est définie par l'administrateur pour la zone d'où provient cetenregistrement. Alors qu'une valeur faible de TTL peut être utilisée pour diminuer la durée en antémémoire, et qu'unevaleur 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éduiteavant 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 dedomaines. Les noms de domaines sont souvent utilisés comme "pointeurs" sur d'autres données du DNS.

page - 8 -


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 uneforme fortement compactée lorsque stockés par un serveur de noms ou un résolveur. Dans ce document, nous adoptons unstyle similaire à celui utilisé dans les fichiers maîtres afin de montrer le contenu des RR. Dans ce format, la plupart des RRsont 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 del'enregistrement est supposé être le même que celui du RR précédent. Des lignes vides sont souvent insérées pouraugmenter 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 dutype et de la classe sont disjoints, les TTL sont des entiers, et le mnémonique de type est toujours en dernier. La classe INet 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 normalepour 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.52VAXA.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 RRutilise 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îtesaux lettres, de nombreuses organisations fournissent de nombreux noms qui pointent sur la même boîte aux lettres ; parexemple [email protected], [email protected], et [email protected] 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 nomprincipal, 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 RRCNAME identifie son nom de propriétaire comme étant un alias, et spécifie le nom canonique correspondant dans lasection RDATA du RR. Si un RR CNAME est présent dans un nœud, aucune autre donnée ne devrait y être présente ; cetterestriction garantit que les données pour un nom canonique et ses alias ne peuvent pas être différents. Cette règle assure deplus 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

page - 9 -


ressources consiste en un enregistrement CNAME avec une classe correspondante. Si c'est le cas, le serveur de noms inclutl'enregistrement CNAME dans la réponse et recommence l'interrogation au nom de domaine spécifié dans le champDonnées de l'enregistrement CNAME. La seule exception à cette règle est que les interrogations qui corrrespondent au typeCNAME ne sont pas recommencées.

Par exemple, supposons qu'un serveur de noms traite une interrogation sur le domaine USC-ISIC.ARPA, pour un typed'information A, et dispose des enregistrements de ressource suivants :

USC-ISIC.ARPA IN CNAME C.ISI.EDUC.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 typeCNAME 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 unalias. Ceci évitera une multiplication inutile des informations d'accès. Par exemple, l'adresse pour désignr les RR pourl'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 devraientpas échouer face à des chaînes ou des boucles de CNAME. Les enchaînements de CNAME devraient être suivis et lesboucles 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. Dansl'Internet, les interrogations sont portées dans des datagrammes UDP ou sur des connexions TCP. La réponse du serveur denom peut répondre à la question posée par l'interrogation, renvoyer le demandeur vers un autre ensemble de serveurs denoms, 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 à sontour envoie une ou plusieurs interrogations à des serveurs de noms et traite les conditions d'erreur ou les points de référencequi peuvent en résulter. Bien sûr, les questions possibles qui peuvent être posées dans une interrogation doiventcorrespondre 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ètresd'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érentesinterrogations. 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 restantnon 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 classed'interrogation (QCLASS) et appelle les RR qui correspondent. Ce type d'interrogation représente une telle majorité desinterrogations 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.

page - 10 -


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 quicorrespondent. En plus des enregistrements pertinents, le serveur de noms peut retourner des RR pointant vers un serveurde noms qui détient les informations désirées ou des RR qui pourraient aider à l'interprétation des RR pertinents. Parexemple, un serveur de noms qui ne dispose pas des informations demandées peut connaître un autre serveur de nom quiles détient ; un serveur de noms qui retourne un nom de domaine dans un RR pertinent peut aussi retourner le RR qui lie cenom de domaine à une adresse.

Par exemple, un agent de courrier tentant d'envoyer un message dans la boîte aux lettres [email protected] peutdemander à son résolveur des informations sur le serveur de courrier de ISI.EDU, résultant en une interrogation surQNAME=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.33VENERA.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 probablementobtenir 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 mesureoù un serveur de noms ne connaît pas nécessairement toutes les classes disponibles dans le système de domaines, il ne peutjamais 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 enun ou des noms de domaine qui ont cette ressource. Par exemple, alors qu'une interrogation standard peut tranposer un nomde 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 nomsdoivent au moins être capables de comprendre un message d'interrogation inverse et de retourner une réponse d'erreur "nonmis en œuvre". Le système des domaines ne peut pas garantir la complétude ou l'unicité des interrogations inverses parceque le système des domaines est organisé par noms de domaines, et non sur l'adresse d'hôte ou autre type de ressource. Lesinterrogations 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é faitpartie d'un ensemble (par exemple, une adresse d'un hôte disposant de plusieurs adresses). De ce fait, les RR retournés pardes 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 ; ilfaut plutôt utiliser le domaine IN-ADDR.ARPA. Une discussion détaillée sur les interrogations inverses se trouve dans la[RFC1035].

page - 11 -


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 typecomplètement rénové sera peut être rétabli à l'avenir, ou bien les codes d'opération réservés pour cette anciennefonctionnalité 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 dedonnées est divisée en sections appelées zones, qui sont réparties entre les serveurs de noms. Comme les serveurs de nomspeuvent avoir plusieurs fonctions et sources de données facultatives, la tâche essentielle d'un serveur de noms est derépondre aux interrogations en utilisant les données qui sont dans ses zones. Par conception, les serveurs de noms peuventrépondre à ces interrogations d'une manière simple ; la réponse peut toujours être générée à partir des seules donnéeslocales, 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 casde défaillance du serveur ou des liaisons de communication. Par décision "administrative", on impose que toute zone soitaccessible 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 desinformations 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 sesréponses aux interrogations de telle sorte que le demandeur puisse dire si les informations proviennent de donnéesd'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 desnoms 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 detoutes les autres classes. Comme par convention, l'espace de noms est le même pour toutes les classes, la séparation parclasse peut être vue comme une matrice d'arborescences de noms parallèles. Noter que les données attachées aux nœuds desarborescences seront différentes pour ces différentes classes parallèles. Les raisons les plus courantes pour créer unenouvelle 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éesé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. Unefois 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 quetous les nœuds d'une zone particulière sont connectés. Du fait de la structure arborescente, chaque zone a un nœud de plushaut 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 domainese 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, labase de données est partitionnée aux points où une organisation particulière accepte de gérer la sous arborescence inférieureau point de coupure. Une fois qu'une organisation contrôle sa propre zone, elle peut modifier les données dans cette zone defaçon unilatérale, créer des nouvelles sous arborescences à l'intérieur de la zone, supprimer des nœuds existants, oudéléguer la gestion de nouvelles sous zones à d'autres organisations plus locales.

page - 12 -


Si l'organisation a elle même une sous structure, elle peut souhaiter créer des partitions internes pour réaliser desdélégations incorporées du contrôle de l'espace de noms. Dans certains cas, de telles divisions ne sont faites que pourrendre 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 ensemblede 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 unerepré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 dela zone jusqu'aux nœuds feuilles les plus bas, ou aux nœuds immédiatement au-dessus d'un point de coupure autour du bordinfé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 importancetoute 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 lazone.

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éesd'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 desnœ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œudsupé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 jamaisentre.

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 zonesparentes disposent de toutes les informations requises pour accéder aux serveurs de leurs zones filles. Les RR NS quidésignent ces serveurs pour les sous-zones ne suffisent pas toujours à cette tâche car si ils désignent le serveur, ils n'endonnent pas l'adresse. En particulier, si le nom du serveur de noms est lui-même dans la sous-zone, on pourrait êtreconfronté à la situation où le RR NS nous dit que pour connaître l'adresse d'un serveur de noms, on devrait contacter leserveur 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écessairesque 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 deré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, etobtenir des "propriétaires" de la zone parente un accord sur la délégation de contrôle. Bien qu'il n'y ait aucune contraintetechnique particulière qui détermine où dans l'arborescence cela peut être effectué, certains regroupements administratifssont exposés dans la [RFC1032] concernant l'organisation des niveaux supérieurs, les zones médianes restant libres de créerleurs propres règles. Par exemple, une université pourrait choisir de n'utiliser qu'une seule zone, tandis qu'une autre pourraitchoisir de s'organiser en sous-zones, dédiées chacune à un département ou une école. La [RFC1033] fait un catalogue deslogiciels 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 leurcapacité à prendre en charge des serveurs de domaines redondants. Noter qu'il n'y a pas d'obligation que les serveurs pour

page - 13 -


une zone soient implantés sur une machine disposant d'un nom dans ce domaine. Dans de nombreux cas, une zone sera plusaccessible à l'Internet au sens large si les serveurs qui la gèrent sont répartis, plutôt que concentrés sur le site physiquecontrô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éspar 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 ladé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 sonttoutes 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'interrogationen utilisant seulement ses informations locales : la réponse contient une erreur, la réponse demandée, ou un point deréférence à un autre serveur plus "proche" de la réponse. Tous les serveurs de noms doivent mettre en œuvre lesinterrogations 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ésolveuret retourne soit un message d'erreur, soit une réponse valide, mais jamais de point de référence. Ce service est facultatifdans 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 lesinformations 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 estné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, lebit 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 serviceré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 desserveurs qui auront donné leur accord pour ce service par un accord privé ou tout autre moyen hors du champ duprotocole DNS.

Le mode récurrent se produit lorsqu'une interrogation arrive avec un bit RD établi sur un serveur qui accepte de fournir leservice 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 dedonné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.

page - 14 -


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éesutilisées pour mémoriser les RR. L'algorithme suivant suppose que les RR sont organisés en plusieurs structuresd'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 plusieursmaniè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 CNAMEdans la section "réponse" de la réponse, changer le QNAME en le nom canonique dans le RR CNAME, etretourner à 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 arrivequand 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 lasection additionnelle, en utilisant des RR "glu" si ces adresses ne sont pas disponibles à partir des donnéesd'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'existepas) 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 nomsuivi à cause d'un CNAME. Si le nom est l'original, établir une réponse d'erreur d'autorité et sortir. Sinon on sortde 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 lasection "réponse", mais en requalifiant le propriétaire des RR comme étant QNAME, et non celui du RR contenantl'é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 RRqui 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) pourrépondre à l'interrogation. Mémoriser les résultats, y compris tout CNAME intermédiaire, dans la section réponse de laréponse.

6. En utilisant seulenent les données locales, tenter d'ajouter d'autres RR qui pourraient être utiles dans la sectionadditionnelle 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 desinstructions pour des RR de synthèse. Lorsque les conditions appropriées sont remplies, le serveur de noms crée des RRdont 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 versd'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 uneinterrogation sera supposé exister, doté de certaines propriétés, sauf si une évidence explicite conduit à l'affirmation ducontraire. Noter que l'utilisation du terme zone dans ce cas, plutôt que domaine, est intentionnel ; un tel usage "par défaut"

page - 15 -


ne se propage pas au delà d'une limite de zone, bien qu'une sous-zone puisse elle aussi présenter ce fonctionnement enmettant 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 ontun nom de propriétaire qui contrôle les noms d'interrogation auxquels ils vont correspondre. Le nom de propriétaire des RRgénériques est de la forme "*. <toutdomaine> ", où <toutdomaine> est n'importe quel nom de domaine. <toutdomaine> nedevrait pas contenir d'autre étiquette "*", et devrait être dans les données d'autorité de la zone. Les enregistrementsgénériques s'appliquent potentiellement aux descendants de <toutdomaine>, mais pas à <toutdomaine> lui-même. Uneautre façon de voir cela est que l'étiquette "*" correspond toujours à au moins une étiquette complète ou parfois plus, maisjamais à 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 informationexplicite 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 lesenregistrements génériques dans une zone d'autorité ; une telle interrogation est la seule manière d'obtenir une réponsecontenant des RR avec un nom de propriétaire incluant un "*". Le résultat de telles interrogations ne devra pas être mis enanté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é surTCP/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 RRMX 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 queles données MX explicites pour X.COM et A.X.COM sont exigées, et qu'aucun des RR ci-dessus ne corespond à un nomd'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 enantémémoire, les résultats négatifs avec des TTL. Par exemple, un serveur de noms peut distribuer un TTL associé à uneindication d'erreur de nom et un résolveur qui reçoit de telles informations peut en déduire que le nom demandé n'existe paspendant la période du TTL sans être obligé de consulter des données d'autorité. De même, un résolveur peut émettre uneinterrogation avec un QTYPE qui correspond à plusieurs types, et conserver dans l'antémémoire le fait que certains destypes ne sont pas présents.

Cette caractéristique peut être particulièrement importante dans un système mettant en œuvre des raccourcis dedénomination qui utilisent des listes de recherche parce que c'est un raccourci populaire qui se trouve exiger un suffixe versla 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-ciest 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'uneerreur de nom si applicable. Le champ MINIMUM de l'enregistrement SOA contrôle le temps pendant lequel la réponsenégative peut être gardée dans l'antémémoire.

page - 16 -


Noter que dans certaines circonstances, la section réponse peut contenir plusieurs noms de propriétaire. Dans ce cas, lemécanisme de SOA ne devrait être employé que pour les données qui correspondent au QNAME, qui sont les seulesdonnées d'autorité dans cette section.

Les serveurs de noms et les résolveurs ne devraient jamais tenter d'ajouter des SOA dans la section additionnelle d'uneréponse non d'autorité, ni tenter de déduire des résultats qui ne soient pas directement déclarés dans une réponse d'autorité.Il y a à cela plusieurs raisons, dont : les informations en antémémoire ne suffisent pas en général pour la confrontation à desRR et leurs noms de zone, les RR SOA peuvent être mis en antémémoire à cause d'interrogations directe du SOA, et lesserveurs de noms ne sont pas obligés de sortir les SOA dans la section d'autorité.

Cette caractéristique est facultative, bien que l'on puisse s'attendre à ce qu'une version précisée soit incorporée à l'avenirdans le protocole standard. Les serveurs de noms ne sont pas tenus d'ajouter les RR SOA dans toutes leurs réponsesd'autorité, et les résolveurs ne sont pas obligés de mettre les résultats négatifs en antémémoire. Les deux comportementssont recommandés. Tous les résolveurs et serveurs de noms récurrents sont tenus d'être au moins capables d'ignorer le RRSOA lorsqu'il est présent dans une réponse.

Certaines expériences ont également été proposées pour utiliser cette caractéristique. L'idée était que si les données enantémémoire sont connues comme venant d'une certaine zone, et si une copie d'autorité du SOA de la zone est obtenue, etenfin si le SERIAL de la zone n'a pas changé depuis que les données ont été mises dans l'antémémoire, alors la durée de viedes données de l'antémémoire peut être réglée à la valeur MINIMUM de la zone si ce minimum est inférieur. Cet usage estdécrit pour une recherche future, et n'est pas recommandé à présent.

4.3.5 Maintenance et transferts de zone

Une partie du travail d'un administrateur de zone est d'entretenir les zones à chacun des serveurs de noms qui sont d'autoritépour la zone. Lorsque des modifications inévitables sont faites, elles doivent être distribuées à tous les serveurs de noms.Bien que cette distribution des données puisse se faire par FTP ou toute autre procédure ad hoc, la méthode préférée est lapartie transfert de zone du protocole DNS.

Le modèle général d'un transfert ou rafraîchissement de zone automatique est qu'un des serveurs de noms est le maître (ouprincipal) pour la zone. Les modifications sont coordonnées au principal, normalement en éditant un fichier maître pour lazone. Àprès l'édition, l'administrateur ordonne au serveur maître de charger la nouvelle zone. Les autres serveurs nonmaîtres ou secondaires pour cette zone vérifient périodiquement (à un intervalle réglable) les changements et obtiennent descopies de la nouvelle zone quand les changements ont été faits.

Pour détecter les modifications, il suffit aux serveurs secondaires de vérifier le champ SERIAL de l'enregistrement SOApour cette zone. En plus de tous les autres changements apportés dans la zone, le champ SERIAL du SOA de la zone esttoujours incrémenté dès qu'un changement est fait à la zone. Cela peut être un simple incrément, ou peut être fondé surl'écriture de la date et l'heure du fichier maître, etc. Le but est de rendre possible de déterminer laquelle des deux copiesd'une zone est la plus récente en comparant les numéros de série. L'incrémentation et la comparaison des numéros de sérieutilise l'arithmétique d'espace de séquence, et il existe de ce fait une limite théorique sur la fréquence de rafraîchissementd'une zone. Celle-ci peut s'exprimer en disant que les anciennes copies doivent être éliminées avant que le numéro de sérieatteigne la moitié de sa gamme de 32 bits. En pratique, le seul point délicat est de vérifier que l'opération de comparaisontraite correctement les comparaisons autour de la limite entre le plus positif et le plus négatif des nombres de 32 bits.

La consultation périodique des serveurs secondaires est définie par des paramètres dans le RR SOA pour la zone, quirèglent l'intervalle minimum acceptable de consultation. Ces paramètres sont appelés REFRESH, RETRY, et EXPIRE.Chaque fois qu'une nouvelle zone est chargée dans un serveur secondaire, celui-ci attend REFRESH secondes avant devérifier sur le primaire le nouveau numéro de série. Si cette vérification ne peut être effectuée, des nouvelles tentatives sontfaites toutes les RETRY secondes. La vérification est une interrogation simple du principal sur le RR SOA de la zone. Si lechamp numéro de série dans la copie hébergée par le secondaire est égal au numéro de série indiqué dans le RR retournépar le principal, aucun changement n'est intervenu, et l'intervalle d'attente REFRESH est relancé. Si le serveur secondairen'arrive pas à faire une vérification du numéro de série dans l'intervalle EXPIRE, il doit supposer que sa copie de la zoneest obsolète et la supprimer.

Lorsque la consultation montre que la zone a changé, le serveur secondaire doit alors demander un transfert de zone via unedemande AXFR pour la zone. Le AXFR peut causer une erreur, comme "refusé", mais normalement a pour réponse uneséquence de messages de réponse. Les premier et dernier messages doivent contenir les données pour le nœud d'autorité deplus haut niveau dans la zone. Les messages intermédiaires portent tous les autres RR de la zone, incluant les RR d'autorité

page - 17 -


et non d'autorité. Le flux des messages permet au serveur secondaire de construire une copie de la zone. Comme laprécision est essentielle, on doit utiliser TCP ou quelque autre protocole fiable pour les demandes AXFR.

Chaque serveur secondaire est tenu d'effectuer les opérations suivantes à l'égard du maître, mais peut aussi facultativementeffectuer ces opérations à l'égard d'autres serveurs secondaires. Cette stratégie peut améliorer le processus de transfertlorsque le principal est indisponible à cause d'un arrêt de l'hôte ou de problèmes de réseau, ou quand un serveur secondairedispose d'un "meilleur" accès réseau à un serveur secondaire "intermédiaire" qu'au serveur principal.

5. Résolveurs

5.1 Introduction

Les "résolveurs" sont des programmes qui font l'interface entre les applications utilisateur et les serveurs de noms dedomaines. Dans le cas le plus simple, un résolveur reçoit une demande d'un programme d'utilisateur (par exemple,applications de courrier électronique, TELNET, FTP) sous la forme d'un appel de sous programme, d'un appel système,etc., et retoune les informations désirées sous une forme compatible avec les formats de données de l'hôte local.

Le résolveur est situé sur la même machine que le programme qui demande les services du résolveur, mais il peut avoirbesoin de consulter des serveurs de noms de domaines sur d'autres hôtes. Comme un résolveur peut avoir besoin deconsulter plusieurs serveurs de noms, ou peut avoir les informations demandées dans une antémémoire locale, le temps deréponse d'un résolveur est assez variable, de quelques millisecondes à plusieurs secondes.

Un objectif important du résolveur est d'éliminer les délais d'acheminement du réseau et de décharger les serveurs de nomsde la plupart des demandes en y répondant à partir des données en antémémoire des résultats antérieurs. Il en résulte qu'uneantémémoire partagée par plusieurs processus, utilisateurs, machines, etc., sera plus efficace qu'une antémémoire nonpartagée.

5.2 Interface résolveur-client

5.2.1 Fonctions normales

L'interface client au résolveur est influencée par les conventions de l'hôte local, mais l'interface résolveur client normale atrois fonctions :

1. Traduction des noms d'hôtes en adresses d'hôtes.Cette fonction est souvent définie comme imitant une fonction ancienne fondée sur HOSTS.TXT. À partir d'une chaîne decaractères, l'appelant désire obtenir une ou plusieurs adresses IP de 32 bits. Dans le contexte du DNS, cela se traduit en uneinterrogation sur des RR de type A. Comme le DNS ne préserve pas l'ordre des RR, cette fonction peut choisir de trier lesadresses retournées, ou de choisir la "meilleure" adresse si le service retourne seulement un résultat au client. Noter qu'unretour de multiples adresses est recommandé, mais une seule d'adresse peut être la seule solution pour émuler les anciensservices fondés sur HOSTS.TXT.

2. Traduction d'une adresse en nom d'hôte.Cette fonction va souvent suivre la forme de fonctions plus anciennes. À partir d'une adresse IP de 32 bits, le requérantdésire une chaîne de caractères. Les octets de l'adresse IP sont inversés, utilisés comme composants de nom, et avec lesuffixe de "IN-ADDR.ARPA". Une interrogation de type PTR est utilisée pour obtenir le RR qui a le nom principal del'hôte. Par exemple, une interrogation sur le nom d'hôte correspondant à l'adresse IP 1.2.3.4 recherchera des RR PTR pourle nom de domaine "4.3.2.1.IN-ADDR.ARPA".

3. Fonction de recherche générale Cette fonction récupère des informations arbitraires à partir du DNS, et n'a pas de contrepartie dans les systèmes antérieurs.Le requérant fournit un QNAME, QTYPE, et une QCLASS, et désire obtenir tous les RR correspondants. Cette fonction vasouvent utiliser le format DNS pour toutes les données des RR plutôt que celle de l'hôte local, et retournera tous lescontenus de RR (par exemple, le champ TTL) plutôt qu'une forme traitée selon les conventions locales de citation.

Lorsque le résolveur exécute la fonction indiquée, il y a généralement un des résultats suivants à repasser au client : - Un ou plusieurs RR donnant les données demandées. Dans ce cas, le résolveur fournit la réponse dans le format

approprié.

page - 18 -


- Une erreur de nom (NE, name error). Ceci arrive lorsque le nom présenté n'existe pas. Par exemple, un utilisateur peuttrès bien avoir mal orthographié un nom d'hôte.

- Une erreur "données non trouvées". Ceci intervient lorsque le nom demandé existe, mais pas les données pour le typeapproprié. Par exemple, une fonction d'adresse d'hôte appliquée à un nom de boîte aux lettres retournerait cette erreur,car le nom existe, mais aucun RR d'adresse n'est présent.

Il est important de noter que les fonctions de traduction entre des noms d'hôte et des adresses peuvent combiner lesconditions d'erreur "erreur de nom" et "données non trouvées" dans un seul type de retour d'erreur, mais la fonctiongénérale ne le devrait pas. Une raison pour cela est que les applications peuvent dans un premier temps demander un typed'information sur un hôte puis dans une seconde interrogation sur le même nom un autre type d'informations ; si les deuxerreurs sont combinées, des interrogations inutiles peuvent alors ralentir l'application.

5.2.2 Alias

Lorsqu'il essaie de résoudre une interrogation particulière, le résolveur peut s'apercevoir que le nom demandé est un alias.Par exemple, le résolveur s'aperçoit que le nom donné pour un nom d'hôte pour traiter une traduction d'adresse est un aliasalors qu'il trouve le RR CNAME. Si possible, la condition d'alias devrait être signalée du résolveur au client.

Dans la plupart des cas, un résolveur recommence simplement l'interrogation sur le nouveau nom quand il rencontre unCNAME. Cependant, lorsque il effectue la fonction générale, le résolveur ne devrait pas suivre des alias lorsque le RRCNAME correspond au type d'interrogation. Ceci permet les interrogations qui demandent si un alias est présent. Parexemple, si le type d'interrogation est CNAME, l'utilisateur s'intéresse au RR CNAME lui-même, et aux RR au nom surlequel il pointe.

Plusieurs conditions particulières peuvent apparaître avec les alias. Plusieurs niveaux d'alias devraient être évités à cause deleur manque d'efficacité, mais ce ne devrait pas être signalé comme erreur. Les boucles d'alias et les alias pointant sur desnoms inexistants devraint être pris comme une condition d'erreur, laquelle sera rapportée au client.

5.2.3 Défaillances temporaires

Dans un monde imparfait, tous les résolveurs peuvent être occasionnellement dans l'incapacité de résoudre une certainedemande. Cette situation peut être causée par un résolveur qui se trouve séparé du reste du réseau à cause d'une panne deliaison ou d'un problème de passerelle, ou, de façon moins courante dans le cas d'une indisponibilité ou défectionsimultanée de tous les serveurs pour un domaine particulier.

Il est essentiel que cette sorte de condition ne soit pas signalée comme une erreur de nom ou de données non présentes auxapplications. Non seulement ce type d'erreur irrite notablement l'utilisateur humain, mais peut aussi causer de sérieuxproblèmes lorsqu'une messagerie utilise le DNS.

Bien que dans certains cas il soit possible de traiter de tels problèmes temporaires en bloquant indéfiniment l'interrogation,ce n'est généralement pas un bon choix, surtout lorsque le client est un processus serveur qui pourrait passer à d'autrestâches. La solution préconisée est de toujours admettre qu'une erreur "temporaire" puisse être un des résultats possibles del'appel à une fonction de résolution, même si cela peut rendre plus ardue l'émulation des fonctions fondées sur leHOSTS.TXT existant.

5.3 Résolveurs - spécifications internes

Toutes les mises en œuvre de résolveur utilisent des algorithmes légèrement différents, et utilisent normalement plus decode pour traiter les erreurs de toutes sortes plutôt que les occurrences "normales". Cette section expose une stratégie debase recommandée pour le fonctionnement du résolveur, les détails pouvant être trouvés dans la [RFC1035].

5.3.1 Résolveur d'extrémité

Une possibilité pour la mise en œuvre d'un résolveur est de déporter la fonction de résolution au dehors de la machinelocale vers un serveur de noms qui prend en charge les interrogations récurrentes. Ceci constitue une méthode facile pouroffrir le service de noms de domaines dans un PC un peu faible en ressources pour effectuer la fonction de résolveur, oupour centraliser l'antémémoire pour tout un réseau local ou une organisation.

page - 19 -


Tout ce dont le résolveur d'extrémité à besoin est une liste d'adresses de serveurs de noms qui vont effectuer la résolutionrécurrente. Ce type de résolveur aura certainement besoin des informations dans un fichier de configuration, car il n'auraprobablement pas la sophistication suffisante pour les localiser dans la base de données des domaines. L'utilisateur auraaussi besoin de vérifier que les serveurs mentionnés peuvent effectivement fournir le service récurrent ; un serveur de nomsest tout à fait libre de refuser le service récurrent à une partie ou la totalité de ses clients. L'utilisateur devrait consulter sonadministrateur local pour savoir quels sont les serveurs qui acceptent de fournir le service.

Ce type de service comporte un certain nombre d'inconvénients. Comme les interrogations récurrentes peuvent être traitéesdans un temps totalement arbitraire, le résolveur d'extrémité peut éprouver des difficultés à optimiser les intervalles deretransmission pour faire face à la fois aux pertes de paquets UDP et à des serveurs défaillants ; le serveur de noms peutfacilement être débordé par un résolveur d'extrémité un peu trop zélé si il interprète les retransmissions comme desnouvelles interrogations. L'utilisation de TCP peut être une réponse à ce problème, mais TCP peut faire peser la charge surles capacités de l'hôte qui sont similiares à celles d'un résolveur réel.

5.3.2 Ressources

En plus de ses ressources propres, le résolveur peut aussi disposer d'accès partagés à des zones maintenues par un serveurde noms local. Ceci donne au résolveur l'avantage d'un accès plus rapide, mais impose que le résolveur surveille que lesinformations en antémémoire ne viennent pas écraser les données de la zone. Dans cette discussion, le terme "informationslocales" signifie la réunion de l'antémémoire et de telles zones partagées, en comprenant que les données d'autorité sonttoujours utilisées de préférence à toutes données en antémémoire lorsque les deux sont présentes.

L'algorithme de résolution suivant suppose que toutes les fonctions ont été converties en une fonction de recherchegénérale, et utilise les structures de données suivantes pour représenter l'état d'une demande en cours dans le résolveur : SNAME : le nom de domaine sur lequel porte la recherche.STYPE : le QTYPE de la demande de recherche.SCLASS : la QCLASS de la demande de recherche.SLIST : une structure qui décrit les serveurs de noms et la zone que le résolveur essaye actuellement d'interroger. Cette

structure garde la trace des serveurs de noms que le résolveur estime actuellement être les plus susceptibles dedétenir l'information désirée ; cette trace est mise à jour quand les informations qui arrivent au résolveurchangent l'estimation. Cette structure contient l'équivalent d'un nom de zone, les serveurs de noms identifiéspour la zone, les adresses connues des serveurs de noms, et des informations d'historique qui peuvent êtreutilisées pour suggérer quel serveur est probablement le mieux placé pour l'essai suivant. L'équivalent du nomde zone est un compte du nombre d'étiquettes qui correspondent à partir de la racine que SNAME a en communavec la zone objet de l'interrogation ; ceci donne une mesure de la "distance" qui sépare encore le résolveur duSNAME.

SBELT : une structure "ceinture de sécurité" d'une forme identique à SLIST, initialisée à partir d'un fichier deconfiguration, et qui liste les serveurs qui devraient être utilisés lorsque le résolveur ne dispose pasd'informations locales pour guider le choix du serveur de noms. Le décompte de correspondance sera fixé à -1pour indiquer qu'aucune des étiquettes ne correspond.

CACHE : une structure qui enregistre les résultats des précédentes réponses. Comme les résolveurs sont responsables de lapurge des RR dont la durée de vie a expiré (dans l'antémémoire) la plupart des mises en œuvre convertissentl'intervalle spécifié dans les RR qui arrivent en une sorte d'heure "absolue" lorsque le RR est enregistré dansl'antémémoire. Au lieu de décrémenter les TTL individuellement, le résolveur ignore simplement ou supprimeles RR "périmés" lorsqu'il les rencontre au cours d'une recherche, ou encore les supprime lors d'opérationspériodiques de nettoyage pour récupérer la mémoire consommée par les vieux RR.

5.3.3 Algorithme

L'algorithme général contient quatre étapes : 1. Vérifier si la réponse est dans les informations locales, et si c'est le cas, la renvoyer au client.2. Déterminer les "meilleurs" serveurs à contacter. 3. Leur envoyer des interrogations jusqu'à ce que l'un d'eux réponde.4. Analyser la réponse, soit :

a. Si la réponse répond à la question posée, ou stipule une erreur de nom, retourner l'information au client et mettrecette information en antémémémoire.

b. Si la réponse contient une meilleure délégation sur d'autres serveurs, mettre en antémémoire les informations dedélégation, et retourner à l'étape 2.

c. Si la réponse donne un CNAME tout en n'étant pas la réponse attendue, mettre le CNAME en antémémoire,remplacer le SNAME par le nom canonique lu dans le RR CNAME et retourner à l'étape 1.

page - 20 -


d. Si la réponse rend compte d'une défaillance du serveur ou autre cas bizarre, supprimer le serveur de la SLIST etretourner à l'étape 3.

L'étape 1 cherche les données désirées dans l'antémémoire. Si les données y sont trouvées, on suppose qu'elles sontsuffisamment fiables pour une exploitation normale. Certains résolveurs disposent d'une option à l'interface d'utilisateur quiforcera le résolveur à ignorer les données de l'antémémoire et à consulter un serveur d'autorité. Ceci n'est pas recommandépar défaut. Si le résolveur dispose d'un accès direct aux zones d'un serveur de nom, il devrait vérifier si les données désiréesy sont présentes sous forme d'autorité et si c'est le cas, utiliser les données d'autorité de préférence aux données del'antémémoire.

L'étape 2 recherche à quel serveur de nom demander les données recherchées. La stratégie générale est de chercher des RRde serveurs de noms disponibles en local, en partant du SNAME, puis le nom de domaine parent du SNAME, son grandparent, et ainsi de suite vers la racine. Ainsi, si le SNAME était Mockapetris.ISI.EDU, cette étape rechercherait des RR NSpour Mockapetris.ISI.EDU, puis ISI.EDU, puis EDU, et enfin "." (la racine). Ces RR NS donnent la liste des noms deshôtes pour la zone coïncidant avec le SNAME ou au dessus. On copie ces noms dans SLIST, puis on détermine leur adresseà l'aide des données locales. Il peut se produire que les adresses ne soient pas disponibles. Le résolveur est alors en face deplusieurs choix ; le mieux est de commencer des processus de résolution en parallèle à la recherche de ces adresses, tout encontinuant avec les adresses disponibles. De façon évidente, les choix et options de conception sont assez complexes etlargement fonction des possibilités de l'hôte local. Les priorités recommandées pour les concepteurs de résolveurs sont : 1. Limiter la quantité de traitement (nombre de paquets émis, nombre de processus parallèles démarrés) afin qu'une

interrogation ne se mette pas en boucle infinie ou initie une réaction en chaîne de demandes ou d'interrogations avecd'autres mises en œuvre MEME DANS LE CAS DE DONNEES MAL CONFIGUREES.

2. Donner une réponse chaque fois que possible.3. Éviter les transmissions inutiles.4. Donner la réponse aussi vite que possible.

Si la recherche de RR NS échoue, alors le résolveur initialisera la SLIST à partir de la ceinture de sécurité SBELT. L'idéede base est que, lorsque le résolveur ne sait pas à quel serveur demander, il devrait utiliser les informations d'un fichier deconfiguration qui fait la liste des serveurs qui sont supposés être utiles. Bien qu'il puisse exister des situations particulières,le choix usuel est de deux serveurs racine et deux serveurs dans le domaine de l'hôte. La raison pour en prendre deux dechaque est pour assurer la redondance. Les serveurs de la racine vont fournir un accès éventuel à tout l'espace desdomaines. Les deux serveurs locaux vont permettre au résolveur de continuer la résolution des noms locaux même si leréseau local se retrouve isolé de l'Internet suite à la défaillance d'une liaison ou d'une passerelle.

En plus de fournir les adresses et noms des serveurs, la structure de données SLIST peut être triée de façon à donnerd'abord les meilleurs serveurs, et s'assurer que toutes les adresses de tous les serveurs seront utilisées à la façon d'un round-robin. Le tri peut être une simple fonction de préférence des adresses sur le réseau local par rapport aux autres, ou peutimpliquer des statistiques sur les événements passés, comme les temps de réponse précédentes et des taux moyens deréussite.

L'étape 3 envoie des interrogations jusqu'à ce qu'une réponse soit donnée. La stratégie consiste à utiliser toutes les adressespour tous les serveurs à tour de rôle, avec une temporisation donnée entre chaque émission. En pratique, il est importantd'utiliser toutes les adresses d'un hôte multi rattachements, sachant qu'une politique de retransmission trop soutenue ralentitla réponse lorsque de multiples résolveurs sont impliqués dans une recherche sur le même serveur de noms (et mêmeparfois pour un seul résolveur). La structure SLIST contient normalement des valeurs de données pour contrôler lestemporisations et garder trace des précédentes transmissions.

L'étape 4 s'occupe de l'analyse des réponses. Le résolveur devra faire preuve d'une grande paranoïa dans l'analyse de cesréponses. Il devra en outre vérifier que la réponse correspond bien à l'interrogation émise grâce à la lecture du champ IDdans la réponse. La réponse idéale est celle d'un serveur d'autorité pour l'interrogation qui donne soit les donnéesdemandées, soit une erreur de nom. Les données sont alors retransmises à l'utilisateur et recopiées dans l'antémémoire enprévision d'une interrogation identique future si sa durée de vie (TTL) est supérieure à 0.

Si la réponse indique une délégation, le résolveur devrait vérifier si la délégation est plus "proche" de la réponse que ne lesont les serveurs de la SLIST. Ceci peut être fait en comparant le compte de correspondances dans la SLIST avec celuicalculé à partir des RR SNAME et NS dans la délégation. Si ce n'est pas le cas, la réponse est considérée comme erronée etdevrait être ignorée. Si la délégation est valide, les RR NS de délégation et tout RR d'adresse pour les serveurs devraientêtre copiés dans l'antémémoire. Les serveurs de noms sont ajoutés à la SLIST, et la recherche recommence.

page - 21 -


Si la réponse contient un CNAME, la recherche doit être recommencée au CNAME sauf si la réponse contient les donnéespour ce nom canonique, où si le CNAME est la réponse elle-même.

Plus de détails et des astuces de mise en œuvre peuvent être trouvés dans la [RFC1035].

6. ScénarioDans notre échantillon d'espace de domaines, supposons qu'on veuille séparer le contrôle administratif pour la racine, et leszones MIL, EDU, MIT.EDU et ISI.EDU. On pourrait allouer les serveurs de noms comme suit :

|(C.ISI.EDU,SRI-NIC.ARPA | A.ISI.EDU) +---------------------+------------------+ | | | MIL EDU ARPA |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, | | A.ISI.EDU | C.ISI.EDU) | +-----+-----+ | +------+-----+-----+ | | | | | | | BRL NOSC DARPA | IN-ADDR SRI-NIC ACC | +--------+------------------+---------------+--------+ | | | | | UCI MIT | UDEL YALE |(XX.LCS.MIT.EDU, ISI |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU, +---+---+ | A.ISI.EDU) | | | LCS ACHILLES +--+-----+-----+--------+ | | | | | | XX A C VAXA VENERA Mockapetris

Dans cet exemple, le serveur de noms d'autorité est noté entre parenthèses au point de l'arborescence de domaines à partirduquel il assure le contrôle.

Donc les serveurs de noms racine sont sur C.ISI.EDU, SRI-NIC.ARPA, et A.ISI.EDU. Le domaine MIL est desservi parSRI-NIC.ARPA et A.ISI.EDU. Le domaine EDU est desservi par SRI-NIC.ARPA. et C.ISI.EDU. Noter que les serveurspeuvent avoir des zones contiguës ou disjointes. Dans ce scénario, C.ISI.EDU a des zones contiguës aux domaines racine etEDU. A.ISI.EDU a des zones contiguës aux domaines racine et MIL, mais a aussi une zone non contiguë à ISI.EDU.

6.1 Serveur de nom C.ISI.EDU

C.ISI.EDU est un serveur de nom pour les domaines racine, MIL, et EDU de la classe IN, et aura des zones pour cesdomaines. Les données de zone pour le domaine racine pourraient être :

. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 870611 ;serie 1800 ;rafraîchissement toutes les 30 min 300 ;reessai toutes les 5 min 604800 ;expirer après une semaine 86400) ;minimum d'un jour NS A.ISI.EDU. NS C.ISI.EDU. NS SRI-NIC.ARPA.

MIL. 86400 NS SRI-NIC.ARPA. 86400 NS A.ISI.EDU.

EDU. 86400 NS SRI-NIC.ARPA. 86400 NS C.ISI.EDU.

page - 22 -


SRI-NIC.ARPA. A 26.0.0.73 A 10.0.0.51 MX 0 SRI-NIC.ARPA. HINFO DEC-2060 TOPS20

ACC.ARPA. A 26.6.0.65 HINFO PDP-11/70 UNIX MX 10 ACC.ARPA.

USC-ISIC.ARPA. CNAME C.ISI.EDU.

73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU. 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.

A.ISI.EDU. 86400 A 26.3.0.103 C.ISI.EDU. 86400 A 10.0.0.52

Ces données sont représentées comme elles seraient écrites dans un fichier maître. La plupart des RR sont des entrées à uneligne ; la seule exception ci-dessus est le RR SOA, qui utilise une "(" pour commencer un RR multi-ligne et une ")" pourindiquer la fin du RR multi-ligne. Comme la classe de tous les RR d'une zone doit être identique, seul le premier RR d'unezone mentionnera la classe. Lorsqu'un serveur de noms charge une zone, il force le TTL de tout RR d'autorité à avoir aumoins la valeur indiquée dans le champ MINIMUM du SOA, ici 86 400 secondes, soit un jour. Le RR NS indiquant ladélégation pour les domaines MIL et EDU, combinés aux RR glu indiquant les adresses des hôtes serveurs, ne fait paspartie des données d'autorité dans la zone, et donc ont des TTL explicites.

Quatre RR sont rattachés au nœud racine : le SOA qui décrit la zone racine et les 3 RR NS qui font la liste des serveurs denoms pour la racine. Les données dans le RR SOA décrivent comment est gérée la zone. Les données de zone sontentretenues sur l'hôte SRI-NIC.ARPA, et le responsable de cette zone est [email protected]. Une desdonnées clef de ce SOA est le TTL minimum de 86400, qui signifie que toutes les données d'autorité de cette zone ont aumoins ce TTL, bien que des valeurs supérieures puissent être explicitement spécifiées.

Les RR NS pour les domaines MIL et EDU marquent la frontière entre la zone racine et les zones MIL et EDU. Noter quedans cet exemple, les zones de niveau inférieur se trouvent être prises en charge par un serveur qui prend aussi en charge lazone racine.

Le fichier maître pour la zone EDU peut être commencé par rapport à l'origine EDU. Les données de zone pour le domaineEDU pourraient être :

EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 870729 ;serie 1800 ;rafraîchissement toutes les 30 minutes 300 ;reessai toutes les 5 minutes 604800 ;expire après une semaine 86400 ;minimum d'un jour ) NS SRI-NIC.ARPA. NS C.ISI.EDU.

UCI 172800 NS ICS.UCI 172800 NS ROME.UCI ICS.UCI 172800 A 192.5.19.1 ROME.UCI 172800 A 192.5.19.31 ISI 172800 NS VAXA.ISI 172800 NS A.ISI 172800 NS VENERA.ISI.EDU. VAXA.ISI 172800 A 10.2.0.27 172800 A 128.9.0.33

page - 23 -


VENERA.ISI.EDU. 172800 A 10.1.0.52 172800 A 128.9.0.32 A.ISI 172800 A 26.3.0.103

UDEL.EDU. 172800 NS LOUIE.UDEL.EDU. 172800 NS UMN-REI-UC.ARPA. LOUIE.UDEL.EDU. 172800 A 10.0.0.96 172800 A 192.5.39.3

YALE.EDU. 172800 NS YALE.ARPA. YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.

MIT.EDU. 43200 NS XX.LCS.MIT.EDU. 43200 NS ACHILLES.MIT.EDU. XX.LCS.MIT.EDU. 43200 A 10.0.0.44 ACHILLES.MIT.EDU. 43200 A 18.72.0.8

Noter ici l'utilisation de noms relatifs. Le nom du proprétaire pour ISI.EDU. est noté en utilisant un nom relatif, ainsi que lecontenu des deux RR relatifs aux serveurs de noms. Les noms de domaines relatifs et absolus peuvent être librementmélangés dans un fichier maître.

6.2 Exemple d'interrogations standard

Les interrogations et réponses suivantes illustrent le comportement d'un serveur de noms. Sauf mention contraire, lesinterrogations n'ont pas le mode récurrent désiré (RD) dans leur en-tête. Noter que les réponses aux interrogations nonrécurrentes dépendent du serveur de noms contacté, mais ne dépendent pas de l'identité du requérant.

6.2.1 QNAME=SRI-NIC.ARPA, QTYPE=A

L'interrogation aurait l'aspect suivant :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

La réponse de C.ISI.EDU serait : +---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | 86400 IN A 10.0.0.51 | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

L'en-tête de la réponse ressemble à celui de l'interrogation, excepté que le bit RESPONSE est établi, indiquant que cemessage est une réponse, et non une interrogation, et le bit Réponse d'autorité (AUTHORITATIVE ANSWER = AA) est

page - 24 -


établi, indiquant que les adresses données dans les RR de la section réponse sont d'autorité. La section question de laréponse correspond à la section question de l'interrogation.

Si la même interrogation avait été envoyée à d'autres serveurs qui ne seraient pas d'autorité pour SRI-NIC.ARPA, laréponse aurait été : +---------------------------------------------------+ En-tête | OPCODE=SQUERY,RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 | | 1777 IN A 26.0.0.73 | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Cette réponse est différente de la précédente à deux titres : l'en-tête ne présente pas le bit AA établi, et les TTL sontdifférents. On en déduit que les données ne proviennent pas d'une zone, mais plutôt d'une antémémoire. La différence entrele TTL d'autorité et le TTL qu'on a ici est due au vieillissement des données dans l'antémémoire. Les différences d'ordredes RR de la section Réponse ne sont pas significatives.

6.2.2 QNAME=SRI-NIC.ARPA, QTYPE=*

Une interrogation similaire à la précédente, mais utilisant un QTYPE de "*", recevrait la réponse suivante de C.ISI.EDU : +---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | A 10.0.0.51 | | MX 0 SRI-NIC.ARPA. | | HINFO DEC-2060 TOPS20 | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Si une interrogation identique était envoyée à deux serveurs non d'autorité pour SRI-NIC.ARPA, la réponse aurait été : +---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+ et +---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | +---------------------------------------------------+

page - 25 -


Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Aucune de ces deux réponse n'a le bit AA établi, et donc aucune ne provient de données d'autorité. Les différences decontenu et de durées de vie suggèrent que les deux serveurs ont enregistré les données dans leur antémémoire à une datedifférente, et que le premier serveur à mis en antémémoire la réponse à une interrogation QTYPE=A, et le second les amises en antémémoire suite à une interrogation HINFO.

6.2.3 QNAME=SRI-NIC.ARPA, QTYPE=MX

Ce type d'interrogation pourrait émaner d'un agent de courrier électronique essayant de trouver le chemin pour ledestinataire de courrier [email protected]. La réponse de C.ISI.EDU serait :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Réponse | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.| +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+

Cette réponse contient le RR MX dans la section Réponse du message. La section additionnelle contient les RR d'adressecar le serveur de nom à C.ISI.EDU devine que le requérant aura besoin de ces adresses pour exploiter correctement lesinformations transmises dans le RR MX.

6.2.4 QNAME=SRI-NIC.ARPA, QTYPE=NS

C.ISI.EDU répondrait à l'interrogation par :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

La seule différence entre l'interrogation et la réponse est l'établissement des bits AA et RESPONSE dans l'en-tête.L'interprétation de cette réponse est que le serveur est bien d'autorité pour le nom en question, lequel existe, mais pourlequel aucun enregistrement de type NS n'est présent.

6.2.5 QNAME=SIR-NIC.ARPA, QTYPE=A

Lorsqu'un utilisateur orthographie mal un nom de domaine, nous pourrons voir ce type d'interrogation. C.ISI.EDUrépondrait dans ce cas :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE | +---------------------------------------------------+

page - 26 -


Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. | | 870611 1800 300 604800 86400 | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Cette réponse déclare que le nom demandé n'existe pas. Cette condition est exprimée dans la section Code de réponse(RCODE) dans l'en-tête. Le RR SOA dans la section Autorité est l'information facultative de mise en antémémoirenégative, qui permet au résolveur utilisant cette réponse de supposer que le nom recherché n'existera pas pendant au moinsSOA MINIMUM (86 400) secondes.

6.2.6 QNAME=BRL.MIL, QTYPE=A

Si cette interrogation était envoyée à C.ISI.EDU, la réponse serait :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | MIL. 86400 IN NS SRI-NIC.ARPA. | | 86400 NS A.ISI.EDU. | +---------------------------------------------------+ Additionnel | A.ISI.EDU. A 26.3.0.103 | | SRI-NIC.ARPA. A 26.0.0.73 | | A 10.0.0.51 | +---------------------------------------------------+

Cette réponse a une section Réponse vide, mais n'est pas d'autorité. Il s'agit donc d'un point de référence. Le serveur denoms à C.ISI.EDU, réalisant qu'il n'est pas d'autorité pour le domaine MIL, a renvoyé le requérant vers les serveursA.ISI.EDU et SRI-NIC.ARPA, qu'il sait être d'autorité pour le domaine MIL.

6.2.7 QNAME=USC-ISIC.ARPA, QTYPE=A

La réponse à cette interrogation venant de A.ISI.EDU serait :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | | C.ISI.EDU. 86400 IN A 10.0.0.52 | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Noter que le bit AA dans l'en-tête garantit que les données correspondantes au QNAME sont d'autorité, mais ne dit rien sursi les données concernant C.ISI.EDU sont d'autorité. Cette réponse complète est possible car A.ISI.EDU se trouve êtred'autorité à la fois pour le domaine ARPA ou se trouve USC-ISIC.ARPA et pour le domaine ISI.EDU où se trouveC.ISI.EDU.

page - 27 -


Si la même interrogation était envoyée à C.ISI.EDU, sa réponse serait la même que celle ci-dessus si il avait sa propreadresse en antémémoire, mais elle pourrait aussi être :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | +---------------------------------------------------+ Autorité | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | | NS A.ISI.EDU. | | NS VENERA.ISI.EDU. | +---------------------------------------------------+ Additionnel | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | | A.ISI.EDU. 172800 A 26.3.0.103 | +---------------------------------------------------+

Cette réponse contient une réponse d'autorité pour l'alias USC-ISIC.ARPA, plus un point de référence aux serveurs denoms pour ISI.EDU. Cette sorte de réponse ne sera en général pas celle donnée si l'interrogation est pour le nom d'hôte duserveur de noms lui-même, mais serait courante pour d'autres alias.

6.2.8 QNAME=USC-ISIC.ARPA, QTYPE=CNAME

Si cette interrogation est envoyée à A.ISI.EDU ou C.ISI.EDU, la réponse serait :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | +---------------------------------------------------+ Réponse | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Parce que le QTYPE=CNAME, le RR CNAME lui-même répond à l'interrogation, et le serveur de nom ne tente pas derechercher autre chose pour C.ISI.EDU (sauf éventuellement pour renseigner une section additionnelle).

6.3 Exemple de résolution

Les exemples suivants illustrent les opérations qu'un résolveur devra effectuer pour son client. On suppose que le résolveurpart avec une antémémoire vide, ce qui pourrait être le cas après un redémarrage système. On supposeras de plus que lesystème n'est pas un des hôtes des données de zone et que l'hôte est situé quelque part sur le réseau d'adresse 26, et que sa"ceinture de sécurité" (SBELT) a les informations suivantes : Match count = -1 SRI-NIC.ARPA. 26.0.0.73 10.0.0.51 A.ISI.EDU. 26.3.0.103

Ces informations spécifient les serveurs à essayer, leurs adresses, et un décompte de concordance à -1, qui indique que lesserveurs ne sont pas "très proches" de la cible. Noter que cette valeur -1 n'est pas supposée être une mesure précise de la"distance", mais juste une valeur conventionnelle sur laquelle se fonderont les étapes ultérieures de l'algorithme.

Les exemples suivants illustrent l'utilisation de l'antémémoire, et donc chaque exemple suppose que les interrogationsprécédentes sont terminées.

page - 28 -


6.3.1 Résolution de MX pour ISI.EDU.

On suppose que la première demande au résolveur provient de l'agent de courrier local, qui doit envoyer un message à[email protected]. L'agent de courrier demande alors les RR de type MX pour le nom de domaine ISI.EDU.

Le résolveur va d'abord chercher dans son antémémoire des RR MX pour ISI.EDU, mais l'antémémoire est vide et cela nerésout rien. Le résolveur va en conclure qu'il doit interroger des serveurs de noms distants et dans un premier temps essayerde déterminer quel sont les meilleurs serveurs à interroger. Cette recherche va porter sur les RR NS pour les domainesISI.EDU, EDU, et la racine. Ces recherches dans l'antémémoire vont aussi échouer. En dernier ressort, le résolveur vautiliser les informations de la structure SBELT, en les copiant dans la structure SLIST.

Arrivé à ce point, le résolveur devra choisir l'une des trois adresses disponibles à essayer. Du fait que le résolveur est sur leréseau d'adresse 26, il devrait choisir soit 26.0.0.73, soit 26.3.0.103 en premier. Il va alors envoyer une interrogation de laforme :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

Le résolveur va ensuite attendre une réponse à son interrogation, ou une fin de temporisation. Si la fin de temporisationarrive, il va essayer les différents serveurs, puis les différentes adresses pour les mêmes serveurs, et enfin en réessayant lesadresses déjà tentées. Il peut finalement recevoir une réponse de SRI-NIC.ARPA :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Réponse | <vide> | +---------------------------------------------------+ Autorité | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | | NS A.ISI.EDU. | | NS VENERA.ISI.EDU.| +---------------------------------------------------+ Additionnel | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | | A.ISI.EDU. 172800 A 26.3.0.103 | +---------------------------------------------------+

Le résolveur va remarquer que les informations dans la réponse donnent une délégation plus "proche" à ISI.EDU que saSLIST existante (du fait que trois étiquettes correspondent). Le résolveur va alors mettre en antémémoire les informationsde cette réponse et les utilisera pour établir une nouvelle SLIST :

Match count = 3 A.ISI.EDU. 26.3.0.103 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 VENERA.ISI.EDU. 10.1.0.52 1281000.9.0.32

page - 29 -


A.ISI.EDU apparaît dans cette liste ainsi que le précédent, mais il s'agit d'une pure coïncidence. Le résolveur varecommencer la transmission des interrogations et l'attente des réponses. Finalement, il obtient une réponse :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | +---------------------------------------------------+ Réponse | ISI.EDU. MX 10 VENERA.ISI.EDU. | | MX 20 VAXA.ISI.EDU. | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | VAXA.ISI.EDU. 172800 A 10.2.0.27 | | 172800 A 128.9.0.33 | | VENERA.ISI.EDU. 172800 A 10.1.0.52 | | 172800 A 128.9.0.32 | +---------------------------------------------------+

Le résolveur va ajouter ces informations à son antémémoire, et retourner les RR MX à son client.

6.3.2 Obtenir le nom d'hôte à partir de l'adresse 26.6.0.65

Le résolveur va traduire ceci en une interrogation sur des RR PTR pour le domaine 65.0.6.26.IN-ADDR.ARPA. Cetteinformation n'est pas dans l'antémémoire, et donc le résolveur doit chercher un serveur distant auquel la demander. Aucunserveur de l'antémémoire ne va correspondre, et il faudra une fois encore exploiter les données de SBELT. (Noter que lesserveurs pour le domaine ISI.EDU sont bien dans l'antémémoire, mais ISI.EDU n'est pas un ancêtre de 65.0.6.26.IN-ADDR.ARPA, et donc SBELT est utilisé).

Comme cette demande est dans les données d'autorité des deux serveurs mentionnés dans SBELT, l'un d'eux va finalementrépondre :

+---------------------------------------------------+ En-tête | OPCODE=SQUERY, RESPONSE, AA | +---------------------------------------------------+ Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR | +---------------------------------------------------+ Réponse | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. | +---------------------------------------------------+ Autorité | <vide> | +---------------------------------------------------+ Additionnel | <vide> | +---------------------------------------------------+

6.3.3 Obtenir l'adresse de l'hôte du domaine poneria.ISI.EDU

Cette interrogation se traduit par une interrogation sur le type A pour le domaine poneria.ISI.EDU. Le résolveur ne trouveaucune donnée en antémémoire pour ce nom, mais trouvera dans l'antémémoire les RR NS pour ISI.EDU lorsqu'il yrecherchera des serveurs distants à interroger. Avec ces données, il va construire une SLIST de la forme :

Match count = 3A.ISI.EDU. 26.3.0.103VAXA.ISI.EDU. 10.2.0.27 128.9.0.33VENERA.ISI.EDU. 10.1.0.52

A.ISI.EDU figure en premier, dans l'hyposthèse où le résolveur hiérarchise ses préférences, et du fait qu'A.ISI.EDU est surle même réseau. Un de ces serveurs va répondre à l'interrogation.

page - 30 -


7. Références et bibliographie

[Dyer 87] Dyer, S., and F. Hsu, "Hesiod, Project Athena Technical Plan - Name Service", avril 1987, version 1.9. Décrit les fondements du service de noms Hesiod.

[IEN-116] J. Postel, "Internet Name Server", IEN-116, USC/Information Sciences Institute, août 1979. Service de noms rendu obsolète par le Système de noms de domaines, mais toujours utilisé.

[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer Networks", Communications of the ACM, octobre 1986, volume 29, numéro 10.

[RFC0742] K. Harrenstien, "NAME/FINGER", décembre 1977. (Obsolète, voir la RFC1288)

[RFC0768] J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

[RFC0793] J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7, septembre 1981.

[RFC0799] D. Mills, "Domaines de noms Internet", septembre 1981.

[RFC0805] J. Postel, "Notes de réunion de la messagerie informatique", février 1982.

[RFC0810] E. Feinler et autres, "Spécification du tableau des hôtes Internet du DOD", mars 1982. Obsolète, voir la RFC0952.

[RFC0811] K. Harrenstien, V. White et E. Feinler, "Serveur des noms d’hôtes", mars 1982. Obsolète, voir la RFC 953.

[RFC0812] K. Harrenstien et V. White, "Surnoms/Qui est qui", mars 1982.

[RFC0819] Z. Su et J. Postel, "Convention de nommage des domaines pour les applications d’utilisateurs de l’Internet", août 1982. Premières réflexions sur la conception du système des domaines. La mise en œuvre actuelle est complètement différente.

[RFC0821] J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.

[RFC0830] Z. Su, "Système distribué pour le service de noms Internet", octobre 1982. Premières réflexions sur la conception du système des domaines. La mise en œuvre actuelle est complètement différente.

[RFC0882] P. Mockapetris, "Noms de domaines - Concepts et facilités", (obsolète voir RFC 1034/1035), novembre 1983.

[RFC0883] P. Mockapetris, "Noms de domaines – Spécification et mise en œuvre", (obsolète, voir RFC 1034/1035), novembre 1983.

[RFC0920] J. Postel et J. Reynolds, "Exigences pour les domaines", octobre 1984.

[RFC0952] K. Harrenstien, M. Stahl, E. Feinler, "Spécification du tableau des hôtes de l’Internet du DOD", octobre 1985. Spécifie le format de HOSTS.TXT, le tableau des hôtes/adresses remplacé par le DNS.

[RFC0953] K. Harrenstien, M. Stahl, E. Feinler, "Serveur HOSTNAME", octobre 1985. (Historique). Cette RFC contientla spécification officielle du protocole de serveur de nom d’hôte, qui est rendue obsolète par le DNS. Ceprotocole fondé sur TCP donne accès à des informations mémorisées dans le format de la RFC 952, et estutilisé pour obtenir des copies du tableau des hôtes.

[RFC0973] P. Mockapetris, "Changements et observations du système des domaines", (Obsolète, voir RFC1034/1035), janvier 1986. Décrit les changements aux RFC 882 et 883 et leurs raisons. Maintenant obsolète.

[RFC0974] C. Partridge, "L’acheminement de la messagerie et le système des domaines", janvier 1986. (obsolète, voirRFC 2821). Décrit la transition de l’adressage de messagerie fondé sur HOSTS.TXT au plus puissantsystème MX utilisé avec le système des domaines.

page - 31 -

http://www.rfc-editor.org/rfc/rfc810.txt









http://abcdrfc.free.fr/rfc-vf/pdf/rfc0830.pdf










http://abcdrfc.free.fr/rfc-vfpdf/rfc0793.pdf


http://abcdrfc.free.fr/rfc-vf/rfc0768.html



[RFC1001] "Protocole standard pour un service NetBIOS sur un transport TCP/UDP : concepts et méthodes", STD 19,mars 1987. Cette RFC et la RFC 1002 sont un dessin préliminaire de NETBIOS par dessus TCP/IP quipropose de placer le service de noms NetBIOS par dessus le DNS. (STD 19)

[RFC1002] "Protocole standard pour un service NetBIOS sur un transport TCP/UDP : Spécifications détaillées", STD 19,mars 1987.

[RFC1010] J. Reynolds et J. Postel, "Numéros alloués", mai 1987. (Historique, voir www.iana.org) Contient les numéros des prises et les mnémoniques pour les noms des hôtes, des systèmes d’exploitation, etc.

[RFC1031] W. Lazear, "Transition du domaine des noms MILNET", novembre 1987. Décrit un plan pour convertir le MILNET en DNS.

[RFC1032] M. K. Stahl, "Établissement d’un domaine - lignes directrices pour les administrateurs", novembre 1987.Décrit les politiques d’enregistrement utilisées par le NIC pour administrer les domaines de niveau supérieuret déléguer les sous-zones.

[RFC1033] M. K. Lottor, "Guide de fonctionnement de l’administrateur de domaine", novembre 1987. Livre de recettespour les administrateurs de domaine.

[Solomon 82] M. Solomon, L. Landweber, et D. Neuhengen, "Le serveur de noms CSNET", Computer Networks, vol 6,n° 3, juillet 1982. Décrit un service de noms pour CSNET indépendant du DNS et l’utilisation du DNS dansCSNET.

Index

A : § 3,6Alias : § 3,6,2 ; 5.2.2Autorité : § 2,4 ; 4.2AXFR : § 3.7.1 ; 4.3.5Casse des caractères : § 3.1Caractère générique : § 4.3.3Ceinture de sécurité (SBELT) : § 5.3.2CH : § 3.6CNAME : § 3.6.2Erreur de nom : § 4.3.1Étiquette : § 3.1HINFO : § 3.6Interrogation de fin de traitement : § 3.9IN : § 3.6Interrogation d'état : § 3.7 ; 3.8Interrogation inverse : § 3.7.2Interrogation standard : § 4.3.1Itératif : § 2.3NE : § 5.2.1Nom absolu : § 3.1Nom de boîte aux lettres : § 3.3Nom de domaine : § 3.1Nom relatif : § 3.1MX : § 3.6Mise en antémémoire négative : § 4.3.4NS : § 3.6Opcode : § 3.7PTR : § 3.6QCLASS : § 3.7.1QTYPE : § 3.7.1RDATA : § 3.6Récurrent : § 2.3RR : § 3.6

page - 32 -


http://www.rfc-editor.org/in-notes/rfc1033.txt




http://www.iana.org/







RR glu : § 4.2.1Résolveur : § 2.4 Résolveur d'extrémité : § 5.3.1Sections : § 3.7.1Serveur de nom : § 2.4 ; § 4Service récurrent ; § 4.3.1SOA : § 3.6Transfert de zeone : § 4.3.5TTL : § 3.6Zones : § 4.2

page - 33 -

RFC 1034 : DNSRFC 1034 : Serveur de noms de domaines ...

Documents

Transcript of RFC 1034 : DNSRFC 1034 : Serveur de noms de domaines ...