Résumé

  • Le DNS originel confiait aux secondaires l’initiative d’interroger périodiquement le primaire. Ce choix économisait sa charge, mais transformait le délai entre deux vérifications en période normale de divergence entre autorités.
  • NOTIFY ne livrait pas une zone à installer : il invitait un secondaire configuré à consulter le numéro de série SOA. IXFR pouvait ensuite fournir les suppressions et ajouts séparant la copie détenue de la version courante.
  • La rapidité restait encadrée par l’arithmétique circulaire des séries, le repli vers AXFR, l’écriture durable, l’activation atomique et, si les pairs le décidaient, l’authentification transactionnelle TSIG.

Quand l’autorité se conjuguait à deux temps

La pluralité des serveurs faisant autorité protège une zone contre la panne d’une machine ou d’un chemin. Elle ouvre aussi une fenêtre délicate : dès que le fichier change, toutes ces autorités ne possèdent plus nécessairement la même vérité opérationnelle.

RFC 1034 organisait la maintenance autour d’une copie primaire et de secondaires qui vérifiaient périodiquement le SOA. Son champ SERIAL indiquait la génération ; REFRESH fixait l’attente normale avant une nouvelle vérification, RETRY le rythme après un échec et EXPIRE la limite au-delà de laquelle une copie impossible à rafraîchir devait cesser d’être servie comme autorité. RFC 1035 précisait les champs sur 32 bits et le transfert intégral AXFR.

Le dispositif avait une vertu : une zone immobile ne provoquait pas de copies inutiles. La plupart des cycles se résumaient à une petite requête SOA. Mais sa cohérence dépendait d’une minuterie. Une modification chargée juste après une interrogation pouvait rester invisible au secondaire jusqu’au prochain cycle. Diminuer REFRESH réduisait l’écart, au prix de davantage de requêtes même lorsque rien ne bougeait.

Il ne faut pas confondre cette divergence avec la persistance des caches récursifs. Tous les serveurs autoritatifs peuvent déjà partager la nouvelle version tandis qu’un résolveur conserve un ancien RR jusqu’à l’échéance de son TTL. À l’inverse, deux résolveurs sans cache peuvent recevoir des réponses différentes si l’ensemble autoritatif n’a pas encore convergé. NOTIFY et IXFR traitent cette seconde situation.

Le coût caché du réveil périodique

Le secondaire gardait l’initiative et sa propre limite d’expiration. Cette autonomie rendait le système récupérable : perdre un message particulier ne condamnait pas la réplication, puisque l’horloge provoquerait une nouvelle vérification. Pourtant, à mesure que les zones grossissaient et changeaient davantage, deux inefficacités apparaissaient. Il fallait interroger souvent pour apprendre vite, et transférer toute la zone pour corriger parfois un seul enregistrement.

RFC 1996 formula nettement le compromis. Des délais de rafraîchissement longs épargnaient le primaire, mais prolongeaient l’incohérence après une mise à jour. DNS NOTIFY ajouta l’interruption au modèle de sondage : le maître pouvait avertir un ensemble connu de secondaires qu’un RR intéressant avait changé.

L’avertissement n’était pas un ordre d’installation. À sa réception, le secondaire devait lancer une requête SOA vers l’un de ses maîtres configurés. Il comparait alors les séries et ne transférait que si sa copie était plus ancienne. Les éventuelles données jointes au NOTIFY n’étaient qu’un indice non sécurisé. La nouvelle voie réduisait l’attente sans déplacer la décision finale.

Par défaut, l’ensemble notifié reprenait les serveurs du RRset NS, sauf celui désigné par le MNAME du SOA. L’administrateur pouvait le modifier et ajouter des serveurs « furtifs », connus seulement par configuration. Le graphe des dépendances AXFR ou IXFR devait rester sans boucle : un secondaire pouvait devenir maître pour d’autres, mais la chaîne devait remonter à un primaire.

Cette architecture distribuait la charge et la connaissance. Elle ne supposait pas que chaque réplique avait un lien direct et permanent avec une source universelle. Elle obligeait cependant à connaître les relations réelles, y compris celles absentes de la zone publiée.

Un coup frappé, pas un colis déposé

NOTIFY fonctionnait au mieux de ses possibilités. Sur UDP, un maître pouvait réémettre jusqu’à recevoir une réponse ou atteindre sa limite, avec temporisation et recul configurables. Un secondaire pouvait entendre plusieurs notifications du même changement, provenant du primaire puis de pairs qui venaient eux-mêmes de se mettre à jour. Il devait éviter que ces doublons déclenchent plusieurs transferts concurrents.

La réponse au NOTIFY signifiait seulement « message reçu ». Elle ne prouvait ni que le transfert avait réussi ni que la nouvelle zone était active. Une source usurpée pouvait provoquer des requêtes SOA inutiles ; un serveur ancien pouvait répondre NOTIMP. Dans les deux cas, le sondage ordinaire demeurait le filet de sécurité.

Voilà pourquoi parler de « poussée de zone » déforme le mécanisme. Le maître poussait l’urgence. Le secondaire gardait la vérification de version, le choix du pair de transfert, le contrôle d’intégrité et le moment de bascule.

Le nombre qui revient à zéro sans revenir au passé

Cette vérification dépend d’un petit champ extrêmement chargé de sens. Un numéro de série sur 32 bits finit par atteindre sa limite et revenir à zéro. Une simple comparaison d’entiers déclarerait alors la nouvelle copie plus ancienne.

RFC 1982 définit donc une arithmétique d’espace de séquence. L’addition est modulaire et limitée ; deux valeurs proches peuvent être ordonnées de part et d’autre du retour à zéro. En revanche, deux séries distantes d’exactement la moitié de l’espace n’ont pas d’ordre défini. Une zone ne doit pas progresser de plus de 2^31−1 pendant un intervalle EXPIRE, faute de quoi un secondaire réellement ancien peut sembler en avance.

Le SERIAL n’est ainsi ni une horloge ni une preuve d’auteur. Il ne dit pas quand le changement fut validé, qui le voulut ou si son contenu est juste. Il affirme seulement une position relative dans une succession autorisée. Cette modestie suffit au protocole, mais interdit de lui attribuer un mandat plus large.

Expédier la modification plutôt que l’archive

NOTIFY accélérait la découverte. RFC 1995 allégeait le rattrapage. Une requête IXFR transporte le SOA et la série que le client détient déjà. Si le serveur a conservé l’historique nécessaire, il renvoie une suite ordonnée de suppressions et d’ajouts conduisant de cette génération à la génération courante.

Chaque différence encadre une transition de série. Modifier un RR revient à supprimer son ancienne forme puis ajouter la nouvelle. Le message ne prétend pas livrer « un changement » valable pour tout état initial : il exprime un chemin depuis X vers Y. Le secondaire ne remplace sa copie qu’après traitement de toute la chaîne.

Le journal des différences n’était pas conçu comme une archive éternelle. Le serveur pouvait purger les anciennes versions, notamment lorsque la réponse IXFR dépasserait la taille d’un AXFR ou lorsque l’historique était plus vieux que EXPIRE. Il pouvait condenser plusieurs générations, ce qui économisait de l’espace mais rendait certains points de départ inconnus. Dans ces cas, le serveur envoyait la zone entière.

Ce repli protégeait l’interopérabilité. IXFR est très efficace pour une petite retouche dans une grande zone, moins utile après une longue déconnexion, une purge de journal ou une transformation massive. Conserver AXFR, c’était admettre que l’optimisation dépend d’une mémoire partagée et que l’état complet reste la preuve de dernier recours.

N’activer que ce qui est complet

La rapidité aurait été dangereuse si une demi-réponse pouvait devenir autorité. RFC 1995 demandait au serveur d’inscrire durablement la nouvelle version avant de la distribuer. Sinon, un crash aurait pu laisser les secondaires avec une génération que le maître redémarré ne possédait plus.

RFC 5936 précisa symétriquement le comportement du client AXFR : recevoir dans un espace séparé, vérifier, puis rendre la nouvelle copie visible par une opération atomique. En cas d’erreur, l’ancienne zone valide continue d’être servie. IXFR impose le même principe : toutes les différences doivent être traitées avant remplacement.

Le parcours comporte donc plusieurs portes. Le signal ouvre une vérification. La série établit qu’une différence existe. IXFR ou AXFR fournit un état candidat. La validation complète autorise la bascule. Fusionner ces étapes donnerait à un paquet rapide un pouvoir que les standards ont précisément refusé de lui accorder.

Sécuriser le trajet sans sanctifier le contenu

Un transfert peut révéler beaucoup de données et modifier ce qu’un serveur publie. RFC 5936 recommande de limiter son accès selon la politique de la zone. RFC 8945 définit aujourd’hui TSIG, une authentification et un contrôle d’intégrité transactionnels fondés sur un secret partagé.

Sur un transfert TCP composé de plusieurs messages, les MAC peuvent être chaînés afin de détecter une altération. Le receveur sait que l’émetteur possède la clé convenue. Il ne sait pas, pour autant, que chaque RR est vrai. TSIG n’assure pas la confidentialité, ne distribue pas les clés et devient lourd lorsqu’un grand nombre de pairs doivent partager des secrets distincts.

Une zone erronée peut être parfaitement authentifiée. Une signature de transaction ne prouve ni propriété juridique, ni intention institutionnelle, ni correction sémantique. Elle protège fidèlement une relation entre deux systèmes. Cette limite n’affaiblit pas TSIG ; elle empêche simplement la sécurité du transport de se transformer en mythe de souveraineté des données.

La leçon discrète de 1996

NOTIFY et IXFR répondent à une question d’autorité distribuée : comment faire changer rapidement un autre opérateur sans administrer directement son serveur ? La réponse fut de découper le pouvoir. Le premier système annonce un événement. Le second vérifie une série auprès d’un maître choisi. Il demande un différentiel lié à son état, accepte éventuellement une copie complète, contrôle la réception et décide de l’activation.

La vitesse ne supprime pas la responsabilité ; elle l’exige plus tôt. Une mauvaise modification peut désormais se propager plus vite. Un journal trop court peut provoquer une vague d’AXFR au retour d’une panne. Un graphe de transferts mal documenté peut cacher un point de dépendance. Une série mal avancée peut bloquer la convergence. Un secret partagé compromis peut authentifier l’imposteur.

L’innovation durable n’était donc pas « pousser le DNS ». Elle consistait à réduire la durée de vie de données d’autorité périmées sans déclarer que le premier avertissement reçu valait vérité. La zone avait appris à frapper ; chaque secondaire restait responsable de ce qu’il décidait de servir.

Sources et limites de preuve

RFC 1034 et RFC 1035 établissent le sondage, les temporisateurs SOA et AXFR. RFC 1982 définit l’ordre circulaire des séries. RFC 1995 décrit IXFR, ses journaux bornés et le repli intégral. RFC 1996 décrit NOTIFY, le graphe configuré et le meilleur effort. RFC 5936 précise l’activation atomique d’AXFR. RFC 8945 encadre TSIG.

Ces textes spécifient des mécanismes ; ils ne mesurent pas une date universelle de déploiement, les valeurs réelles de tous les opérateurs ni un temps mondial de convergence. L’inférence défendue ici porte sur la séparation des fonctions : signaler, comparer, transférer, vérifier et activer.