RFC: 1034
Statut : Standard
Retour à l'index français
Les serveurs de noms sont dépositaires de l'information qui constitue la base de données des domaines. La base de données est divisée en sections appelées zones, lesquelles sont distribuées sur l'ensemble des serveurs de noms. Comme les serveurs de noms peuvent implémenter des fonctions optionnelles et des sources de données différentes, la tâche essentielle d'un serveur de nom reste de répondre à des requêtes sur ses données propres. Par conception, les serveurs de noms peuvent répondre à ces requêtes d'une manière simple ; la réponse peut toujours être générée à partir des seules données locales, et contiendra soit la réponse à la question posée, soit une référence à un autre serveur de noms "plus susceptible" d'avoir l'information demandée.
Une zone donnée pourra être accessible à partir de plusieurs serveurs de noms afin d'assurer son accessibilité même en cas de défaillance du serveur ou des liaisons. Par décision "administrative", nous imposons qu'une zone soit accessible au moins par deux serveurs, et souhaitons que la redondance soit en réalité plus importante que cela.
Un serveur de noms donné support typiquement une ou plusieurs zones, ceci ne le qualifiant d'autorisé que pour une petite partie de l'arbre des domaines. Il pourra de plus détenir une certaine quantité de données "non-autorisées" dans son cache, spécifiant certaines autres parties de l'arbre. Le serveur de nom renseigne sa réponse de telle sorte que le requérant sache si les informations proviennent de la partie "autorisée" ou nom du serveur de noms.
La base de données de domaines est divisées selon deux méthodes : en classes, et par "découpage" de l'espace des noms de domaines.
La partition en classes est assez simple. La base de données est organisée, déléguée, et maintenue séparément pour chacune des classes. Comme par convention, l'espace de noms est identique quel que soit la classe, la séparation par classe peut conduire à voir l'espace de domaines comme un tableau d'arbres de noms parallèles. Notez que les données attachées aux noeuds des arbres seront différentes dans chaque arbre. Les raisons les plus courantes poussant à créer une nouvelle classe est soit la nécessité de gérer un nouveau format de données pour des types existants, soit la nécessité de gérer différemment une partie des informations.
Dans une classe, des "coupes" dans l'espace de noms peuvent être faites entre deux noeuds adjacents quelconques. Un fois toutes les coupes définies, chaque groupe de noeuds interconnectés devient une zone indépendante. La zone est alors définie comme étant la "sphère d'autorisation" pour tout nom à l'intérieur de la zone. Notez que les "coupes" dans l'espace de noms peuvent être à des endroits différents de l'arbre suivant la classe, les serveurs de noms associés peuvent être différents, etc.
Ces règles signifient que chaque zone doit avoir au moins un noeud, et donc un nom de domaine, pour lequel il est "autorisé", et que tous les noeuds d'une zone particulière sont connectés. Du fait de la structure d'arbre, chaque zone contient un noeud "de plus haut niveau" qui est plus proche de la racine que tous les autres noeuds de cette zone. Le nom de ce noeud est souvent utilisé pour identifier la zone elle-même.
Selon ce concept, il est possible, bien que pas forcément utile, de découper l'espace de noms de telle façon que chaque nom de domaine se retrouve dans une zone séparée ou au contraire que tous les noeuds se retrouvent dans une zone unique. En fait, la base de données est découpée selon la volonté d'une organisation particulière d'accepter de gérer le sous-arbre inférieur au point de coupure. Une fois que cette organisation contrôle sa propre zone, elle pourra modifier les données dans cette zone de façon unilatérale, créer des nouveaux sous-arbres à l'intérieur de la zone, supprimer des noeuds existants, ou déléguer la gestion de sous-zone à d'autres organisations plus locales.
Si l'organisation est elle même structurée, elle souhaitera certainement créer des sous partitions dont elle déléguera à son tour la gestion. Dans certains cas, de telles divisions ne sont faites que pour rendre plus maniable la maintenance de la base de données.
Les données décrivant une zone se divisent en quatre parties majeures :
Toutes ces données sont exprimées sous forme de RR, et donc une zone peyt être entièrement décrite comme un ensemble de RR. Des zones entières peuvent être transférées de serveur à serveur par le transfert des RR, soit par une suite de messages, ou en transférant le fichier principal, qui en est une représentation textuelle, par FTP.
Les données autorisées pour une zone sont en fait tous les RR attachés à tous les noeuds depuis la tête de la zone jusqu'aux feuilles les plus basses, ou le noeud immédiatement au-dessus d'un point de coupe d'une sous-zone.
Bien que faisant logiquement partie des données autorisées, les RR qui décrivent la tête de la zone sont fondamentaux pour la gestion des zones. Ces RR sont de deux types : des RR de serveurs de noms qui listent, à raison de un par RR, tous les serveurs autorisés pour cette zone, et un RR SOA unique qui donne les paramètres de gestion de cette zone.
Les RR qui décrivent les coupures vers le bas de la zone sont des RR NS qui pointent sur les serveurs de noms auxquels ont été déléguées les sous-zones. Dans la mesure où les coupures se font entre deux noeuds, ces RR NE font PAS partie des données autorisées de la zone, et devront donner exactement les mêmes informations que le RR donnant les informations sur le noeud de tête de la sous-zone, dans le serveur délégué. Comme les serveurs de noms sont toujours associés par rapport aux limites de zones, les RR NS ne peuvent être trouvés que dans des noeuds représentant la tête d'une zone. Dans les données qui caractérisent la zone, les RR NS seront trouvés dans le noeud qui caractérise la tête de la zone courante (constituant un enregistrement autorisé*) et au niveau des noeuds pointant sur la tête d'une sous-zone (lequel noeud n'est pas considéré comme une information "autorisée"), mais jamais dans un noeud intermédiaire.
L'un des objectifs de cette structure en zones est que toute zone puisse disposer localement de toutes les données nécessaires pour communiquer avec les serveurs de noms de chacune de ses sous-zones. En d'autres termes, que les zones mères disposent de toute l'information requise pour accéder aux serveurs des zones filles. Les RR NS qui nomment ces serveurs pour les sous-zones ne suffisent pas toujours à cet tâche dans la mesure où, s'ils définissent le nom du serveur, n'en donnent pas l'adresse. En particulier, si le nom du serveur de noms est lui-même dans la sous-zone, nous pourrions être confronté à la situation embarrassante où le RR NS nous dit que pour connaître l'adresse du serveur de noms de la sous-zone, nous devons contacter un serveur portant l'adresse que nous souhaitons justement apprendre. Pour contourner ce problème, une zone contient des RR qualifiés de "glue" qui ne font pas partie de l'ensemble des données dites "autorisées", et représentent des adresses de serveurs sous forme de RR. Ces RR ne sont nécessaires que si le nom du serveur de nom se situe justement dans la portion d'espace "en dessous" de la coupure, et ne sont utilisés que comme constituant partiel d'une réponse référentielle.
Lorsque certaines organisations veulent récupérer le contrôle de leur propre domaine, la première étape est d'identifier la bonne zone mère, et obtenir des "légataires" de la zone mère un accord de délégation de gestion. Comme aucune contrainte technique particulière ne vient déterminer un point précis de l'arbre où la coupure peut être effectuée, certains regroupements "arbitraires" ont été exposés dans la [RFC-1032] concernant l'organisation des niveaux supérieurs, les zones médianes restant libres de créer leurs propres règles. Par exemple, une université pourrait choisir de n'utiliser qu'une seule zone, tandis qu'une autre pourrait choisir d'organiser son parc en sous-zones, dédiées chacune à un département ou une école. La [RFC-1033] liste les logiciels de DNS disponibles et expose les procédures administratives.
Une fois le nom de la sous-zone choisi, les futurs "légataires" devront prouver leur capacité à supporter la redondance des serveurs de domaines. Notez qu'il n'y a pas d'obligation à ce que le serveur pour une zone soit implanté sur une machine disposant d'un nom dans cette zone. Dans de nombreux cas, une zone sera bien plus largement accessible à Internet si les serveurs qui la gèrent sont dispersés, plutôt que concentrés sur le site physique contrôlé par le "légataire" de la la zone. Par exemple, l'un des serveurs de noms pour le sous-domaine United Kingdom, ou UK, est situé aux Etats-Unis. Ceci permet aux hôtes américains d'obtenir les informations sur les serveurs anglais sans être contraint par les limites de bande passante transatlantique.
Dans la dernière étape, les RR NS et les RR "glue" pointant sur le serveur délégué, et nécessaires pour rendre opérationnel le transfert de gestion, devront être ajoutés dans la zone mère. Les administrateurs de chaque zones devront s'assurer que les RR NS et "glue" situés de chaque côté de la coupure sont identiques et le restent.
La principale activité d'un serveur de noms est de répondre aux requêtes standard. La requête et sa réponse sont toutes deux véhiculées par un message de format standardisé décrit dans la [RFC-1035]. La requête contient des champs QTYPE, QCLASS, et QNAME, qui décrivent le(s) type(s) et la ou les classes de l'information souhaitée, et quel nom de domaine cette information concerne.
La manière dont le serveur de noms répond peut être différente selon que le serveur utilise le mode récursif ou non :
Le service récursif est utile dans plusieurs situations :
Le service non-récursif est approprié si le résolveur est capable de façon autonome de poursuivre sa recherche et est capable d'exploiter l'information supplémentaire qui lui est envoyée pour l'aider à résoudre son problème.
L'utilisation du mode récursif est limité aux cas qui résultent d'un accord négocié entr ele client et le serveur. Cet accord est négocié par l'utilisation de deux bits particuliers des messages de requête et de réponse :
Le mode récursif est mis en œuvre lorsqu'une requête arrive avec un bit RD marqué sur un serveur annonçant disposer de ce service ; le client peut vérifier si le mode récursif a été utilisé en constatant que les deux bits RA et RD ont été marqués dans la réponse. Notez que le serveur de noms ne doit pas utiliser le service récursif s'il n'a pas été explicitement demandé par un bit RD, car cela interfère avec la maintenance des serveurs de noms et de leurs bases de données. Lorsque le service récursif est demandé et est disponible, la réponse récursive à une requête doit être l'une des suivantes :
Si le service récursif n'est pas requis, ou n'est pas disponible, la réponse non-récursive devra être l'une des suivantes :
L'algorithme actuel utilisé par le serveur de noms dépends de l'OS local et des structures de données physiques utilisées pour stocker les RR. L'algorithme suivant suppose que les RR sont organisés en structures d'arbre multiples, un pour chaque zone, et une particulière pour le cache :
Dans l'algorithme précédant, un traitement spécial a été fait sur les RR dont le nom de propriétaire (owner) commence par l'identifiant "*". De tels RR sont appelés "métaenregistrements" (NdT : nous avons choisi ce terme au même titre que l'on utilise sous UNIX des métacaractères dans les expressions régulières pour remplacer une chaîne de caractères quelconque). Les métaenregistrements peuvent être compris comme des instructions servant à synthétiser des RR. Lorsque les conditions appropriées sont remplies, le serveur de nom crée des RR dont le nom de propriétaire est celui présent dans la requête et le contenu récupéré dans le métaenregistrement.
Cette faculté est le plus souvent utilisée pour créer une zone servant à rediriger des mail depuis Internet vers d'autres systèmes de messagerie. L'idée générale est que tout nom dans cette zone présenté au serveur dans une requête doit être supposé exister, doté de certaines propriétés, sauf si une évidence explicite conduit à l'affirmation du contraire. Notez que l'utilisation du terme zone dans ce cas, plutôt que domaine, est intentionnel ; un tel usage "par défaut" ne se propage pas au delà d'une limite de zone, bien qu'une sous-zone puisse elle aussi présenter ce fonctionnement en mettant en place un usage par défaut similaire.
Le contenu des métaenregistrements suit les règles et formats généraux des RR. Un métaenregistrement dans une zone a un propriétaire (owner) contrôlant pour quel nom requis l'enregistrement sera choisi. Le format pour le propriétaire du méta enregistrement est de la forme "*. Les métaenregistrements ne peuvent s'appliquer :
Un identifiant "*" apparaissant dans une requête n'a pas d'effet particulier, mais peut être utilisé pour tester les défauts d'une zone autorisée ; une telle requête est la seule manière d'obtenir des réponses contenant des RR portant un nom de propriétaire incluant un "*". Le résultat de telles requêtes ne devra pas être conservé en cache.
Notez que le contenu des métaenregistrements n'est pas modifié lorsque ceux-ci sont lus pour synthétiser des RR.
Pour illustrer l'usage des métaenregistrements, supposez qu'une grande société disposant d'un réseau étendu, non basé sur TCP/IP, désire créer une passerelle de messagerie. Si la compagnie s'appelle X.COM, et la passerelle vers TCP/IP, A.X.COM, les RR suivants devraient être rentrés dans la zone COM :
Avec une telle programmation, toute requête de type MX pour tout domaine terminant par X.COM retournera un RR MX pointant sur A.X.COM. Pour obtenir cet effet, deux métaenregistrements sont nécessaires. En effet, l'effet du métaenregistrement *.X.COM est inhibé pour tous les sous-domaines de A.X.COM du fait de l'existence d'un enregistrement explicite pour A.X.COM. Notez de plus que les enregistrements MX pour X.COM et A.X.COM eux-mêmes sont requis, et qu'aucun RR de la zone ci-dessus ne doit apparaître avec un propriétaire XX.COM.
Le DNS définit un service optionnel qui permet aux serveurs de nom de distribuer, et aux résolveurs de stocker en cache, les réponses négatives dotées d'une durée de vie. Par exemple, un serveur de noms peut distribuer une durée de vie associée à une indication d'erreur de nom de domaine. Un résolveur recevant ce message à la possibilité de déduire que le nom demandé n'existe pas pendant ladite durée de vie sans être obligé de consulter des données autorisées. De même, un résolveur peut émettre une requête avec un QTYPE qui accepte plusieurs types à la fois, et conserver dans le cache l'information concernant l'absence de certains types.
Cette fonctionnalité peut être particulièrement importante dans un système qui propose des raccourcis recherche en utilisant des listes car ces raccourcis, qui nécessitent généralement un suffixe en fin de liste, peuvent générer de multiples erreurs de noms lorsqu'elles sont utilisées.
La méthode qu'utilise un serveur de noms sera d'ajouter un RR SOA dans la section additionnelle d'une réponse lorsque celle-ci est "autorisée". Le SOA doit être celui fourni par la zone source des données autorisées incluses dans la section réponse, ou un message d'erreur de nom si applicable. Le champ MINIMUM de l'enregistrement SOA contrôle le temps pendant lequel la réponse négative peut être gardée dans le cache.
Notez que dans certaines circonstances, la section réponse peut spécifier plusieurs noms de propriétaires. Dans ce cas, le mécanisme de SOA ne devra être employé que pour les données correspondant au QNAME, ces données étant les seules autorisées dans cette section.
Les serveurs de noms et les résolveurs ne devront jamais tenter d'ajouter des SOA dans la section additionnelle d'une réponse non-autorisée, ni tenter d'exploiter des résultats autres que ceux déclarés comme "autorisés". Il y a à cela plusieurs raisons, dont : l'information dans le cache ne suffit pas en général à déterminer des RR et leurs nom de zone associée, les RR SOA pourront être maintenues en cache suite à une requête explicite dirigée vers des SOA, et les serveurs de noms n'inscrivent pas nécessairement les SOA dans la section autorisée (authority).
Ce fonctionnement reste optionnel, bien que l'on puisse prévoir qu'une version plus précise puisse rentrer dans le cadre du protocole officiel dans le futur. Les serveurs de noms ne sont pas tenus d'ajouter les RR SOA dans toutes leurs réponses autorisées, et les résolveurs ne sont pas plus tenus de conserver les réponses négatives en cache. Les deux comportements restent cependant recommandés. Tous les résolveurs et serveurs de noms recursifs sont tenu, au moins, de savoir ignorer des RR SOA lorsqu'ils se présentent dans une réponse.
Certaines expérimentations ont également été proposées pour utiliser cette fonctionnalité. L'idée qui les conduisait était que, si les données en cache sont conues comme venant d'une zone identifiée, et si une copie autorisée du SOA de la zone est obtenue, et enfin si le SERIAL de la zone n'a pas changé depuis que les données ont été mises dans le cache, alors la durée de vie des données du cache peut être réduite au MINIMUM de la zone considérée, si ce minimum est inférieur à la valeur cachée. Cet usage est décrit pour une recherche future, est n'est pas recommandé à présent.
Une partie du travail d'un administrateur de zone est de maintenir l'état des zones dans chacun des serveurs de noms autorisés pour celles-ci. Lorsque des modifications, inévitables, sont reportées, elles doivent l'être sur tous les serveurs de noms associés à la zone. Bien que la distribution des données puisse se faire par FTP ou toute autre procédure de transfert conséquente, la méthode préférée sera le transfert de données de zone par le protocole DNS lui-même.
Le modèle général d'un transfert de zone ou rafraîchissement automatiques consiste à dire que l'in des serveurs de noms est le serveur maître (ou encore primaire) pour cette zone. Les modifications sont coordonnées depuis le serveur maître, en général en éditant le fichier primaire pour la zone. A la fin de l'édition, l'administrateur ordonne au serveur maître de charger la zone modifiée. Les autres serveurs secondaires (ou esclaves) pour cette zone doivent vérifier périodiquement (l'intervalle de périodicité doit être réglable) si des changements sont intervenus dans la définition primaire de la zone et demanderont des copies remises à jour une fois les modifications effectuées.
Pour détecter ces modifications, il suffit aux serveurs secondaires de vérifier le champ SERIAL de l'enregistrement SOA pour cette zone. En plus de tous les autres changements apportés dans la zone, le champ SERIAL du SOA de la zone est toujours modifié dès que le moindre changement intervient. Cette modification peut se limiter à l'incrémentation d'un compteur, ou peut être basée sur l'écriture de la date et de l'heure de dernière écriture du fichier maître, etc. Le but est de donner un moyen de pouvoir savoir laquelle des deux copies du fichier de zone est le plus récent, par la simple comparaison d'un numéro de série. L'incrémentation et la comparaison des numéros de série s'appuie sur un espace séquentiel arithmétique, et il existe de ce fait une limite théorique sur la fréquence de rafraîchissement d'une zone. Celle-ci peut s'exprimer en disant que les anciennes copies doivent être totalement éliminées du système avant que le numéro de série ne "tourne" sur plus de la moitié de sa plage de 32 bits. En pratique, le seul point délicat est de vérifier que la comparaison fonctionne correctement lorsque l'on se trouve de part et d'autre du point où le compteur de série repart à 0.
La périodicité de la vérification de version par les serveurs secondaires est définie par des paramètres marqués dans le RR SOA attribué à la zone, qui définissent l'intervalle minimum entre deux vérifications. Ces paramètres sont appelés REFRESH, RETRY, et EXPIRE. Lorsqu'une zone est enregistrée dans un serveur secondaire, celui-ci attendra REFRESH secondes avant de vérifier sur le primaire si un nouveau numéro de série a été donné pour la zone. Si cette vérification ne peut être effectuée, des nouvelles tentatives seront faites toutes les RETRY secondes. La vérification est une requête simple visant le RR SOA de la zone sur le serveur principal. Si le 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 la requête, alors aucune remise à jour n'est nécessaire, et la temporisation REFRESH doit être réactivée. Si le serveur secondaire n'arrive pas à faire la vérification après que l'intervalle EXPIRE se soit écoulé, il doit alors admettre que sa copie de la zone est obsolète et doit la supprimer.
Lorsque la vérification conclue en une différence de numéros de série, le serveur secondaire devra demander un transfert de données de zone via une requête AXFR pour cette zone. La requête AXFR peut retourner une erreur, telle que "refusé", mais donne suite en temps normal à la réception d'une séquence de messages de réponse. Les premier et dernier messages doivent contenir les données du noeud autorisé de plus haut niveau dans la zone. Les messages intermédiaires transportent tous les autres RR enregistrés pour la zone, les RR non autorisés y compris. Le flux de messages permettent au serveur secondaire de reconstituer une copie conforme de la zone. Comme la précision est essentielle, on utilisera TCP ou tout autre protocole fiabilisé pour les requêtes AXFR.
Tout serveur secondaire est tenu d'effectuer cette remise à jour auprès du principal, mais doit pouvoir optionnellement permettre à un autre serveur secondaire pour la même zone d'effectuer sa remise à jour à partir de cette copie secondaire. Cette stratégie permet d'améliorer globalement la pertinence des données, en proposant une solution en cas d'arrêt du serveur principal, ou de problèmes de réseau, ou tout simplement lorsqu'un serveur secondaire dispose d'un "meilleur" accès sur un autre serveur secondaire plutôt que sur le principal.
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
4.3.4. Mise en cache de réponses négatives (Optionnel)
4.3.5. Maintenance et transfert de zones