Résumé

  • ZONEMD lie le contenu canonique d’une zone à un numéro de série SOA ; seule une validation DNSSEC appropriée transforme ce contrôle de cohérence en preuve d’origine.
  • Une concordance établit que la copie reçue correspond à l’objet publié. Elle ne prouve ni que les enregistrements étaient souhaitables, ni qu’un rejet immédiat protège mieux le service que la conservation de la dernière zone saine.

Le cas le plus instructif n’est pas celui d’un attaquant. C’est celui d’un administrateur autorisé qui publie proprement une mauvaise adresse. Le numéro de série augmente, le condensat est recalculé, la signature est valide et le secondaire obtient exactement ce qui a été annoncé. L’erreur n’est ni dans le transport ni dans la cryptographie. Elle se trouve dans la décision que ces mécanismes ont fidèlement transportée.

RFC 8976 fournit précisément ce qui manquait aux copies autonomes de zones DNS : un condensat attaché à la zone elle-même. Une zone peut circuler par AXFR, IXFR, HTTP, rsync, archive ou flux de politique. La protection du canal disparaît souvent une fois le transfert achevé. ZONEMD permet de reprendre la copie plus tard et de vérifier son objet canonique, indépendamment des espaces, des commentaires ou des majuscules de sa représentation textuelle.

L’enregistrement se place à l’apex et porte le type 63. Il contient le numéro de série SOA, le schéma d’assemblage, l’algorithme de hachage et le condensat. Le vérificateur doit constater une égalité exacte entre le numéro de série ZONEMD et celui du SOA. Ainsi, l’empreinte n’est pas seulement rattachée à un nom de zone, mais à une version déterminée.

Le schéma SIMPLE reprend l’ordre canonique défini par RFC 4034. Les enregistrements de glue et les données masquées sont inclus ; les doublons strictement identiques ne le sont qu’une fois. Les ZONEMD provisoires de l’apex et la RRSIG qui couvre leur ensemble sont exclus pour éviter une dépendance circulaire. Hors apex, un ZONEMD n’a aucune valeur de vérification selon la norme.

Le registre IANA actuel ne compte qu’un schéma public attribué, SIMPLE avec la valeur 1, et deux algorithmes publics : SHA-384 et SHA-512. Le premier doit être pris en charge, le second devrait l’être. Plusieurs couples uniques peuvent coexister pendant une migration ; un seul couple pris en charge et conforme à la politique locale peut suffire. Conserver indéfiniment l’ancien algorithme revient toutefois à conserver son niveau de confiance.

La procédure de vérification révèle les véritables frontières. Le destinataire détermine d’abord si DNSSEC est attendu. Lorsque c’est le cas, il s’appuie sur ses ancres de confiance et sur les DS validés dans le parent pour savoir si un ZONEMD doit exister. Il valide ensuite SOA et ZONEMD, refuse les couples schéma-algorithme dupliqués, contrôle le numéro de série, les valeurs prises en charge et la longueur, recalcule le condensat de toute la zone, puis compare.

Sans DNSSEC, un adversaire capable de modifier la zone peut simplement recalculer l’empreinte. ZONEMD n’est alors qu’une excellente somme de contrôle contre la corruption accidentelle, la troncature ou la divergence de copies. Avec DNSSEC, l’origine de l’affirmation SOA/ZONEMD peut être reliée à une ancre acceptée. RFC 4033 permet de comprendre cette chaîne et ses propres limites. ZONEMD complète donc DNSSEC au niveau de la zone entière ; il ne le remplace pas.

Même cette preuve renforcée ne connaît pas la vérité métier. Le condensat ne sait pas qu’un MX a été supprimé par erreur, qu’une adresse appartient au site de secours, qu’une règle RPZ bloque trop largement ou qu’une publication a devancé l’autorisation du client. Il affirme seulement : « cet objet canonique est celui dont l’opérateur a publié l’empreinte pour ce numéro de série ». La correction sémantique exige d’autres données et d’autres responsables.

Les produits rendent ce choix visible. Dans la référence actuelle de Knot DNS, zonemd-verify contrôle chaque chargement ou mise à jour, tandis que la génération SHA-384 ou SHA-512 est configurée séparément ; les valeurs par défaut n’activent pas ces actions. Unbound distingue le contrôle, le rejet de l’absence et un mode permissif qui journalise l’échec sans bloquer la zone. PowerDNS propose une commande explicite pour vérifier un fichier. La prise en charge de RFC 8976 n’impose donc pas une conséquence opérationnelle unique.

Cette liberté est nécessaire, car le refus peut à la fois protéger et casser. Le RFC explique qu’un contrôle avant utilisation évite de servir une zone incomplète ou corrompue. Il prévient aussi qu’une seule donnée manquante ou fautive peut rendre indisponible le reste d’une zone saine. Au niveau du résultat, une erreur de génération et une falsification volontaire ont le même aspect : le condensat ne concorde pas.

RFC 5936 fournit un bon précédent pour la continuité. Le client AXFR reçoit un candidat, effectue ses contrôles puis le charge de façon atomique ; s’il détecte une erreur, il élimine ce candidat et continue de servir la version précédente lorsqu’elle existait. Ajouter ZONEMD enrichit les contrôles du candidat. Cela n’oblige pas à détruire l’état sain déjà en service.

La chronologie cryptographique compte également. Le SOA et le ZONEMD correspondant doivent être publiés ensemble. La signature de ZONEMD ne doit pas provoquer une nouvelle incrémentation du SOA qui rendrait immédiatement l’empreinte incohérente. Plus tard, une signature encore dans sa période de validité peut ne plus être vérifiable si le DS ou l’ancre nécessaire a disparu après une rotation de KSK.

SIMPLE doit parcourir la zone entière après chaque changement. RFC 8976 le juge peu adapté aux zones grandes ou très dynamiques lorsque le calcul approche l’intervalle de mise à jour ou de propagation. Knot avertit lui aussi du coût en temps et en processeur. Une règle d’intégrité qui dépasse le budget d’exploitation finit en file d’attente, en retard de publication ou en dérogation d’urgence.

La chaîne de preuve doit donc rester décomposée : le transfert remet un candidat ; ZONEMD compare son identité canonique ; DNSSEC authentifie l’affirmation lorsque la chaîne est disponible ; les contrôles sémantiques cherchent les incohérences ; la politique locale choisit avertissement, quarantaine ou refus ; le chargement sélectionne une version ; les réponses faisant autorité montrent enfin ce qui tourne réellement.

Cette lecture rejoint la discipline des couches exposée par Heng Lu dans Running-Code Primacy, dans son texte sur la spécification initiale minimale et la décision future localisée et dans son analyse des couches de réalité. La règle commune peut rester déterministe ; la réponse à l’échec demeure locale, explicite et vérifiable.

La précision impose aussi de signaler que la page d’errata du RFC conserve une correction relative à un exemple d’annexe dont le condensat SHA-384 privé est affiché trop court. La règle normative des 48 octets ne change pas. Une source fiable peut contenir une erreur circonscrite sans que l’on doive ni l’ignorer ni rejeter tout le protocole.

La vraie question de direction devient alors concrète : quelles zones sont inscrites, quelles ancres et quels algorithmes sont acceptés, combien de temps la dernière version saine peut-elle survivre, et quelle preuve relie finalement la zone admise aux réponses servies ? L’empreinte mérite une confiance exacte — pas une autorité illimitée.