RFC: 1034
Statut : Standard
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 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 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.
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 manière dont le serveur de noms répond peut être différente selon que le serveur utilise le mode récursif ou non :
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 :
Si l'information présente dans le noeud est un CNAME, et
QTYPE ne correspond pas à CNAME, copier le RR CNAME dans la section
"réponse" du message retourné, changer QNAME en le nom canonique
dans le RR CNAME, et retournez au pas 1.
Autrement, copier tous les RR qui correspondent au QTYPE dans la section "réponse" et sauter au pas 6.
Copier les RR NS de la sous-zone dans la section "autorisée"
de la réponse. Mettre toute adresse disponibles pouvant aider à
atteindre la sous-zone dans la section additionnelle, en utilisant des
RR "glue" si ces adresses ne peuvent être extraites que d'une partie
non-autorisée ou du cache. Sauter au pas 4.
Si l'identifiant "*" n'existe pas, vérifier si le nom que
nous cherchons est le QNAME original de la requête et non un nom
donné par une ou plusieurs redirections dans des CNAME. Si le nom
est l'original, préparer une réponse d'erreur "autorisée"
et sortir. Sinon on sort de l'algorithme sans autre action.
Si l'identifiant "*" existe, chercher les RR de ce noeud correspondant au QTYPE de la requête. S'il en existe, les copier dans la section "réponse", mais en requalifiant le propriétaire (owner) des RR comme étant QNAME, et non celui du RR contenant l'identifiant "*". Sauter en 6.
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 :
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 :
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.
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.
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.
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
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.
4.3.4. Mise en cache de réponses négatives (Optionnel)
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.
4.3.5. Maintenance et transfert de zones
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.