Résumé

  • Une contribution déposée le 16 octobre demande à l’ICANN de mettre son évaluation de l’automatisation DNSSEC des enregistrements DS en cohérence avec la RFC 10026.
  • Le rapport de juin dit à un endroit que l’automatisation doit s’interrompre sous un verrou de registre, puis indique ailleurs que l’automatisation menée par le registre peut continuer. HR-4 ne traite explicitement que du verrou côté bureau d’enregistrement.
  • L’ICANN prévoit d’examiner les commentaires et pourra mettre à jour l’évaluation. La procédure se clôt le 23 novembre; le rapport de synthèse est attendu le 7 décembre. Aucune décision finale ni clause contractuelle n’a été publiée.

Le débat porte sur une question précise: quel acteur un verrou d’enregistrement limite-t-il lorsque le DS de la zone parente est modifié? C’est le point soulevé dans un commentaire sur l’évaluation de sécurité et de stabilité de l’ICANN consacrée à l’automatisation DNSSEC des enregistrements DS.

Dans sa contribution du 16 octobre, Quynh Nguyen estime que l’évaluation couvre les principaux risques, mais demande une position cohérente sur serverUpdateProhibited. La contribution est présentée à titre individuel; elle ne constitue ni une conclusion de l’ICANN ni un consensus de la communauté. Elle intervient toutefois dans une procédure dont l’évaluation doit servir de fondement technique à un parcours accéléré RSEP pour les registres qui souhaitent automatiser la maintenance des DS.

Le rapport d’Interisle Consulting Group porte la date du 23 juin 2026. Sa section 4.4 reprend la position selon laquelle la maintenance automatique des DS devrait être suspendue lorsqu’un statut serverUpdateProhibited est actif. Elle rappelle que le projet IETF alors cité préconisait l’inverse pour l’automatisation pilotée par le registre: le statut impose au serveur EPP de rejeter les demandes de mise à jour du bureau d’enregistrement, mais n’interdit pas au registre de modifier lui-même les données.

Ce projet est devenu la RFC 10026, publiée en juillet comme BCP 246. Sa section 6.1(2) indique que, lorsque le registre assure la maintenance des DS, l’automatisation ne doit pas être suspendue au seul motif que serverUpdateProhibited est présent. La section 6.2.1 distingue les rôles: le verrou bloque les mises à jour soumises par le bureau d’enregistrement, pas l’action du registre; une notification au bureau d’enregistrement permet de rendre cette action visible.

Le rapport contient aussi une tension interne. La section 4.7 dit que le mécanisme peut fonctionner sous clientUpdateProhibited comme sous serverUpdateProhibited; la section 6.1 répète que ces statuts n’imposent pas l’arrêt de la maintenance lorsque le bureau d’enregistrement peut exercer un droit de retrait de l’automatisation opérée par le registre. Pourtant, l’exigence forte HR-4 ne vise explicitement que clientUpdateProhibited. Nguyen demande une règle univoque, alignée sur la RFC 10026.

La chronologie compte. Le 31 août, le SSAC a publié SAC126v2. Le comité dit avoir aligné son avis sur la RFC 10026, laquelle résout la question de la section 4.4 de la version initiale; la version 1 est retirée. L’évaluation de juin précède donc à la fois la RFC définitive et l’avis actualisé qu’elle examine.

Le commentaire formule d’autres demandes: définir les critères et délais de nouvelle tentative lorsqu’un serveur de noms faisant autorité est déclaré définitivement inaccessible; préciser le traitement des changements de clé retardés par des réponses incohérentes; expliciter les effets d’un retrait de DS; et fixer des attentes minimales de notification et de conservation des traces pour les opérations acceptées ou rejetées. Ce sont les propositions d’une personne, pas des exigences déjà adoptées.

La page de la procédure annonce une synthèse des commentaires, leur examen, puis une éventuelle mise à jour et un addendum. Les contributions sont ouvertes jusqu’au 23 novembre 2026; le rapport doit paraître le 7 décembre. Le projet de texte contractuel du parcours accéléré fera l’objet d’une procédure ultérieure. Ni l’évaluation ni ce commentaire n’autorisent aujourd’hui un déploiement et ne préjugent des clauses à venir.

Sources