Résumé

  • Le groupe DNSOP a ouvert le Last Call de draft-ietf-dnsop-integration-04 le 24 août 2026, avec une clôture prévue le 7 septembre. L’état relevé dans le Datatracker demeure In WG Last Call : il ne s’agit pas d’un RFC approuvé.
  • Le projet demande aux applications de traiter l’expiration, les changements de statut DNSSEC, la suppression d’un enregistrement attendu et la resynchronisation, pas seulement la preuve initiale de contrôle.
  • Un test minimal peut observer quatre passages : établir, modifier, supprimer, puis transférer ou réenregistrer. Chaque passage doit avoir un déclencheur, un vérificateur, un état d’arrivée et une durée maximale d’obsolescence.
  • Les identifiants d’AT Protocol reposent sur une vérification bidirectionnelle et une nouvelle résolution périodique. Dans l’exemple ENS du projet, l’absence de preuve négative laisse au contraire une ancienne affirmation positive en place jusqu’à son remplacement.
  • Cette matrice est une proposition analytique de Daniel Kade, non un texte adopté par l’IETF. Elle compare des comportements observables sans imposer une architecture unique.

Le 7 septembre n’est pas un verdict technique

L’annonce du groupe DNSOP fixe au 7 septembre la fin du Last Call ouvert le 24 août. Un rappel envoyé la veille invite encore les participants à exprimer leur soutien ou leurs objections. La date marque donc la fin prévue d’une consultation, pas l’approbation du document.

Le Datatracker classe toujours la révision 04 comme Internet-Draft à vocation informative. L’état du groupe est In WG Last Call, celui de l’IESG se limite à I-D Exists. Aucune de ces mentions ne permet de parler d’un RFC, d’un consensus acquis ou d’une publication certaine.

Cette précision n’est pas accessoire. Le projet explique comment une application peut refléter l’autorité publiée dans le DNS. Il faut donc distinguer l’événement vérifiable — l’arrivée à la date limite — de la décision qui n’est pas encore inscrite au dossier.

Un nom importé apporte avec lui ses changements futurs

L’ajout initial est la partie facile à montrer. Un utilisateur place un TXT, lance une vérification et voit son nom apparaître. La révision 04 oblige à regarder ce qui suit.

Sa section consacrée au cycle de vie cite l’expiration, le changement de statut DNSSEC et le retrait d’un enregistrement attendu. Ces événements peuvent modifier le contrôle du domaine ou l’état qui avait justifié l’intégration. Le texte demande aussi que seul le titulaire actuel, ou une personne autorisée, puisse établir le lien ; que les noms techniquement admissibles ne soient pas filtrés par une liste arbitraire de TLD ; et que la resynchronisation avec le DNS mondial soit documentée.

Vérifier sans cesse n’est pas une solution gratuite. Les requêtes coûtent, les caches existent, les pannes peuvent donner un faux signal et une fréquence trop forte peut déclencher des limitations. L’intégrateur choisit donc nécessairement un compromis. La gouvernance commence lorsqu’il rend ce compromis visible.

Voici le test proposé dans cet article :

Passage Question probante État à montrer
Établir Qui prouve le contrôle actuel ou une délégation valide ? Le lien est accepté ou refusé.
Modifier Quelle nouvelle affirmation remplace l’ancienne ? La destination ou l’identifiant change.
Supprimer Comment l’absence devient-elle un signal, et dans quel délai ? Le lien devient invalide, vide ou explicitement périmé.
Transférer ou réenregistrer Comment le nouveau titulaire écarte-t-il l’ancien état ? L’autorité précédente cesse ; la nouvelle repart d’une preuve actuelle.

Pour chaque ligne, l’application devrait indiquer le déclencheur, la méthode de vérification, la règle de cache, la durée maximale de divergence et la procédure de récupération. DNSOP n’a pas adopté ce tableau. Il s’agit d’une manière compacte de mettre à l’épreuve les exigences déjà présentes dans le projet.

AT Protocol prévoit un état invalide

Dans AT Protocol, le nom de domaine lisible reste distinct du DID durable. La spécification des handles demande une vérification dans les deux sens : le handle doit résoudre vers le DID et le document du DID doit renvoyer vers ce handle. Une simple publication unilatérale ne suffit donc pas à usurper le nom d’un compte tiers.

Surtout, la spécification décrit l’après-suppression. Si un handle connu ne résout plus, il doit être marqué comme invalide. Les services peuvent mettre les résultats en cache, mais ils sont invités à refaire la résolution périodiquement. La modification DNS ne déclenche pas nécessairement un événement applicatif ; la prochaine vérification ferme la boucle.

Le délai reste un choix local. Un cache long réduit la charge, au prix d’un affichage erroné plus durable. Une résolution fréquente raccourcit l’écart, mais augmente les requêtes et la sensibilité aux pannes transitoires. L’élément vérifiable est l’existence d’un résultat négatif et d’un chemin pour l’atteindre.

Cette comparaison interdit aussi un raccourci : AT Protocol précise que DNSSEC n’est pas obligatoire pour cette résolution. Le projet DNSOP n’impose pas le même mécanisme à toutes les applications. Il leur demande de décrire comment leur propre mécanisme suit l’évolution du contrôle.

Dans l’exemple ENS, retirer n’équivaut pas à remplacer

L’exemple ENS suit une autre logique. Une preuve DNSSEC positive est soumise à la chaîne. Une preuve positive plus récente peut remplacer l’ancienne ; après un changement de titulaire, le nouveau contrôleur peut rétablir l’intégration avec son propre enregistrement.

Le projet décrit ensuite la faille de fermeture : ENS ne prend pas actuellement en charge les preuves NSEC négatives dans ce parcours. La non-existence ou la suppression de l’enregistrement ne peut donc pas être prouvée sur la chaîne. L’affirmation positive ancienne subsiste jusqu’à l’arrivée d’une affirmation positive plus récente, au lieu d’être révoquée par le seul retrait du TXT ou par la perte du nom.

Ce passage n’est pas une nouveauté de dernière minute. Il figurait déjà dans la révision 03, comme le montre la comparaison avec la révision 04. Il serait donc faux de présenter le Last Call comme la découverte récente du problème.

La documentation d’importation d’ENS donne le geste opérationnel : un nouveau propriétaire modifie le TXT _ens, puis utilise l’action de rafraîchissement pour porter le nouvel état côté ENS. C’est un mécanisme de remplacement positif. Ce n’est pas la détection automatique d’une suppression.

La portée doit rester exacte. Cette limite concerne le parcours décrit, pas tous les usages d’ENS, tous les résolveurs ou toute intégration DNS. Elle révèle néanmoins une question universelle : une architecture qui sait recevoir une preuve positive sait-elle aussi constater que cette preuve n’existe plus ?

Le coût invisible de l’état périmé

L’intégration initiale sert l’acquisition et se prête à une démonstration. La suppression ne crée pas de nouvel utilisateur. Elle consomme des requêtes, du calcul de vérification, des changements d’état, de l’assistance et parfois des transactions. Même sans faute, les incitations favorisent une entrée soignée et une sortie vague.

Les conséquences dépendent de l’usage. Un nom d’affichage périmé peut tromper ; une destination de trafic périmée peut détourner ; un lien utilisé comme droit d’administration, adresse de paiement ou justificatif d’identité peut maintenir une autorité qui n’a plus de base DNS. Il faut donc mesurer l’état applicatif obtenu, pas seulement la possibilité de lire un enregistrement.

L’expiration n’est pas non plus un instant universel. Le cycle de vie des gTLD décrit par l’ICANN comporte plusieurs étapes. La règle utile n’est pas un compte à rebours inventé, mais la déclaration du moment où l’application réagit à chaque événement pertinent.

Le principe de Heng Lu d’une spécification initiale minimale et de décisions futures localisées fournit ici une voie sobre. Les quatre passages peuvent former la base commune ; chaque service garde son résolveur, son système de preuve, sa durée de cache et son processus de secours.

Et si le code en fonctionnement est la preuve première, l’étiquette « vérifié par DNS » ne suffit pas. Le test qui ajoute, remplace, supprime puis réenregistre le nom montre réellement où l’autorité s’arrête.

Sources

  1. Ouverture du Last Call de DNSOP
  2. Rappel du Last Call de DNSOP
  3. Fiche du Datatracker de l’IETF
  4. Historique du document à l’IETF
  5. Projet d’intégration DNS, révision 04
  6. Projet d’intégration DNS, révision 03
  7. Comparaison officielle des révisions 03 et 04
  8. Modifications DNSSEC, RFC 4035
  9. Spécification des handles d’AT Protocol
  10. Synchronisation des dépôts d’AT Protocol
  11. Guide ENS d’importation DNS sur la chaîne
  12. Cycle de vie des gTLD de l’ICANN
  13. Heng Lu — Spécification initiale minimale et décisions futures localisées
  14. Heng Lu — Primauté du code en fonctionnement