Aller au contenu principal

4. SERVEURS DE NOMS (NAME SERVERS)

4.1. Introduction​

Les serveurs de noms sont les dépôts d'informations qui constituent la base de données de domaine. La base de données est divisée en sections appelées zones, qui sont distribuées parmi les serveurs de noms. Bien que les serveurs de noms puissent avoir plusieurs fonctions optionnelles et sources de données, la tâche essentielle d'un serveur de noms est de répondre aux requêtes en utilisant les données de ses zones. Par conception, les serveurs de noms peuvent répondre aux requêtes de manière simple ; la réponse peut toujours être générée en utilisant uniquement des données locales, et contient soit la réponse à la question, soit une référence à d'autres serveurs de noms "plus proches" de l'information désirée.

Une zone donnée sera disponible à partir de plusieurs serveurs de noms pour assurer sa disponibilité malgré une défaillance d'hôte ou de lien de communication. Par décret administratif, nous exigeons que chaque zone soit disponible sur au moins deux serveurs, et de nombreuses zones ont plus de redondance que cela.

Un serveur de noms donné supportera généralement une ou plusieurs zones, mais cela ne lui donne des informations autoritatives que sur une petite section de l'arbre de domaine. Il peut également avoir des données non autoritatives mises en cache sur d'autres parties de l'arbre. Le serveur de noms marque ses réponses aux requêtes afin que le demandeur puisse dire si la réponse provient de données autoritatives ou non.

4.2. Comment la base de données est divisée en zones (How the database is divided into zones)​

La base de données de domaine est partitionnée de deux manières : par classe, et par des "coupures" effectuées dans l'espace de noms entre les nœuds.

Partitionnement par classe (Class partitioning)​

Le partitionnement par classe est simple. La base de données pour toute classe est organisée, déléguée et maintenue séparément de toutes les autres classes. Puisque, par convention, les espaces de noms sont les mêmes pour toutes les classes, les classes séparées peuvent être considérées comme un tableau d'arbres d'espaces de noms parallèles. Notez que les données attachées aux nœuds seront différentes pour ces différentes classes parallèles. Les raisons les plus courantes de créer une nouvelle classe sont la nécessité d'un nouveau format de données pour les types existants ou le désir d'une version gérée séparément de l'espace de noms existant.

Coupures de zone (Zone cuts)​

Dans une classe, des "coupures" dans l'espace de noms peuvent être effectuées entre deux nœuds adjacents quelconques. Après que toutes les coupures sont effectuées, chaque groupe d'espace de noms connecté est une zone séparée. On dit que la zone est autoritative pour tous les noms dans la région connectée. Notez que les "coupures" dans l'espace de noms peuvent être à des endroits différents pour différentes classes, 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 elle est autoritative, et tous les nœuds d'une zone particulière sont connectés. Étant donné la structure arborescente, chaque zone a un nœud le plus élevé qui est plus proche de la racine que tout autre nœud de la zone. Le nom de ce nœud est souvent utilisé pour identifier la zone.

Il serait possible, bien que pas particulièrement utile, de partitionner l'espace de noms de sorte que chaque nom de domaine soit dans une zone séparée ou que tous les nœuds soient dans une seule zone. Au lieu de cela, la base de données est partitionnée aux points où une organisation particulière veut prendre le contrôle d'un sous-arbre. Une fois qu'une organisation contrôle sa propre zone, elle peut unilatéralement modifier les données dans la zone, faire croître de nouvelles sections d'arbre connectées à la zone, supprimer des nœuds existants ou déléguer de nouvelles sous-zones sous sa zone.

Si l'organisation a une sous-structure, elle peut vouloir effectuer d'autres partitions internes pour réaliser des délégations imbriquées du contrôle de l'espace de noms. Dans certains cas, ces divisions sont effectuées purement pour rendre la maintenance de la base de données plus pratique.

4.2.1. Considérations techniques (Technical considerations)​

Les données qui décrivent une zone ont quatre parties principales :

  • Données autoritatives (Authoritative data) pour tous les nœuds à l'intérieur de la zone.
  • Données qui définissent le nœud supérieur (Data that defines the top node) de la zone (peuvent être considérées comme faisant partie des données autoritatives).
  • Données qui décrivent les sous-zones déléguées (Data that describes delegated subzones), c'est-à-dire les coupures autour du bas de la zone.
  • Données qui permettent l'accès aux serveurs de noms pour les sous-zones (Data that allows access to name servers for subzones) (parfois appelées données "glue").

Toutes ces données sont exprimées sous forme de RRs, donc une zone peut être complètement décrite en termes d'ensemble de RRs. Des zones entières peuvent être transférées entre serveurs de noms en transférant les RRs, soit transportés dans une série de messages, soit en transférant par FTP un fichier maître qui est une représentation textuelle.

Données autoritatives (Authoritative data)​

Les données autoritatives pour une zone sont simplement tous les RRs attachés à tous les nœuds depuis le nœud supérieur de la zone jusqu'aux nœuds feuilles ou aux nœuds au-dessus des coupures autour du bord inférieur de la zone.

Bien que faisant logiquement partie des données autoritatives, les RRs qui décrivent le nœud supérieur de la zone sont particulièrement importants pour la gestion de la zone. Ces RRs sont de deux types : les RRs de serveur de noms qui listent, un par RR, tous les serveurs pour la zone, et un seul RR SOA qui décrit les paramètres de gestion de zone.

Données de délégation (Delegation data)​

Les RRs qui décrivent les coupures autour du bas de la zone sont des RRs NS qui nomment les serveurs pour les sous-zones. Puisque les coupures sont entre les nœuds, ces RRs ne font PAS partie des données autoritatives de la zone, et devraient être exactement les mêmes que les RRs correspondants dans le nœud supérieur de la sous-zone. Puisque les serveurs de noms sont toujours associés aux limites de zone, les RRs NS ne se trouvent qu'aux nœuds qui sont le nœud supérieur d'une zone. Dans les données qui composent une zone, les RRs NS se trouvent au nœud supérieur de la zone (et sont autoritatifs) et aux coupures autour du bas de la zone (où ils ne sont pas autoritatifs), mais jamais entre les deux.

Données glue (Glue data)​

L'un des objectifs de la structure de zone est que toute zone ait toutes les données nécessaires pour établir des communications avec les serveurs de noms pour toutes les sous-zones. C'est-à-dire que les zones parentes ont toutes les informations nécessaires pour accéder aux serveurs de leurs zones enfants. Les RRs NS qui nomment les serveurs pour les sous-zones ne suffisent souvent pas pour cette tâche puisqu'ils nomment les serveurs, mais ne donnent pas leurs adresses. En particulier, si le nom du serveur de noms est lui-même dans la sous-zone, nous pourrions être confrontés à la situation où les RRs NS nous disent que pour apprendre l'adresse d'un serveur de noms, nous devrions contacter le serveur en utilisant l'adresse que nous souhaitons apprendre. Pour résoudre ce problème, une zone contient des RRs "glue" qui ne font pas partie des données autoritatives, et qui sont des RRs d'adresse pour les serveurs. Ces RRs ne sont nécessaires que si le nom du serveur de noms est "en dessous" de la coupure, et ne sont utilisés que dans le cadre d'une réponse de référence.

4.2.2. Considérations administratives (Administrative considerations)​

Lorsqu'une organisation veut contrôler son propre domaine, la première étape consiste à identifier la zone parente appropriée et à obtenir l'accord des propriétaires de la zone parente pour la délégation du contrôle. Bien qu'il n'y ait pas de contraintes techniques particulières concernant l'endroit où cela peut être fait dans l'arbre, il existe des groupements administratifs discutés dans [RFC-1032] qui traitent de l'organisation de niveau supérieur, et les zones de niveau intermédiaire sont libres de créer leurs propres règles. Par exemple, une université pourrait choisir d'utiliser une seule zone, tandis qu'une autre pourrait choisir de s'organiser par sous-zones dédiées aux départements ou écoles individuels. [RFC-1033] catalogue les logiciels DNS disponibles et discute des procédures d'administration.

Une fois que le nom approprié pour la nouvelle sous-zone est sélectionné, les nouveaux propriétaires devraient être tenus de démontrer un support redondant de serveur de noms. Notez qu'il n'y a pas d'exigence que les serveurs pour une zone résident dans un hôte qui a un nom dans ce domaine. Dans de nombreux cas, une zone sera plus accessible à Internet dans son ensemble si ses serveurs sont largement distribués plutôt que d'être dans les installations physiques contrôlées par la même organisation qui gère la zone. Par exemple, dans le DNS actuel, l'un des serveurs de noms pour le Royaume-Uni, ou domaine UK, se trouve aux États-Unis. Cela permet aux hôtes américains d'obtenir des données britanniques sans utiliser la bande passante transatlantique limitée.

Comme dernière étape d'installation, les RRs NS de délégation et les RRs glue nécessaires pour rendre la délégation effective devraient être ajoutés à la zone parente. Les administrateurs des deux zones devraient s'assurer que les RRs NS et glue qui marquent les deux côtés de la coupure sont cohérents et le restent.

4.3. Structures internes des serveurs de noms (Name server internals)​

4.3.1. Requêtes et réponses (Queries and responses)​

L'activité principale des serveurs de noms est de répondre aux requêtes standard. La requête et sa réponse sont toutes deux transportées dans un format de message standard décrit dans [RFC-1035]. La requête contient un QTYPE, QCLASS et QNAME, qui décrivent les types et classes d'informations désirées et le nom d'intérêt.

La façon dont le serveur de noms répond à la requête dépend s'il fonctionne en mode récursif ou non :

  • Mode non récursif (Non-recursive mode) : Le mode le plus simple pour le serveur est non récursif, car il peut répondre aux requêtes en utilisant uniquement des informations locales : la réponse contient une erreur, la réponse, ou une référence à un autre serveur "plus proche" de la réponse. Tous les serveurs de noms doivent implémenter les requêtes non récursives.

  • Mode récursif (Recursive mode) : Le mode le plus simple pour le client est récursif, car dans ce mode le serveur de noms agit dans le rôle d'un résolveur et renvoie soit une erreur, soit la réponse, mais jamais de références. Ce service est optionnel dans un serveur de noms, et le serveur de noms peut également choisir de restreindre les clients qui peuvent utiliser le mode récursif.

Quand utiliser le service récursif (When to use recursive service)​

Le service récursif est utile dans plusieurs situations :

  • Un demandeur relativement simple qui manque de la capacité d'utiliser autre chose qu'une réponse directe à la question.
  • Une demande qui doit traverser des protocoles ou d'autres limites et peut être envoyée à un serveur qui peut agir comme intermédiaire.
  • Un réseau où nous voulons concentrer le cache plutôt que d'avoir un cache séparé pour chaque client.

Le service non récursif est approprié si le demandeur est capable de poursuivre les références et intéressé par des informations qui aideront les demandes futures.

Négociation de récursion (Recursion negotiation)​

L'utilisation du mode récursif est limitée aux cas où le client et le serveur de noms acceptent tous deux son utilisation. L'accord est négocié par l'utilisation de deux bits dans les messages de requête et de réponse :

  • Le bit récursion disponible (RA) (The recursion available bit) est défini ou effacé par un serveur de noms dans toutes les réponses. Le bit est vrai si le serveur de noms est disposé à fournir un service récursif pour le client, que le client ait demandé ou non un service récursif. C'est-à-dire que RA signale la disponibilité plutôt que l'utilisation.

  • Les requêtes contiennent un bit récursion désirée (RD) (Queries contain a recursion desired bit). Ce bit spécifie si le demandeur veut un service récursif pour cette requête. Les clients peuvent demander un service récursif à n'importe quel serveur de noms, bien qu'ils ne devraient compter sur sa réception que de serveurs qui ont précédemment envoyé un RA, ou de serveurs qui ont accepté de fournir le service par accord privé ou par d'autres moyens en dehors du protocole DNS.

Le mode récursif se produit lorsqu'une requête avec RD défini arrive à un serveur qui est disposé à fournir un service récursif ; le client peut vérifier que le mode récursif a été utilisé en vérifiant que RA et RD sont tous deux définis dans la réponse. Notez que le serveur de noms ne devrait jamais effectuer de service récursif à moins qu'il ne soit demandé via RD, car cela interfère avec le dépannage des serveurs de noms et de leurs bases de données.

Types de réponse (Response types)​

Si le service récursif est demandé et disponible, la réponse récursive à une requête sera l'une des suivantes :

  • La réponse à la requête, éventuellement précédée d'un ou plusieurs RRs CNAME qui spécifient les alias rencontrés sur le chemin d'une réponse.
  • Une erreur de nom indiquant que le nom n'existe pas. Cela peut inclure des RRs CNAME qui indiquent que le nom de requête d'origine était un alias pour un nom qui n'existe pas.
  • Une indication d'erreur temporaire.

Si le service récursif n'est pas demandé ou n'est pas disponible, la réponse non récursive sera l'une des suivantes :

  • Une erreur de nom autoritative indiquant que le nom n'existe pas.
  • Une indication d'erreur temporaire.
  • Une combinaison de :
    • RRs qui répondent à la question, avec une indication si les données proviennent d'une zone ou sont mises en cache.
    • Une référence aux serveurs de noms qui ont des zones qui sont des ancêtres plus proches du nom que le serveur envoyant la réponse.
    • RRs que le serveur de noms pense seront utiles au demandeur.

4.3.2. Algorithme (Algorithm)​

L'algorithme réel utilisé par le serveur de noms dépendra de l'OS local et des structures de données utilisées pour stocker les RRs. L'algorithme suivant suppose que les RRs sont organisés en plusieurs structures arborescentes, une pour chaque zone, et une autre pour le cache :

  1. Définir ou effacer la valeur de récursion disponible (Set or clear the value of recursion available) dans la réponse selon que le serveur de noms est disposé à fournir un service récursif. Si le service récursif est disponible et demandé via le bit RD dans la requête, aller à l'étape 5, sinon étape 2.

  2. Rechercher les zones disponibles (Search the available zones) pour la zone qui est l'ancêtre le plus proche de QNAME. Si une telle zone est trouvée, aller à l'étape 3, sinon étape 4.

  3. Commencer la correspondance vers le bas, étiquette par étiquette, dans la zone (Start matching down, label by label, in the zone). Le processus de correspondance peut se terminer de plusieurs façons :

    a. Si la totalité de QNAME correspond (If the whole of QNAME is matched), nous avons trouvé le nœud.

    Si les données au nœud sont un CNAME, et QTYPE ne correspond pas à CNAME, copier le RR CNAME dans la section réponse de la réponse, changer QNAME en nom canonique dans le RR CNAME, et revenir à l'étape 1.

    Sinon, copier tous les RRs qui correspondent à QTYPE dans la section réponse et aller à l'étape 6.

    b. Si une correspondance nous ferait sortir des données autoritatives (If a match would take us out of the authoritative data), nous avons une référence. Cela se produit lorsque nous rencontrons un nœud avec des RRs NS marquant les coupures le long du bas d'une zone.

    Copier les RRs NS pour la sous-zone dans la section autorité de la réponse. Mettre les adresses disponibles dans la section additionnelle, en utilisant des RRs glue si les adresses ne sont pas disponibles à partir des données autoritatives ou du cache. Aller à l'étape 4.

    c. Si à une certaine étiquette, une correspondance est impossible (If at some label, a match is impossible) (c'est-à-dire que l'étiquette correspondante n'existe pas), vérifier si l'étiquette "*" existe.

    Si l'étiquette "*" n'existe pas, vérifier si le nom que nous cherchons est le QNAME d'origine dans la requête ou un nom que nous avons suivi en raison d'un CNAME. Si le nom est d'origine, définir une erreur de nom autoritative dans la réponse et sortir. Sinon, sortir simplement.

    Si l'étiquette "" existe, faire correspondre les RRs à ce nœud contre QTYPE. Si certains correspondent, les copier dans la section réponse, mais définir le propriétaire du RR comme étant QNAME, et non le nœud avec l'étiquette "". Aller à l'étape 6.

  4. Commencer la correspondance dans le cache (Start matching down in the cache). Si QNAME est trouvé dans le cache, copier tous les RRs qui lui sont attachés et qui correspondent à QTYPE dans la section réponse. S'il n'y avait pas de délégation à partir des données autoritatives, chercher la meilleure du cache, et la mettre dans la section autorité. Aller à l'étape 6.

  5. Utiliser le résolveur local (Using the local resolver) ou une copie de son algorithme (voir la section résolveur de ce mémo) pour répondre à la requête. Stocker les résultats, y compris les CNAMEs intermédiaires, dans la section réponse de la réponse.

  6. En utilisant uniquement les données locales (Using local data only), tenter d'ajouter d'autres RRs qui peuvent être utiles à la section additionnelle de la requête. Sortir.

4.3.3. Caractères génériques (Wildcards)​

Dans l'algorithme précédent, un traitement spécial a été donné aux RRs avec des noms de propriétaire commençant par l'étiquette "*". Ces RRs sont appelés caractères génériques. Les RRs de caractères génériques peuvent être considérés comme des instructions pour synthétiser des RRs. Lorsque les conditions appropriées sont remplies, le serveur de noms crée des RRs avec un nom de propriétaire égal au nom de requête et un contenu tiré des RRs de caractères génériques.

Cette facilité est le plus souvent utilisée pour créer une zone qui sera utilisée pour transférer le courrier d'Internet vers un autre système de messagerie. L'idée générale est que tout nom dans cette zone qui est présenté au serveur dans une requête sera supposé exister, avec certaines propriétés, à moins qu'il n'existe des preuves explicites du contraire. Notez que l'utilisation du terme zone ici, au lieu de domaine, est intentionnelle ; ces valeurs par défaut ne se propagent pas à travers les limites de zone, bien qu'une sous-zone puisse choisir d'obtenir cette apparence en configurant des valeurs par défaut similaires.

Syntaxe et sémantique des caractères génériques (Wildcard syntax and semantics)​

Le contenu des RRs de caractères génériques suit les règles et formats habituels pour les RRs. Les caractères génériques dans la zone ont un nom de propriétaire qui contrôle les noms de requête qu'ils correspondront. Le nom de propriétaire des RRs de caractères génériques est de la forme *.<anydomain>, où <anydomain> est n'importe quel nom de domaine. <anydomain> ne devrait pas contenir d'autres étiquettes , et devrait être dans les données autoritatives de la zone. Les caractères génériques s'appliquent potentiellement aux descendants de <anydomain>, mais pas à <anydomain> lui-même. Une autre façon de voir cela est que l'étiquette "" correspond toujours à au moins une étiquette entière et parfois plus, mais toujours des étiquettes entières.

Quand les caractères génériques ne s'appliquent pas (When wildcards do not apply)​

Les RRs de caractères génériques ne s'appliquent pas :

  • Lorsque la requête est dans une autre zone (When the query is in another zone). C'est-à-dire que la délégation annule les valeurs par défaut des caractères génériques.

  • Lorsque le nom de requête ou un nom entre le domaine de caractère générique et le nom de requête est connu pour exister (When the query name or a name between the wildcard domain and the query name is known to exist). Par exemple, si un RR de caractère générique a un nom de propriétaire de "*.X", et que la zone contient également des RRs attachés à B.X, les caractères génériques s'appliqueraient aux requêtes pour le nom Z.X (en supposant qu'il n'y ait pas d'informations explicites pour Z.X), mais pas à B.X, A.B.X ou X.

Une étiquette * apparaissant dans un nom de requête n'a pas d'effet spécial, mais peut être utilisée pour tester les caractères génériques dans une zone autoritative ; une telle requête est le seul moyen d'obtenir une réponse contenant des RRs avec un nom de propriétaire avec * dedans. Le résultat d'une telle requête ne devrait pas être mis en cache.

Notez que le contenu des RRs de caractères génériques n'est pas modifié lorsqu'il est utilisé pour synthétiser des RRs.

Exemple de caractère générique (Wildcard example)​

Pour illustrer l'utilisation des RRs de caractères génériques, supposons qu'une grande entreprise avec un grand réseau non IP/TCP veuille créer une passerelle de messagerie. Si l'entreprise s'appelait X.COM, et que la machine passerelle capable IP/TCP s'appelait A.X.COM, les RRs 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 ferait en sorte que toute requête MX pour tout nom de domaine se terminant par X.COM renvoie un RR MX pointant vers A.X.COM. Deux RRs de caractères génériques sont nécessaires car l'effet du caractère générique à *.X.COM est inhibé dans le sous-arbre A.X.COM par les données explicites pour A.X.COM. Notez également que les données MX explicites à X.COM et A.X.COM sont requises, et qu'aucun des RRs ci-dessus ne correspondrait à un nom de requête de XX.COM.

4.3.4. Mise en cache des réponses négatives (Negative response caching) (Optionnel)​

Le DNS fournit un service optionnel qui permet aux serveurs de noms de distribuer, et aux résolveurs de mettre en cache, des résultats négatifs avec des TTLs. Par exemple, un serveur de noms peut distribuer un TTL avec une indication d'erreur de nom, et un résolveur recevant de telles informations est autorisé à supposer que le nom n'existe pas pendant la période TTL sans consulter les données autoritatives. De même, un résolveur peut effectuer une requête avec un QTYPE qui correspond à plusieurs types, et mettre en cache le fait que certains des types ne sont pas présents.

Cette fonctionnalité peut être particulièrement importante dans un système qui implémente des raccourcis de nommage utilisant des listes de recherche car un raccourci populaire, qui nécessite un suffixe vers la fin de la liste de recherche, générera plusieurs erreurs de nom chaque fois qu'il est utilisé.

Méthode d'implémentation (Implementation method)​

La méthode est qu'un serveur de noms peut ajouter un RR SOA à la section additionnelle d'une réponse lorsque cette réponse est autoritative. Le SOA doit être celui de la zone qui était la source des données autoritatives dans la section réponse, ou erreur de nom si applicable. Le champ MINIMUM du SOA contrôle la durée pendant laquelle le résultat négatif peut être mis en cache.

Notez que dans certaines circonstances, la section réponse peut contenir plusieurs noms de propriétaire. Dans ce cas, le mécanisme SOA ne devrait être utilisé que pour les données qui correspondent à QNAME, qui sont les seules données autoritatives dans cette section.

Les serveurs de noms et les résolveurs ne devraient jamais tenter d'ajouter des SOAs à la section additionnelle d'une réponse non autoritative, ou tenter de déduire des résultats qui ne sont pas directement déclarés dans une réponse autoritative. Il y a plusieurs raisons à cela, notamment : les informations mises en cache ne suffisent généralement pas pour faire correspondre les RRs et leurs noms de zone, les RRs SOA peuvent être mis en cache en raison de requêtes SOA directes, et les serveurs de noms ne sont pas tenus de sortir les SOAs dans la section autorité.

Cette fonctionnalité est optionnelle, bien qu'une version raffinée soit attendue pour faire partie du protocole standard à l'avenir. Les serveurs de noms ne sont pas tenus d'ajouter les RRs SOA dans toutes les réponses autoritatives, et les résolveurs ne sont pas tenus de mettre en cache les résultats négatifs. Les deux sont recommandés. Tous les résolveurs et serveurs de noms récursifs sont tenus au moins d'être capables d'ignorer le RR SOA lorsqu'il est présent dans une réponse.

Certaines expériences ont également été proposées qui utiliseront cette fonctionnalité. L'idée est que si les données mises en cache sont connues pour provenir d'une zone particulière, et si une copie autoritative du SOA de la zone est obtenue, et si le SERIAL de la zone n'a pas changé depuis que les données ont été mises en cache, alors le TTL des données mises en cache peut être réinitialisé à la valeur MINIMUM de la zone si elle est plus petite. Cette utilisation est mentionnée à des fins de planification uniquement, et n'est pas encore recommandée.

4.3.5. Maintenance et transferts de zone (Zone maintenance and transfers)​

Une partie du travail d'un administrateur de zone est de maintenir les zones sur tous les serveurs de noms qui sont autoritatifs pour la zone. Lorsque les changements inévitables sont effectués, ils doivent être distribués à tous les serveurs de noms. Bien que cette distribution puisse être accomplie en utilisant FTP ou une autre procédure ad hoc, la méthode préférée est la partie transfert de zone du protocole DNS.

Modèle de transfert de zone (Zone transfer model)​

Le modèle général du transfert ou rafraîchissement automatique de zone est que l'un des serveurs de noms est le maître ou primaire pour la zone. Les changements sont coordonnés au primaire, typiquement en éditant un fichier maître pour la zone. Après l'édition, l'administrateur signale au serveur maître de charger la nouvelle zone. Les autres serveurs non maîtres ou secondaires pour la zone vérifient périodiquement les changements (à un intervalle sélectionnable) et obtiennent de nouvelles copies de zone lorsque des changements ont été effectués.

Détection de changement via SERIAL (Change detection via SERIAL)​

Pour détecter les changements, les secondaires vérifient simplement le champ SERIAL du SOA pour la zone. En plus de tous les autres changements effectués, le champ SERIAL dans le SOA de la zone est toujours avancé chaque fois qu'un changement est effectué dans la zone. L'avancement peut être un simple incrément, ou pourrait être basé sur la date et l'heure d'écriture du fichier maître, etc. Le but est de permettre de déterminer laquelle de deux copies d'une zone est plus récente en comparant les numéros de série. Les avancées et comparaisons de numéros de série utilisent l'arithmétique de l'espace de séquence, il y a donc une limite théorique à la vitesse à laquelle une zone peut être mise à jour, essentiellement que les anciennes copies doivent disparaître avant que le numéro de série ne couvre la moitié de sa plage de 32 bits. En pratique, la seule préoccupation est que l'opération de comparaison traite correctement les comparaisons autour de la limite entre les nombres 32 bits les plus positifs et les plus négatifs.

Paramètres SOA pour le transfert de zone (SOA parameters for zone transfer)​

L'interrogation périodique des serveurs secondaires est contrôlée par des paramètres dans le RR SOA pour la zone, qui définissent les intervalles d'interrogation minimum acceptables. Les paramètres sont appelés REFRESH, RETRY et EXPIRE. Chaque fois qu'une nouvelle zone est chargée dans un secondaire, le secondaire attend REFRESH secondes avant de vérifier avec le primaire pour un nouveau numéro de série. Si cette vérification ne peut pas être complétée, de nouvelles vérifications sont lancées toutes les RETRY secondes. La vérification est une simple requête au primaire pour le RR SOA de la zone. Si le champ de série dans la copie de zone du secondaire est égal au numéro de série retourné par le primaire, alors aucun changement ne s'est produit, et l'attente de l'intervalle REFRESH est redémarrée. Si le secondaire trouve impossible d'effectuer une vérification de série pendant l'intervalle EXPIRE, il doit supposer que sa copie de la zone est obsolète et la rejeter.

Transfert de zone AXFR (AXFR zone transfer)​

Lorsque l'interrogation montre que la zone a changé, alors le serveur secondaire doit demander un transfert de zone via une requête AXFR pour la zone. L'AXFR peut causer une erreur, comme refusé, mais est normalement répondu par une séquence de messages de réponse. Les premiers et derniers messages doivent contenir les données pour le nœud autoritatif supérieur de la zone. Les messages intermédiaires portent tous les autres RRs de la zone, y compris les RRs autoritatifs et non autoritatifs. Le flux de messages permet au secondaire de construire une copie de la zone. Parce que l'exactitude est essentielle, TCP ou un autre protocole fiable doit être utilisé pour les requêtes AXFR.

Chaque serveur secondaire est tenu d'effectuer les opérations suivantes contre le maître, mais peut également effectuer optionnellement ces opérations contre d'autres serveurs secondaires. Cette stratégie peut améliorer le processus de transfert lorsque le primaire n'est pas disponible en raison d'une panne d'hôte ou de problèmes de réseau, ou lorsqu'un serveur secondaire a un meilleur accès réseau à un secondaire "intermédiaire" qu'au primaire.

Dernière mise à jour le