Résumé

  • La consultation de l’ICANN demande si l’évaluation de l’automatisation DNSSEC des enregistrements DS repère les risques et propose des mesures suffisantes, proportionnées et applicables.
  • La conclusion favorable du rapport dépend de sept exigences obligatoires et de sept divulgations propres à chaque opérateur; elle ne vaut pas approbation générale d’un déploiement.

La question des verrous est le point précis à éclaircir avant d’accélérer la procédure DNSSEC. L’avis de consultation publique précise l’échéance et le périmètre de la consultation.

Datée du 23 juin, l’évaluation de 41 pages examine un mécanisme précis. L’opérateur de la zone déléguée publie des enregistrements CDS ou CDNSKEY; le parent — souvent un registre ou un bureau d’enregistrement — les vérifie avant de modifier le DS dans sa zone. Le rapport couvre la maintenance, l’initialisation et le passage à une délégation non signée. Les notifications poussées, les API hors bande et les mises à jour CSYNC sont exclues. Sa conclusion positive ne concerne donc ni tous les moyens de gérer une délégation, ni un opérateur en particulier. Le rapport d’Interisle conclut qu’il n’y a pas de problème significatif de sécurité ou de stabilité si ses conditions sont respectées.

Le premier niveau comprend sept exigences impératives. Le parent doit vérifier qu’une clé correspondant à chaque DS proposé existe et qu’elle signe l’ensemble DNSKEY. Il doit comparer les réponses de tous les serveurs faisant autorité et interrompre l’opération en cas d’incohérence. Il faut aussi conserver une interface manuelle, permettre aux bureaux d’enregistrement de se désinscrire de l’automatisation, traiter correctement la suppression du DS et informer le bureau d’enregistrement lorsqu’un registre effectue lui-même le changement.

Le rapport ajoute sept sujets à documenter : cadence des contrôles, délais, politique multi-signeur, destinataires des alertes et conditions préalables à l’initialisation automatique, entre autres. Quatre bonnes pratiques restent recommandées, sans être des conditions de la conclusion favorable.

Cette séparation donne de la souplesse, mais rend les informations propres à chaque déploiement importantes. Les exigences impératives forment un plancher commun, notamment la cohérence des serveurs exigée par le RFC 9975. Les divulgations doivent préciser des choix qui influent sur le délai de correction d’une erreur ou la capacité d’un titulaire à voir une mise à jour. Sans notification, une requête acceptée, refusée ou devenue obsolète peut rester invisible jusqu’à une panne de résolution. Le rapport identifie cette lacune d’observabilité sans prétendre que le protocole lui-même fournit un canal universel de compte rendu.

La chronologie ajoute une question vérifiable. Le rapport est daté du 23 juin; le RFC 10026 est devenu une bonne pratique actuelle de l’IETF en juillet. La page ICANN de la procédure cite désormais le RFC 10026 parmi les documents d’appui, tandis que le corps de l’évaluation datée de juin conserve la chronologie antérieure du projet. Le RFC 10026 existe désormais et traite notamment des contrôles d’acceptation, des rapports, des verrous et des mises à jour concurrentes. Cela n’annule pas l’évaluation, mais les commentaires peuvent demander comment la liste s’aligne sur ce texte désormais publié.

La différence apparaît dans l’analyse des verrous du rapport. Celui-ci reprend la position de SAC126 : le statut serverUpdateProhibited doit suspendre l’automatisation conduite par le registre, alors que le seul clientUpdateProhibited ne l’interrompt pas. Le projet de l’IETF a retenu l’approche inverse pour le verrou du registre; le RFC 10026 dit que l’automatisation du registre ne doit pas être arrêtée sur ce seul fondement, puisque le registre peut remplacer son propre statut. La possibilité pour le bureau d’enregistrement de refuser l’automatisation constitue le contrôle exprimant une préférence contraire. La liste finale des exigences impératives traite explicitement du verrou client, sans exigence parallèle sur le verrou du registre. Comme la page actuelle de la procédure cite le RFC 10026, les commentaires peuvent demander quelle règle s’appliquera aux demandes ultérieures et au texte contractuel.

En septembre 2025, le conseil de l’ICANN avait chargé l’organisation d’établir une voie RSEP accélérée pour les registres, sous réserve qu’aucun problème de sécurité ou de stabilité ne soit constaté. Il a précisé que les bureaux d’enregistrement peuvent déployer le service sans autorisation de l’ICANN. La procédure RSEP conserve une décision préliminaire et la possibilité de saisir un panel technique. L’évaluation vise donc à rendre les futures demandes plus comparables; elle n’est pas encore une décision d’approbation pour un registre donné. La résolution du conseil et la politique RSEP exposent cette répartition.

Les commentaires peuvent dès lors examiner trois points concrets : les exigences impératives suivent-elles le BCP 246 désormais publié; les divulgations donnent-elles aux titulaires une visibilité réelle sur les délais, les désinscriptions et le rétablissement; et la future modification contractuelle maintiendra-t-elle un examen adapté à chaque architecture ? L’échéance de novembre précède le texte type. Le rapport de synthèse et la procédure ultérieure fourniront donc deux preuves distinctes de la manière dont l’ICANN transforme une évaluation commune en autorisations applicables.