Résumé

  • draft-hoffman-duj-06 décrit un paquet DUJS ou DUJ64 qu’un humain transporte d’un service vers l’interface de son opérateur DNS ; ce n’est volontairement pas un protocole de mise à jour automatique.
  • Le traitement atomique évite un demi-changement, mais l’opérateur doit encore établir le pouvoir de l’utilisateur sur la zone, appliquer sa politique locale et constater l’état effectivement servi.

Le troisième ordre ne doit pas casser le premier

Une entreprise doit remplacer un enregistrement de validation et une politique de messagerie. Trois actions voyagent ensemble : supprimer l’ancienne valeur, ajouter la nouvelle, créer un nom spécialisé. Si les deux premières passent et que la troisième échoue, le domaine peut rester dans un état que ni le service demandeur ni son propriétaire n’avaient choisi.

DUJ traite ce problème sans inventer une nouvelle souveraineté. La liste d’actions est ordonnée, et l’opérateur doit vérifier qu’elle peut être appliquée tout entière. Si une action empêche l’application atomique, aucune ne doit être exécutée. C’est une règle transactionnelle forte pour un flux qui, aujourd’hui, repose souvent sur une prose approximative et plusieurs champs de formulaire.

Mais une transaction mauvaise peut être parfaitement atomique. La cohérence n’authentifie pas le service qui a produit la chaîne. Elle ne transforme pas l’accès à un compte DNS en mandat d’entreprise. Elle ne décide pas qu’un enregistrement inconnu est acceptable. Elle ne prouve pas que les serveurs faisant autorité, les secondaires, les résolveurs et le service aval voient déjà le nouvel état.

La discipline éditoriale consiste donc à ne pas donner à l’atomicité un pouvoir qu’elle n’a pas.

Un format volontairement maigre

Une valeur DUJ est un tableau JSON de deux éléments. Le premier est exactement DUJS ou DUJ64. Le second est un tableau non vide de modèles d’action. Chaque modèle contient seulement add ou delete, puis une chaîne au format de fichier de zone de RFC 1035.

Le choix d’un tableau, au lieu d’un objet extensible, réduit la possibilité d’ajouter des champs persuasifs. Une source ne peut pas glisser à côté de l’enregistrement « mise à jour urgente de sécurité » et espérer que l’étiquette remplace l’examen. Le document refuse aussi l’extensibilité silencieuse : une nouvelle version devrait changer l’identifiant initial.

DUJS garde les données relativement lisibles, tout en interdisant commentaires, directives et retours à la ligne incorporés. DUJ64 encode les données en Base64. Il facilite le transport de formes délicates, mais masque volontairement le contenu à la lecture ordinaire. L’utilisateur voit encore l’action ; il ne voit pas nécessairement ce qu’elle fait.

Le Base64 n’est pas du chiffrement. I-JSON n’est pas une signature. Une valeur conforme à RFC 3597 pour un type inconnu ne constitue pas une permission. DUJ améliore la forme d’une demande ; il ne résout pas sa provenance.

Deux sessions, une personne, aucune délégation automatique

La chaîne traverse d’abord la connexion entre le service et l’utilisateur, puis celle entre l’utilisateur et l’opérateur DNS. Le projet indique que l’authenticité et l’intégrité ne sont, sur chaque trajet, pas plus fortes que la connexion correspondante.

La présence de l’humain ne fusionne pas ces deux sessions. L’opérateur voit un compte authentifié qui colle des octets ; il ne sait pas nécessairement quel service les a produits, dans quelle session, ni si un ticket ou une messagerie les a modifiés. Le service, de son côté, ne voit pas la décision locale de l’opérateur.

Il faut donc conserver quatre preuves séparées : l’origine du paquet présenté, l’identité du compte qui le soumet, l’autorisation de ce compte sur la zone visée et la décision de politique appliquée à chaque action. Une interface qui résume tout par « demande valide » efface précisément les distinctions nécessaires lors d’un incident.

L’autorité commence après l’analyse syntaxique

La vérification du format est stricte : I-JSON valide, bon identifiant, au moins une action, FQDN valide sans joker, type reconnu ou représentation générique, Rdata adaptée. Ce filtre empêche de nombreuses erreurs. Il ne répond pas à la question institutionnelle.

Après ce filtre, l’opérateur doit vérifier que l’utilisateur est autorisé à modifier la zone nommée par le FQDN. Il doit aussi tenir compte des coupures de zone : un nom visuellement voisin peut appartenir à une délégation enfant que le compte ne contrôle pas. Il peut refuser un type inconnu au titre de sa politique, même si sa représentation est correcte. Il peut rejeter tout paquet, par exemple une séquence qui ajoute puis supprime le même enregistrement, et devrait en expliquer la raison dans l’interface.

C’est une architecture saine : le format partagé décrit l’intention minimale ; la décision future reste localisée chez l’acteur qui exploite la zone et porte les conséquences.

Une réception qui dit ce qui s’est réellement passé

La répétition complique le vocabulaire de succès. Un ajout peut être ignoré parce que l’enregistrement exact existe déjà. Une suppression peut ne rien faire parce que la valeur n’existe plus. Le projet demande aussi de vérifier l’existence ou l’absence exacte lors du traitement et recommande d’informer l’utilisateur de chaque changement réalisé.

Un simple voyant vert ne suffit donc pas. Une réception exploitable devrait lier l’empreinte du paquet au compte authentifié, à la zone, au fondement de l’autorisation, à la décision locale, à l’état avant/après, aux actions ignorées, à l’identifiant de transaction et à l’instant de validation. Cette réception détaillée est une recommandation opérationnelle de l’Article, pas une exigence déjà formulée dans la révision 06.

Même cette réception ne prouve pas la publication. Le chargement des serveurs faisant autorité peut être différé ; des secondaires peuvent être en retard ; des résolveurs peuvent conserver l’ancienne valeur jusqu’à l’expiration du TTL ; un service de certificat ou de messagerie peut interroger une autre vue. Il faut observer le système en marche, puis distinguer cette observation de la décision finale du service aval.

Le statut exact du texte

La révision 06 a été déposée le 26 septembre 2026 et expire le 30 mars 2027. Datatracker la classe comme Internet-Draft individuel actif, sans flux RFC et sans statut formel dans le processus IETF. Le texte porte une intention Standards Track, mais ce n’est ni une adoption par un groupe de travail, ni un consensus IETF, ni une approbation, ni un RFC.

Le diff gelé entre 05 et 06 ne change que la date, l’expiration et le numéro de révision. Un numéro plus récent prouve une nouvelle soumission, pas un déploiement ou une validation. Les sources ne montrent aucune implémentation, mesure, interopérabilité, adoption ou panne réelle.

Sources