Le nombre devenu plus récent après zéro : comment DNS ordonne ses versions sans horloge

Résumé

• Le numéro de série SOA ne date pas une zone. Il place une copie dans une séquence circulaire de 32 bits que chaque secondaire peut comparer localement.
• La RFC 1982 autorise le passage de 4 294 967 295 à zéro, mais refuse d’ordonner deux valeurs séparées exactement par la moitié de l’espace.
• Cette règle n’est fiable que si les copies encore actives restent dans la fenêtre définie avant EXPIRE. Elle ordonne des versions ; elle ne prouve ni la justesse des données, ni leur auteur, ni leur propriétaire.

Le jour où zéro passa devant le maximum

Un secondaire détient la série 4 294 967 295. Le primaire annonce désormais zéro. Un tri numérique classique place zéro en premier et conclut qu’il est plus ancien. Le DNS doit pourtant pouvoir dire le contraire : après la dernière valeur représentable sur 32 bits, zéro est la position suivante.

Interdire ce retour aurait donné une date d’expiration au mécanisme de version. Un compteur fini, utilisé assez longtemps, finit nécessairement par réemployer une valeur. La question décisive n’était donc pas d’éviter le cercle, mais d’y conserver un sens de marche.

Le DNS aurait pu demander une heure absolue, un journal mondial ou une décision du primaire. Il choisit une exigence plus mince : deux serveurs qui observent les mêmes valeurs doivent pouvoir appliquer le même calcul et obtenir le même ordre, sans transformer l’un d’eux en juge permanent.

Une convention inachevée en 1987

La RFC 1034 confie au primaire la coordination des modifications et aux secondaires la vérification périodique du SOA. Chaque modification doit faire avancer SERIAL. REFRESH fixe la prochaine vérification, RETRY la reprise après échec et EXPIRE le moment où une copie impossible à rafraîchir doit cesser d’être servie comme autorité.

La RFC 1035 précise que SERIAL est un entier non signé de 32 bits, conservé par les transferts de zone. Le champ revient à zéro et doit être comparé selon une « arithmétique d’espace de séquence ».

L’intention était claire, la règle générale ne l’était pas. L’héritage des numéros de séquence de transport ne suffisait pas à expliquer comment comparer toutes les paires possibles dans le DNS. Près du point de retour, deux implémentations pouvaient reconnaître le même mécanisme de débordement et néanmoins choisir des copies différentes.

Ce vide minuscule touchait un acte important : accepter qu’un état remplace un autre. Une opération de comparaison tient en quelques instructions ; son résultat distribue pourtant le pouvoir de publier une nouvelle réalité DNS.

Un cercle et un diamètre sans vainqueur

La RFC 1982 apporte en août 1996 la définition manquante. Pour le SOA, les valeurs vont de zéro à 4 294 967 295. L’addition se fait modulo 2^32, avec un incrément défini au plus égal à 2^31−1.

Entre deux valeurs inégales, on regarde le trajet le plus court autour du cercle. Si l’écart est inférieur à la moitié de l’espace, la valeur située en avant sur ce trajet est la plus récente. C’est ainsi que zéro peut suivre le maximum, et qu’une petite valeur numérique peut être postérieure à une grande.

Une paire résiste à la règle. Deux valeurs distantes exactement de 2^31 sont aux extrémités d’un diamètre. Les deux directions ont la même longueur. En choisir une arbitrairement créerait des inversions incohérentes après des incréments identiques. La RFC ne tranche donc pas : les valeurs sont différentes, mais aucune n’est définie comme supérieure ou inférieure.

Cette abstention est une force. Le protocole ne fabrique pas une certitude là où les seules données disponibles n’en contiennent aucune. Il oblige le système d’exploitation à éviter cette situation plutôt qu’à masquer l’ambiguïté derrière un ordre artificiel.

EXPIRE protège la comparaison

Une comparaison circulaire n’a de sens que si les vieilles copies disparaissent avant que la séquence ne leur fasse un tour complet. La RFC 1982 demande de ne pas avancer, en une ou plusieurs étapes, de plus de 2 147 483 647 pendant l’intervalle EXPIRE.

Supposons qu’un secondaire soit isolé. Le primaire continue à modifier la zone et franchit plus d’un demi-espace avant le retour du secondaire. Selon le calcul, l’ancienne copie peut alors paraître en avance. La machine n’a pas voyagé dans le futur ; l’exploitation a rompu l’hypothèse qui rendait la réponse déterministe.

Le système remplace donc l’horloge commune par une promesse de portée limitée. Les serveurs n’ont pas besoin d’être d’accord sur l’heure. Ils doivent être d’accord sur l’arithmétique, limiter la vitesse de progression et retirer l’autorité à une copie dont la fraîcheur ne peut plus être vérifiée.

La règle commune est plus légère qu’une synchronisation mondiale, mais elle dépend d’une discipline réelle. Le code local ne corrige pas une fenêtre d’observation que l’opérateur a laissée se briser.

Corriger un numéro trop grand sans revenir en arrière

L’accident classique n’attend pas le débordement naturel. Un opérateur saisit une série très élevée, la publie, puis tente de la remplacer par la valeur qu’il voulait écrire. Pour l’œil humain, c’est une correction. Pour les secondaires, c’est parfois une ancienne version.

La RFC 2182 déconseille absolument la simple décrémentation. Les serveurs ayant vu le grand nombre peuvent ignorer la correction et toutes les petites augmentations suivantes. La réparation doit avancer dans l’espace défini, par étapes observables, jusqu’à atteindre la région voulue. Chaque secondaire doit suivre chaque transition avant la suivante.

Cette procédure paraît laborieuse parce que l’état est déjà distribué. Modifier le fichier primaire ne retire pas une observation de la mémoire de tous les pairs. La version n’est pas seulement une intention de l’administrateur ; elle est une preuve que d’autres machines ont consommée pour prendre une décision autonome.

La date imprimée dans le nombre

Pour rendre les séries lisibles, la RFC 1912 recommande la convention AAAAMMJJnn. Elle avertit aussi contre les nombres décimaux qui peuvent être convertis de façon surprenante en entier de 32 bits.

Une série comme 2026082201 aide un humain à repérer une édition probable. Elle ne devient pas pour autant une heure attestée. Le protocole ne sait pas si l’horloge du générateur était correcte, si deux systèmes ont écrit le même jour, si la révision a été autorisée ou si la date correspond au moment d’activation.

Le format est une convention locale posée sur une valeur circulaire. Un compteur simple peut être valide ; une date élégante peut être erronée. Confondre lisibilité et preuve ferait entrer dans le champ plus de pouvoir que l’interopérabilité n’en exige.

Le nombre que consomment les autres mécanismes

La série n’agit pas seule. Lors d’un contrôle périodique, le secondaire la compare avant de décider d’un transfert. La RFC 1996 permet à NOTIFY de provoquer ce contrôle plus tôt. Le message ne déclare pas quelle version est légitime ; il invite le destinataire à vérifier.

La RFC 1995 place la série détenue par le client au début d’une demande IXFR. Si le serveur conserve l’historique nécessaire, il renvoie les suppressions et ajouts menant de cette version à la version courante. Sinon, il peut fournir une copie complète.

Le numéro ne contient ni la différence ni la zone. Il affirme seulement une position relative dans une séquence permise. L’intégrité du transfert, la complétude des données et leur activation restent des décisions séparées.

Une règle assez petite pour rester locale

L’élégance historique de la RFC 1982 réside dans sa modestie. Une largeur fixe, une addition bornée, une comparaison reproductible et une limite explicite suffisent à l’accord ordinaire. Chaque serveur peut vérifier l’ordre sans demander la permission d’une institution ou la vérité d’une horloge centrale.

Cette même modestie interdit de tirer du champ ce qu’il ne dit pas. « Y vient après X » ne signifie pas « Y est correct », « Y a été signé par le propriétaire » ou « tous les secondaires servent Y ». Le numéro est un instrument d’ordre, pas un acte de souveraineté sur la zone.

Le protocole le plus responsable n’est pas toujours celui qui répond à toutes les questions. Ici, la place laissée indéfinie à mi-espace rappelle qu’une règle commune doit rester dans les limites de ce qu’elle peut réellement observer.

Sources et limites de preuve

Les RFC 1034 et 1035 établissent le mécanisme initial. La RFC 1912 documente des erreurs d’exploitation et la convention de date. La RFC 1982 définit l’arithmétique. La RFC 2182 décrit l’entretien des secondaires et la récupération après une mauvaise série. Les RFC 1995 et 1996 montrent l’usage du numéro par IXFR et NOTIFY.

Ces textes ne donnent ni date universelle de déploiement ni garantie que toutes les implémentations ont traité zéro correctement. La lecture architecturale — un ordre déterministe et local plutôt qu’une heure centrale — est une inférence. La série ne prouve ni propriété, ni identité, ni vérité du contenu.