Résumé

  • ZONEVERSION place l’identifiant de zone dans la réponse autoritative qu’il décrit, au lieu de tenter de reconstituer après coup la correspondance avec une requête SOA séparée.
  • La valeur concerne une réponse observée depuis un point donné : ce n’est ni une empreinte de toute la zone, ni une preuve de convergence, ni une donnée protégée par DNSSEC.

Le piège commence par un voyant vert. Deux sondes interrogent le même nom auprès d’une adresse anycast. Les deux réponses portent NOERROR. Pourtant, l’une livre la nouvelle adresse et l’autre l’ancienne. La première contient un ZONEVERSION SOA-SERIAL de 4 120 ; la seconde, 4 119.

Si l’équipe demande ensuite le SOA, les deux requêtes suivantes peuvent atteindre le site déjà mis à jour. Le journal conservera deux numéros 4 120, mais aura perdu la réponse précise que 4 119 avait produite. RFC 9660 évite cette rupture temporelle : la version accompagne la réponse au moment où le serveur la fabrique.

La scène est illustrative. Elle ne décrit ni panne publique ni comportement d’un logiciel donné. Elle montre aussi ce que l’option ne sait pas faire. Le numéro 4 119 n’explique pas la cause de l’écart. Le 4 120 ne garantit pas que le nouveau contenu soit juste. Une observation ne représente pas toutes les instances autoritatives.

Une question sans version souhaitée

Le demandeur place le code EDNS 19 dans le pseudo-enregistrement OPT. La longueur de l’option vaut zéro : aucune donnée, aucun numéro cible, aucune instruction de bascule. Il demande seulement au serveur d’identifier, s’il peut et s’il le veut, la version de la zone ayant servi à construire cette réponse.

La forme est stricte. Une longueur non nulle ou plusieurs options ZONEVERSION dans la même requête la rendent invalide ; un serveur autoritatif qui met en œuvre le mécanisme répond FORMERR. Ce résultat accuse la sonde, pas la zone. Une investigation sérieuse conserve donc les octets de la requête avant d’interpréter le moindre numéro.

Une requête valide ne force pas le serveur. Il doit comprendre l’option, faire autorité pour une zone englobante pertinente et décider d’honorer la demande. L’absence de réponse ZONEVERSION signifie seulement que cette transaction n’offre pas la corrélation. Elle ne démontre ni retard ni corruption.

L’option est de proche en proche. Un relais ne peut pas recopier aveuglément la question en amont puis coller la valeur reçue dans une réponse qu’il a lui-même reconstruite. La provenance disparaîtrait avec le lien entre producteur, réponse et version.

LABELCOUNT rend le numéro interprétable

La donnée retournée commence par un octet LABELCOUNT, un octet TYPE et une valeur VERSION propre au type. LABELCOUNT compte, depuis la droite, les labels du QNAME original qui forment la zone englobante. Zéro désigne la racine.

Pour hote.branche.example, la valeur 2 pointe vers branche.example, tandis que 1 pointe vers example. Le compteur ne peut dépasser le nombre de labels du QNAME. Extraire « série 4120 » en supprimant la question originale et le compteur revient à perdre la portée du fait.

Une délégation descendante peut porter la version de la zone parente qui a construit le referral. Une réponse négative NXDOMAIN ou NODATA peut identifier la zone qui l’a produite. Certains SERVFAIL le peuvent aussi lorsque le serveur connaît encore la zone autoritative concernée. Plusieurs zones ou types peuvent apparaître, mais jamais deux valeurs pour le même couple TYPE–LABELCOUNT.

Le bon modèle de données n’est donc pas une colonne « version DNS ». Il relie QNAME, zone dérivée, type et valeur au paquet, au serveur, au point de mesure et à l’heure.

Le SERIAL n’est ni une horloge simple ni une empreinte

Le TYPE 0, SOA-SERIAL, est aujourd’hui le type public défini par RFC 9660. Sa valeur copie les quatre octets du champ SERIAL du SOA de la zone. Avec les deux octets d’en-tête, l’option de réponse mesure six octets.

Le nombre reste local à une zone. RFC 1982 impose une arithmétique circulaire sur 32 bits : après bouclage, une valeur numériquement plus petite peut être plus récente. Certaines paires n’ont pas d’ordre défini. Une comparaison entière naïve fabrique donc des faux retours arrière.

Le serial n’est pas non plus un condensat. Une erreur d’exploitation peut maintenir le même serial sur deux contenus différents. Des réponses peuvent différer sous un même serial en raison du contexte de requête ou d’une politique. Il faut comparer les RRsets, les sections, les indicateurs, les TTL et le résultat DNSSEC en plus de l’option.

Pour vérifier tout le contenu d’une zone, RFC 8976 fournit ZONEMD. ZONEVERSION répond « quelle version ce serveur associe-t-il à cette réponse ? ». ZONEMD répond à une question de digest global. Les confondre retire à chacun sa portée probante.

Avec anycast, le serveur est un ensemble à mesurer

Une adresse anycast peut mener à plusieurs instances. Une réponse réussie établit ce qu’un chemin a atteint à un instant donné, rien de plus. La comparaison doit commencer par l’inventaire des NS, des adresses, des préfixes anycast, des cohortes de service et des points d’observation pertinents.

Chaque interrogation directe désactive la récursion et conserve origine, destination, transport, heure, QNAME, RCODE, bit AA, réponse brute, TTL, option et résultat de validation. Des répétitions dans le temps distinguent un écart persistant d’un changement de route ponctuel.

NSID peut aider à reconnaître une instance. Mais sa valeur et son unicité sont définies par l’opérateur ; elle n’est pas authentique par simple présence. Elle complète l’adresse et le point de mesure, elle ne les remplace pas.

Si trois lieux observent durablement 4 120 avec les mêmes octets et un quatrième 4 119 avec l’ancienne adresse, l’équipe peut affirmer un écart borné dans l’échantillon. Elle ne peut pas encore accuser un secondaire. Le journal de transfert, la génération du signataire, la version chargée et le routage vers le site fourniront la causalité.

La signature DNSSEC ne couvre pas l’option

DNSSEC authentifie les RRsets signés selon la chaîne de confiance. Les octets EDNS de ZONEVERSION ne sont pas couverts par RRSIG. Sur un chemin non protégé, un intermédiaire peut modifier ou retirer l’option tout en laissant valider la réponse signée.

Il faut donc séparer deux constats : « le RRset valide » et « le couple réponse–version a une chaîne de garde protégée ». Un transport authentifié et chiffré, TSIG ou SIG(0) peut protéger l’échange selon ses clés et ses extrémités. Il faut en conserver l’identité et le verdict. Cette protection ne garantit toujours ni la justesse du contenu ni la convergence générale.

OPT n’est pas une donnée de zone. Une valeur ZONEVERSION ne doit être ni mise en cache comme un RR, ni transférée, ni réutilisée pour étiqueter une autre réponse. La provenance ne survit que tant que le paquet et son contexte restent ensemble.

Sources