Résumé

  • ZONEMD associe le numéro de série SOA à l’empreinte d’une zone entière ordonnée sous forme canonique, y compris les données de glue et les données occultées. Une copie peut donc être à jour selon le numéro et néanmoins échouer sur son contenu.
  • Avec DNSSEC, l’empreinte peut authentifier l’engagement du producteur ; sans DNSSEC, elle reste un contrôle contre les altérations accidentelles. Dans les deux cas, l’exploitation doit encore prouver l’activation, l’état de la flotte et la capacité de revenir à une génération vérifiée.

Le cas le plus instructif n’est pas celui d’un fichier illisible. C’est celui d’un fichier presque convaincant.

Le transfert AXFR se termine. Le processus récepteur écrit la zone sur disque. Le numéro de série de la SOA correspond au ticket de mise en production. Le parseur accepte le résultat. Pourtant, une adresse de glue manque : une erreur de stockage, une reconstruction incomplète ou deux chaînes de fabrication ayant publié sous le même numéro ont produit un contenu différent. Si cette zone devient active, certaines délégations peuvent devenir injoignables alors que les tableaux de bord annoncent partout la « bonne version ».

RFC 8976 ajoute un objet de preuve adapté à ce défaut. L’enregistrement ZONEMD, placé à l’apex, contient une empreinte cryptographique des données de la zone au repos. Le destinataire reconstruit la même séquence canonique, calcule sa propre empreinte et la compare à celle qui accompagne la zone. Le numéro peut être identique ; l’empreinte, non. Cette dissociation donne à l’étape d’activation un verdict qui n’existait pas dans le seul ordre des versions.

Le numéro de série désigne une génération, pas son contenu

Le champ Serial de la SOA vient de RFC 1035. RFC 1982 a précisé l’arithmétique circulaire permettant de dire qu’une valeur est plus récente qu’une autre malgré le retour à zéro. Cette règle rend possible une décision locale et distribuée : un secondaire peut savoir s’il doit demander une mise à jour sans horloge globale.

Elle ne dit pas que deux zones portant la même valeur sont égales. Le numéro est un choix du producteur, non une mesure dérivée de tous les RR. Une troncature après transfert ne le change pas. Une construction concurrente peut réutiliser accidentellement la même valeur. Une restauration peut réintroduire un fichier altéré dont la SOA reste intacte.

ZONEMD conserve le Serial dans ses propres données RDATA précisément pour attacher l’empreinte à une instance nommée de la zone. Les trois autres éléments sont le schéma de collation, l’algorithme de hachage et le Digest. La SOA répond donc à « quelle génération le producteur annonce-t-il ? » ; ZONEMD répond à « quel contenu complet le producteur a-t-il engagé pour cette génération ? ».

Le transfert ne remplit pas la seconde fonction. RFC 1995 permet de transmettre des différences par IXFR. RFC 5936 définit AXFR comme transfert d’une zone complète. Ces protocoles conduisent une copie vers le destinataire ; ils n’établissent pas, après écriture, passage par un dépôt, redémarrage et chargement, une preuve persistante de l’intégralité de l’objet. C’est ce changement de question — de la livraison à la garde du contenu — qui justifie une politique distincte.

L’empreinte porte sur une zone DNS, pas sur la typographie du fichier

ZONEMD est le type RR 63. Le schéma standardisé par RFC 8976 est SIMPLE, valeur 1, que les implémentations doivent prendre en charge. SHA-384, algorithme 1, est obligatoire à prendre en charge et son résultat complet occupe 48 octets. SHA-512, algorithme 2, devrait l’être et conserve ses 64 octets. Les valeurs actives, privées et non attribuées figurent dans le registre IANA des paramètres DNS.

SIMPLE ne hache pas le texte brut d’un fichier maître. Deux présentations peuvent différer par les commentaires, les espaces ou la casse tout en décrivant les mêmes données DNS. Les RR sont transformés dans la forme filaire canonique sans compression et ordonnés selon RFC 4034, avec un ordre numérique supplémentaire des types pour un même propriétaire. La comparaison vise ainsi la sémantique de la zone plutôt que les habitudes d’un éditeur.

Le périmètre est plus large que ne le suggère l’expression « données signées ». Tous les enregistrements de la zone sont inclus sauf exception définie. La glue est incluse. Les données occultées sont incluses. Les doublons strictement égaux ne comptent qu’une fois. Dans une zone DNSSEC, les enregistrements de sécurité entrent eux aussi dans le calcul, hormis le placeholder ZONEMD de l’apex et la RRSIG qui couvrira l’ensemble ZONEMD final.

Cette portée explique pourquoi ZONEMD complète DNSSEC. DNSSEC authentifie des RRsets et les preuves nécessaires à la validation des réponses. Toute la matière d’une zone distribuée — en particulier certaines données de délégation et de glue — ne se présente pas comme une collection ordinaire de RRsets autoritatifs du child tous signés et validés de la même manière. ZONEMD engage l’objet zone complet destiné aux serveurs autoritatifs, dépôts ou autres consommateurs.

Cette globalité coûte du temps. Avec SIMPLE, modifier un seul RR impose de parcourir de nouveau la zone. RFC 8976 le considère adapté aux zones petites ou stables et potentiellement impraticable pour les zones grandes ou très dynamiques. La mesure utile n’est donc pas une capacité annoncée par le logiciel, mais la marge entre calcul, signature, vérification et le plus court intervalle réel de publication.

Publier correctement exige une séquence contrôlée

Dans une zone signée, ajouter ZONEMD après coup modifierait les bitmaps de types des preuves NSEC ou NSEC3. Le processus commence donc par la suppression des anciens ZONEMD d’apex et de leurs signatures, puis par l’ajout d’un enregistrement placeholder avant la signature DNSSEC. Les preuves de non-existence intègrent alors dès le départ la présence du type.

La zone peut être signée. Le calcul SIMPLE traite ensuite la séquence canonique sans inclure le placeholder d’apex ni la RRSIG qui couvrira plus tard le RRset ZONEMD. L’empreinte remplace la valeur provisoire, puis cette valeur définitive reçoit sa propre signature.

Une règle évite un cercle opérationnel : produire la signature de ZONEMD ne doit pas incrémenter à nouveau le Serial. La SOA et le ZONEMD correspondant doivent être publiés simultanément. Sans cette atomicité, l’acte qui authentifie l’empreinte déplacerait la version qu’elle est censée décrire.

Une preuve de publication exploitable doit donc conserver davantage qu’un digest lu par dig. Elle relie l’identifiant du snapshot source, la politique approuvée, les versions du constructeur et du signataire, le Serial, le schéma, l’algorithme, l’empreinte, les clés DNSSEC et l’heure de bascule. En l’absence de cette chaîne, un incident ne permet pas de situer l’écart entre source, construction, signature et distribution.

Avant de comparer, le vérificateur doit savoir ce qu’il doit exiger

La présence d’un ZONEMD ne suffit pas à choisir le niveau de confiance. Le destinataire détermine d’abord si DNSSEC est attendu, à partir de ses ancres de confiance et, pour une zone non racine, de la chaîne DS validée dans le parent. Le cadre de validation vient de RFC 4035.

Lorsque des signatures sont attendues, l’existence même du RRset ZONEMD doit être validée, ainsi que les signatures de la SOA et de ZONEMD. Une preuve DNSSEC d’absence empêche la vérification du digest ; une preuve qu’il doit exister suivie de son absence dans la copie reçue interdit de conclure au succès. Une signature invalide ne doit pas être transformée silencieusement en simple checksum parce que deux empreintes coïncident.

Le contrôle structurel vient ensuite. Plusieurs ZONEMD peuvent coexister durant une transition, mais chaque couple schéma/algorithme doit être unique. La politique locale peut ignorer un couple qu’elle refuse. Pour chaque candidat accepté, le Serial doit être identique à celui de la SOA, le schéma et l’algorithme pris en charge, la taille du Digest valide, et la valeur recalculée égale à la valeur reçue.

Un seul couple accepté qui correspond suffit pendant une migration. Cette souplesse comporte son propre risque : la sécurité de plusieurs empreintes reste limitée par l’algorithme accepté le plus faible. Une procédure de transition doit donc supprimer l’ancien couple à une date ou condition explicite. Une compatibilité sans sortie n’est plus une migration.

Enfin, le résultat doit conserver sa raison. « ZONEMD absent », « chaîne DNSSEC indisponible », « Serial différent », « couple dupliqué », « algorithme refusé », « taille invalide » et « contenu différent » appellent des responsables et réponses distincts. Les réduire à un unique état rouge empêche précisément l’analyse que le contrôle devait rendre possible.

Sans DNSSEC, le digest n’arrête pas un adversaire

Sur une zone non signée, ZONEMD peut révéler une altération accidentelle : perte d’une partie du fichier, erreur de transmission ou corruption de stockage. Mais un acteur capable de modifier les RR peut recalculer le digest et remplacer l’enregistrement ZONEMD. RFC 8976 décrit donc cette utilisation comme un checksum, non comme une protection réelle contre l’attaque.

DNSSEC authentifie l’engagement et rend détectables sa suppression ou sa modification. Il n’authentifie pas la sagesse de la décision publiée. Un producteur autorisé peut signer une délégation erronée ou une politique mal conçue ; une empreinte parfaite prouve seulement que le récepteur détient ce contenu-là. Elle ne prouve ni propriété du nom, ni conformité au ticket, ni comportement applicatif, ni présence de cette génération sur chaque serveur.

La sécurité du canal reste également un objet différent. RFC 8945 définit TSIG pour authentifier et protéger des transactions DNS avec un secret partagé. C’est une preuve utile sur une session AXFR ou IXFR. Une fois les données écrites, recopiées, restaurées ou rechargées, le MAC de l’ancienne transaction ne suit pas l’objet. ZONEMD rend la vérification reproductible au-delà du canal qui l’a livré.

Même une preuve signée vieillit. Une modification des ancres de confiance ou le retrait d’un DS peut empêcher la validation historique alors que la RRSIG ZONEMD n’a pas encore expiré selon ses propres dates. Une archive sérieuse conserve donc le contexte de confiance utilisé au moment de la décision, et pas seulement le fichier de zone.

Le refus protège l’intégrité et peut dégrader la disponibilité

Un serveur peut vérifier la zone en staging et refuser de l’activer si le digest ne correspond pas. C’est le bénéfice essentiel : une copie corrompue ne devient pas une vérité autoritative.

Mais cette rigueur crée une nouvelle dépendance. Une erreur de publication, un défaut de canonicalisation ou un seul RR manquant peut rendre indisponible le reste d’une zone par ailleurs utilisable. Au moment du contrôle, ces erreurs sont souvent indiscernables d’une falsification. Et si deux fournisseurs autoritatifs appliquent des réponses différentes, ils peuvent servir des générations divergentes.

RFC 8976 évoque donc un déploiement progressif, d’abord en avertissement, ensuite en erreur. L’avis RZERC003 d’ICANN a traité l’arrivée de ZONEMD dans la racine comme un changement coordonné entre le mainteneur, les opérateurs de serveurs racine, les logiciels et les utilisateurs de copies locales. Ce précédent ne dicte pas une politique universelle ; il montre qu’un engagement de contenu traverse plusieurs domaines de panne avant de pouvoir devenir bloquant.

La réponse opérationnelle devrait distinguer trois chemins. Une génération vérifiée devient éligible à l’activation. Une génération qui échoue entre en quarantaine pendant qu’une précédente génération vérifiée continue pour une durée bornée. Enfin, une preuve incomplète — par exemple une panne de chaîne de confiance plutôt qu’une différence de contenu — exige une décision fail-open ou fail-closed attribuée, limitée dans le temps et auditable.

Continuer l’ancienne génération n’est pas gratuit. Son intégrité est connue, mais sa fraîcheur décroît. Le budget acceptable dépend des valeurs refresh et expire, du rythme de changement et de l’impact métier. Le rollback doit donc être préparé comme un produit : objet conservé, digest de nouveau vérifiable, chargement testé et génération observable dans les réponses.

La preuve ne s’arrête pas au serveur de staging

Le DNS autoritatif peut associer plusieurs fournisseurs et des centaines de sites anycast, situation encadrée par RFC 8901. La validation sur une machine ne prouve pas que toute la flotte a chargé la zone. Le succès d’une commande de reload ne prouve pas que le processus la sert. Une requête depuis un réseau ne couvre pas tous les catchments.

Le reçu d’activation doit donc suivre cinq frontières : engagement du producteur ; garde lors du transport ou dans le dépôt ; calcul indépendant du vérificateur ; décision et résultat de chargement ; observation des réponses autoritatives. À chaque étape, il relie l’objet exact, le Serial, le digest, l’identité du système et l’heure.

Les canaris ne doivent pas se limiter à la SOA, sous peine de reproduire l’angle mort initial. Ils interrogent ZONEMD, des noms sensibles aux délégations, des adresses de glue sélectionnées, des RRsets signés et des réponses négatives. Ils enregistrent l’identité autoritative et le point d’observation. Une racine hyperlocale relevant de RFC 8806 a besoin de son propre reçu de copie et de rafraîchissement ; l’état de la racine publique ne prouve pas celui du résolveur local.

Enfin, fermer l’incident exige une preuve négative. Après refus ou rollback, le digest rejeté doit disparaître des objets activables, des processus en service et des réponses échantillonnées. Voir la bonne génération quelque part ne suffit pas si un nœud oublié peut encore servir la mauvaise.

Sources