Résumé

  • L’évaluation conclut à l’absence de risque important au sens de la politique RSEP seulement si sept exigences impératives sont respectées et sept choix de conception documentés ; quatre autres pratiques sont recommandées.
  • Ce constat porte sur le mécanisme, pas sur un opérateur. La consultation, un addendum, les demandes individuelles des registres et une procédure distincte sur le texte contractuel restent à venir.

Une conclusion favorable, sous conditions

La formulation décisive du rapport consacré à l’automatisation DNSSEC est conditionnelle. L’évaluation d’Interisle estime que l’automatisation CDS/CDNSKEY ne soulève pas de problème important de sécurité ou de stabilité au sens de la Registry Services Evaluation Policy (RSEP), à condition de respecter sept exigences impératives et de documenter sept éléments de conception. Elle étaye ainsi une détermination préliminaire positive pour le mécanisme. Elle ne dit pas que tous les registres ont été évalués, que chaque mise en œuvre est sûre, ou qu’un opérateur peut activer le service dès aujourd’hui.

Cette nuance se perd facilement : « automatisation DNSSEC » évoque une fonction technique unique, alors que la question posée porte sur un service de registre, ses contrats et un cadre d’examen aux critères volontairement délimités. Le rapport évalue une famille de solutions sous des conditions précises. Chaque opérateur conserve sa propre demande, sa configuration et son parcours contractuel.

La consultation publique de l’ICANN s’est ouverte le 12 octobre 2026. L’organisation demande si l’évaluation cerne correctement les enjeux de sécurité et de stabilité et si les mesures proposées sont suffisantes, proportionnées et applicables. Les contributions sont attendues jusqu’au 23 novembre ; le rapport de synthèse doit paraître le 7 décembre. L’ICANN indique qu’elle examinera les commentaires, modifiera si nécessaire l’évaluation, puis publiera un addendum les analysant. Un projet de libellé d’amendement standard est annoncé dans une procédure ultérieure, distincte.

Il s’agit de décisions différentes. La consultation examine les éléments de preuve et les mesures d’atténuation. Elle n’est ni un vote sur l’intérêt du DNSSEC, ni le texte d’amendement lui-même. Le calendrier confirme que le dispositif reste en construction.

Du travail de normalisation au contrôle des services de registre

Le mandat remonte au 14 septembre 2025. Le conseil d’administration de l’ICANN a accepté les recommandations SAC126 du SSAC et demandé à l’organisation de mettre en place une voie RSEP accélérée, sous réserve de l’absence de problème de sécurité ou de stabilité. La résolution du conseil établit donc un mandat conditionnel, pas une dérogation automatique à la procédure RSEP.

La base technique s’appuie sur des textes publiés. Les RFC 7344, 8078 et 9615 décrivent la maintenance, le retrait et l’amorçage des enregistrements ; la RFC 9975 précise les contrôles de cohérence ; la RFC 10026 formule des recommandations opérationnelles. Le rapport les traite comme un mécanisme composé pour les services DNS tiers : une zone enfant publie des enregistrements CDS ou CDNSKEY, puis le registre parent ou le bureau d’enregistrement parrain ingère ces données, les valide et peut publier l’enregistrement DS correspondant.

La question n’est pas de savoir si ces enregistrements doivent exister, mais quelles garanties permettent à une modification de service de franchir le filtre RSEP. La politique définit la sécurité à partir de la divulgation ou de l’altération non autorisée des données de registre et de certains accès non autorisés ; la stabilité concerne le respect des normes faisant autorité ainsi que le débit, le temps de réponse, la cohérence et la concordance des réponses DNS. Cette délimitation rend l’examen possible.

Elle signifie aussi qu’une conclusion positive ne tranche pas tous les débats sur la gouvernance, la concurrence, la qualité de service ou le choix des titulaires.

Le rapport distingue trois niveaux. Sept exigences impératives sont des conditions préalables ; sept informations doivent rendre visibles les choix de conception de chaque opérateur ; quatre bonnes pratiques renforcent le déploiement, sans être nécessaires à une conclusion positive dans l’état actuel des normes. Les dix-huit éléments forment une grille d’évaluation. Elle peut éviter de refaire toute l’analyse technique à chaque demande, à condition que les opérateurs et les évaluateurs sachent quelles preuves répondent à chaque point et comment les exceptions sont traitées.

Le document précise que ses conclusions portent sur le mécanisme, non sur un opérateur. Chaque registre devra répondre aux éléments dans sa demande. Une réponse lacunaire ou trop générale peut entraîner des échanges supplémentaires ou un renvoi au Registry Services Technical Evaluation Panel. Un second filtre subsiste donc après l’analyse technique : le mécanisme commun est évalué une fois, mais le service proposé et ses contrôles restent examinés individuellement.

Ce que l’évaluation ne résout pas

Trois risques résiduels expliquent la prudence de la conclusion. Dans une configuration à plusieurs signataires, une mise à jour mal conçue pourrait évincer les clés d’un autre prestataire. Les RFC citées n’imposent pas de mécanisme commun de signalement permettant aux titulaires ou aux opérateurs DNS enfants de suivre les événements. Enfin, l’amorçage prévu par la RFC 9615 suppose que les noms d’hôtes des serveurs faisant autorité se trouvent dans des zones signées par DNSSEC ; cette condition limite les cas où cette voie fonctionne.

Le rapport ne dit pas que le mécanisme est inutilisable. Il identifie plutôt les choix et les limites que les opérateurs doivent prendre en charge. Le périmètre exclut les cas où le bureau d’enregistrement exploite aussi le DNS, qui relèvent d’une coordination interne, ainsi que les solutions par push ou par API hors bande. Il ne s’agit pas d’une évaluation universelle de toutes les méthodes d’automatisation des DS.

Séparer les preuves réutilisables de l’autorisation a une utilité pratique. Si l’analyse commune est acceptée, chaque registre n’a pas à repartir de zéro. Mais le dossier public ne démontre encore ni le texte définitif de l’amendement, ni une demande approuvée, une date de déploiement, un nombre de candidats, des coûts, une hausse de l’adoption, moins d’incidents ou un bénéfice pour les clients. Affirmer que la voie accélérée a déjà réduit les coûts ou accru l’adoption dépasserait les preuves disponibles.

Le calendrier publié par l’ICANN fournit une séquence de suivi : le contenu de l’addendum après consultation ; le texte standard ultérieur et sa manière de reprendre les dix-huit points ; puis les demandes RSEP et leurs décisions préliminaires. Ce n’est qu’après ces étapes que registres, bureaux d’enregistrement et titulaires pourront juger si la procédure est prévisible. L’enjeu est qu’un constat technique circonscrit devienne une règle claire et vérifiable, sans être confondu avec une autorisation générale.