Résumé

  • Dans la RFC 10026, clientUpdateProhibited et serverUpdateProhibited n’ont pas la même cible : un état EPP interdit une catégorie de requêtes, pas toute action imaginable sur le domaine.
  • Une rotation de clé ou d’algorithme peut exiger une modification DS malgré le verrou ; la demande CDS/CDNSKEY doit encore être authentifiée, cohérente, sûre pour la validation et acceptée par le parent.
  • L’icône « verrouillé » n’est ni une autorisation ni la preuve qu’aucune donnée n’a bougé. La conclusion exige un reçu qui relie statut, acteur, contrôles, publication, notification et voie de reprise.

Le titulaire consulte son portail : le cadenas est toujours vert. Pourtant, le DS publié dans la zone parente n’est plus celui de la veille. La chronologie paraît contradictoire seulement si le mot « verrou » a reçu, sans preuve, le sens de « personne ne peut rien changer ».

Dans EPP, un statut ne décrit pas une impossibilité physique. Il décrit une relation entre un client, un serveur et une commande. La RFC 10026, publiée en juillet 2026 et cosignée par Steve Sheng et Peter Thomassen, applique cette précision à la maintenance automatisée de la délégation DNSSEC.

Son apport n’est pas d’affaiblir les verrous. Il consiste à refuser qu’un contrôle soit crédité d’un pouvoir situé hors de sa frontière technique.

Deux préfixes, deux détenteurs du levier

La RFC 5731 sépare les statuts commençant par client de ceux commençant par server. Le client sponsor, généralement le bureau d’enregistrement, gère les premiers. Le serveur EPP, généralement le registre, gère les seconds.

clientUpdateProhibited et serverUpdateProhibited imposent tous deux le rejet d’une demande de mise à jour, sauf celle qui retire le statut. Mais le parallélisme lexical masque une asymétrie de pouvoir. Le client ne peut modifier un statut placé par le serveur. Le serveur peut, selon sa politique locale, modifier ou remplacer un statut placé par le client.

Un verrou client protège donc surtout la voie des commandes du bureau sponsor. Il peut limiter les erreurs du portail ou l’abus d’un compte titulaire. Il n’empêche pas le bureau qui l’a placé de le retirer, et il ne rend pas le registre incapable d’agir.

Un verrou serveur ferme la voie du bureau vers le registre. La requête EPP du bureau doit échouer. Il ne prouve pas pour autant que l’opérateur du serveur a détruit sa propre capacité d’appliquer une décision autorisée localement.

Le premier enregistrement sérieux n’est donc pas « verrou présent ». Il doit préciser qui l’a placé, quand, quelle commande il refuse et quels acteurs conservent un levier.

Le DNSSEC ne se prête pas au « régler puis oublier »

Une délégation sécurisée a besoin de continuité cryptographique. Une clé SEP peut être renouvelée ; un algorithme peut ne plus être recommandé ; le service DNS peut changer de fournisseur. Dans chacun de ces cas, le jeu DS du parent doit suivre une transition ordonnée.

Geler toute maintenance au nom d’un verrou ordinaire peut conserver une valeur ancienne tout en détruisant la fonction qu’elle devait protéger. Lorsque la clé référencée disparaît du côté enfant, le validateur ne voit pas une prudente immobilité : il voit une chaîne qui ne se ferme plus.

La RFC 7344 permet à l’enfant de publier CDS ou CDNSKEY pour demander la maintenance du DS. La RFC 9615 traite l’amorçage authentifié lorsqu’aucun DS préalable ne fournit encore de chemin de confiance. Ces signaux ne sont pas des ordres anonymes, mais ils ne s’approuvent pas eux-mêmes.

La RFC 10026 exige ainsi que la maintenance DS automatisée ne soit pas suspendue au seul motif d’un verrou de mise à jour du bureau. Si le registre exécute l’automatisation, son propre verrou de mise à jour ne suffit pas davantage à l’interrompre. L’amorçage initial et les rotations ultérieures suivent la même règle.

Un produit de verrouillage propriétaire peut imposer une cérémonie hors bande plus forte. Sa portée doit alors venir de son contrat et de son implémentation, pas d’une analogie avec un nom EPP.

Une voie ouverte n’est pas une approbation automatique

Le parent ne change pas son DS parce qu’un paquet a franchi la porte. Il doit d’abord établir une intention non ambiguë : CDS et CDNSKEY doivent désigner les mêmes clés, et l’état pertinent doit être vraisemblablement cohérent sur tous les serveurs autoritatifs de la délégation.

Il doit ensuite calculer le jeu DS qui résulterait de la demande et vérifier qu’au moins un chemin de validation DNSSEC resterait valable. Si la cohérence ou la continuité échoue, l’opération est annulée.

Cette chaîne produit des preuves distinctes :

  • le verrou a une portée déterminée ;
  • l’enfant a émis un signal ;
  • ce signal est authentique et cohérent ;
  • le résultat projeté ne casse pas la validation ;
  • le parent compétent a publié la modification.

Le cadenas n’authentifie pas CDS. L’authenticité ne prouve pas l’accord de tous les serveurs. Leur accord ne garantit pas un résultat sûr. Une décision acceptée ne prouve pas sa publication, et la publication ne vide pas instantanément les caches des résolveurs.

La différence avec l’article consacré au contrôle « tous les serveurs autoritatifs » est nette. Ce dernier demande si le service enfant exprime une seule volonté technique. Le présent article demande quel acteur administratif un statut peut effectivement arrêter.

Le verrou du bureau ne protège pas contre le bureau

La justification de la RFC 10026 retire une ambiguïté utile aux slogans de sécurité. Un verrou client ne défend pas contre une action illégitime du bureau ou du registre : le premier peut retirer son statut ; le second peut le remplacer selon sa politique.

Il reste utile contre les commandes ordinaires, les erreurs et certaines compromissions de compte. Mais son modèle de menace a des limites. Une capture d’écran prise avant l’incident atteste l’affichage d’un portail. Elle ne montre ni la lecture serveur du statut, ni l’identité de l’acteur ultérieur, ni le canal d’autorisation, ni les contrôles, ni le diff réellement publié.

Lorsqu’un service commercial nommé « registry lock » ajoute une validation téléphonique, plusieurs approbateurs ou un délai de déverrouillage, le contrôle est matériellement différent. L’audit doit conserver ces règles, y compris l’exception d’urgence et le pouvoir de contournement. Le nom seul reste insuffisant.

Une modification correcte doit être visible aux autres acteurs

Dans le modèle titulaire–bureau–registre, le registre peut automatiser la maintenance directement depuis le signal de l’opérateur DNS enfant. Le bureau n’a alors envoyé aucune commande de mise à jour. Sans reçu, une action correcte devient une surprise institutionnelle.

La RFC 10026 recommande que le registre informe le bureau, notamment par l’extension Change Poll de la RFC 8590 ou un canal équivalent. Les contacts pertinents doivent être avisés dans les situations importantes, et le titulaire doit pouvoir consulter la configuration DS active.

Le parental agent devrait aussi conserver un dossier structuré : horodatage, CDS/CDNSKEY déclencheur, canal de notification, serveurs interrogés, résultats de vérification, décision, jeu DS appliqué ou motif d’annulation.

Avec cette pièce, la phrase « le domaine verrouillé a changé correctement » devient vérifiable. Le verrou a continué de bloquer sa voie ; un signal authentifié est entré par une autre ; les contrôles ont réussi ; le parent a agi ; le bureau a reçu l’avis ; le DNS public montre le résultat.

Une notification absente démontre d’abord un défaut de transparence. Elle ne suffit pas, à elle seule, à prouver que le DS était illicite. Chaque conclusion reste attachée à sa preuve.

La reprise doit survivre à la perte de la clé

L’automatisation ne peut être l’unique canal. L’enfant peut perdre la clé qui authentifie la rotation. Un fournisseur d’un montage multi-opérateur peut cesser de coopérer. Certains opérateurs ne publient pas CDS/CDNSKEY.

La RFC 10026 oblige registres et bureaux à maintenir une autre voie de maintenance DS pour ces cas. Elle peut être manuelle, mais doit rétablir le contrôle quand la preuve en bande n’est plus possible.

Le reçu de reprise doit nommer l’autorité humaine ou organisationnelle, les contrôles hors bande, le DS demandé, la suspension éventuelle de l’automatisation et la condition de reprise. Sinon, « intervention manuelle » devient un nouveau libellé sans frontière.

Une signature d’auteur n’est pas un plan de contrôle

Le RFC Editor attribue la RFC 10026 à Steve Sheng et Peter Thomassen. La fiche IETF de Sheng répertorie aussi les RFC 7485 et 7710. Les archives d’ICANN le présentent en 2022 comme directeur principal du soutien à l’élaboration des politiques ; sa biographie publique actuelle indique qu’il a achevé quinze ans chez ICANN en 2024 et qu’il est docteur de Carnegie Mellon en ingénierie et politique publique.

Ces éléments documentent une contribution au croisement de la technique et des institutions. Ils ne prouvent aucun contrôle personnel sur un registre, un bureau, un parent ou une implémentation. Une RFC de consensus ne transfère pas l’autorité des titulaires à ses auteurs.

La même discipline vaut pour les deux noms étudiés. Celui de l’auteur attribue une contribution. Celui du statut attribue une interdiction. Aucun ne doit recevoir un pouvoir plus large que la trace qui l’accompagne.

Le vrai résultat est un reçu centré sur les acteurs

Pour reconstruire une modification DS, il faut joindre le statut public et le statut serveur, leur auteur et leur horodatage ; l’acteur qui soumet et le canal employé ; les données CDS/CDNSKEY ; l’authentification ; la cohérence autoritative ; la validation projetée ; la politique locale ; puis la décision.

Viennent ensuite l’heure de publication, le DS parent obtenu, le TTL, les notifications, la vérification visible par les résolveurs et la voie de reprise. Le secret n’a pas sa place dans ce dossier ; l’explication de l’autorité et du résultat, oui.

C’est la primauté du code en fonctionnement appliquée au cadenas d’une interface. Le minimum commun protège la continuité DNSSEC authentifiée et une reprise indépendante. Les opérateurs restent libres d’ajouter des verrous plus forts et des contrôles locaux, à condition de dire quel acteur et quelle voie ils lient réellement.

Sources