Résumé

  • La suggestion ACSP 2026.1 demandait que les DS DNSSEC puissent être mis à jour automatiquement. Le 21 janvier, ARIN a jugé l’idée bénéfique, indiqué qu’elle demanderait un développement de son système de provisionnement, puis renvoyé le sujet à la priorisation interne avant de fermer la suggestion. Aucune mise en production n’est annoncée par cette réponse.
  • La documentation DNSSEC actuelle décrit une saisie ou un import de DS dans ARIN Online. Le guide DNS inverse mentionne aussi Reg-RWS. Une requête API émise sous l’autorité du titulaire n’est pas la même opération qu’une lecture, par ARIN, de CDS ou CDNSKEY publiés dans la zone enfant.
  • Les RFC 7344, 8078 et 9615 proposent des mécanismes de signalisation et de validation, notamment pour l’amorçage sans chaîne de confiance préexistante. Elles ne renseignent pas sur un déploiement chez ARIN.
  • Un éventuel service devrait permettre de distinguer signal reçu, contrôle de l’autorité, décision, publication dans la zone parente et observation indépendante. Cette chaîne de preuves est une proposition éditoriale, pas la description d’un produit existant ni d’un incident.

Le dossier a été fermé, pas la boucle DNSSEC

Le point de départ n’est ni une panne ni une révélation technique. Brandon Applegate a proposé le 7 janvier 2026 qu’ARIN accepte la mise à jour automatique des enregistrements DS, afin que les rotations de clés ne nécessitent plus, à chaque fois, une intervention dans l’interface Web. Sa demande renvoie à trois RFC qui traitent des signaux fournis par la zone enfant et de leur traitement par le parent. ARIN a répondu deux semaines plus tard que l’amélioration serait utile, mais que sa réalisation demanderait un travail de développement.

La suggestion est devenue une entrée du processus de priorisation et de planification; son statut est passé à « Closed ».

Une procédure de consultation sait fermer une demande même quand le service demandé n’existe pas encore publiquement. Cette différence est essentielle dans un registre. Le titulaire qui prépare une rotation ne peut pas se fier à l’état administratif d’une suggestion pour savoir quel DS figure aujourd’hui dans la zone parente. Il lui faut une méthode de modification qu’il est autorisé à utiliser, puis une preuve distincte de la publication.

Les instructions d’ARIN détaillent une voie concrète : sélectionner les zones inverses, coller ou téléverser les données DS, les faire analyser et appliquer les changements. Reg-RWS donne aussi accès à des opérations de gestion de délégation au moyen d’une clé API et d’un compte habilité. Un opérateur peut automatiser l’appel depuis son propre système. Mais cette automatisation présente à ARIN une commande associée à un compte. La suggestion de janvier vise une autre architecture, dans laquelle le parent détecte un signal publié par l’enfant et détermine s’il peut en tirer une modification. Le titulaire n’y disparaît pas : son droit de décider qui entretient sa délégation doit être représenté autrement.

Le DS n’est pas un décor. Dans la zone parente, il rattache la validation DNSSEC à une clé de la zone enfant. Cette zone peut être exploitée par le titulaire des adresses ou par un prestataire DNS. Ce dernier peut publier CDS ou CDNSKEY pour exprimer le nouvel état souhaité; il ne peut pas, du seul fait qu’il exploite des serveurs de noms, écrire dans la zone contrôlée par ARIN. Réciproquement, la possibilité d’envoyer un DS par API ne prouve pas que le registre surveille les signaux DNS et les accepte sans ordre de compte. La frontière est une question de compétence avant d’être une question de logiciel.

L’historique public des versions logicielles d’ARIN mentionne d’anciennes fonctions DNSSEC et de gestion des délégations. Dans les entrées examinées, il n’annonce pas précisément le service automatisé demandé en 2026. Cela borne le constat public; cela ne prouve ni l’absence de travaux internes ni celle d’un futur essai limité. Aucun document retenu ici ne décrit une rotation ratée chez un client d’ARIN, un DS indûment publié ou une panne du DNS inverse. Le dossier permet de poser une question de conception, non d’attribuer un dommage.

Il existe au moins deux problèmes d’authentification

La RFC 7344 définit les signaux CDS et CDNSKEY par lesquels l’enfant exprime l’évolution de la chaîne de confiance souhaitée. La RFC 8078 décrit des procédures de traitement automatique par un agent du parent. Si la délégation est déjà sécurisée, le lien DNSSEC existant peut servir à authentifier une rotation. Lors du tout premier ajout d’un DS, ce lien n’existe précisément pas. Le parent ne peut pas prendre le contenu d’une zone encore non validée comme preuve suffisante de sa propre légitimité sans introduire un raisonnement circulaire.

La RFC 9615 apporte une réponse plus forte à l’amorçage : un signal authentifié par l’exploitant des serveurs de noms peut aider l’agent parent à valider les CDS/CDNSKEY de l’enfant. Son texte est aussi instructif par ses limites. Lorsque tous les noms de serveurs sont situés à l’intérieur du domaine enfant, cette méthode ne dispose pas de la chaîne préexistante nécessaire à l’amorçage. Elle ne règle pas davantage, par simple existence, le choix de l’agent parent, les permissions du titulaire et la procédure applicable aux cas exclus. Pour ARIN, un éventuel déploiement demanderait donc une liste de cas pris en charge et de chemins alternatifs, pas un slogan disant que « la RFC automatise DNSSEC ».

Une rotation ordinaire et un changement de prestataire ne se déroulent pas non plus sur la même horloge. L’ancien opérateur peut encore publier une zone correctement signée tandis que le nouveau prépare ses clés et ses serveurs. Le parent doit savoir quelle délégation fait autorité au moment où il examine les signaux et comment éviter de transformer une coexistence transitoire en ordre contradictoire. La suppression d’un DS mérite elle aussi une politique explicite : elle change la manière dont la validation remonte du parent à l’enfant.

Il n’est pas nécessaire d’affirmer qu’ARIN traite aujourd’hui ces cas de façon dangereuse pour dire qu’un service automatique devra les séparer.

La RFC 9859 permet d’avertir le parent qu’un traitement CDS/CDNSKEY est à vérifier, au lieu d’attendre uniquement un balayage périodique. Une notification peut raccourcir l’attente avant la découverte; elle ne vaut ni authentification, ni décision, ni publication. Il faut ensuite distinguer l’observation du signal, sa validation, son admission, l’écriture effective du DS dans le parent et ce qu’un validateur extérieur voit après sa propre mise à jour. Un accusé de réception réseau ne certifie pas le dernier maillon.

Une preuve accessible au titulaire

Avant les tableaux de bord, ARIN aurait à définir la portée du service si elle le mettait en œuvre. Quelles délégations inverses y entreraient? Le titulaire devrait-il l’activer? Pourrait-il désigner un exploitant DNS, retirer cette autorisation ou suspendre le traitement pendant une migration? La première sécurisation, l’entretien d’une délégation déjà signée et la suppression finale du DS relèveraient-ils de règles différentes? Une réattribution de ressources ferait-elle expirer les anciens mandats?

Ces questions ne sont pas des détails juridiques ajoutés après le code; elles déterminent quel signal le parent peut légitimement lire comme une instruction.

Chaque modification devrait ensuite laisser un reçu compact. Pour une zone donnée, il associerait la version de la règle, l’ancien et le nouveau jeu de DS, le signal retenu, les serveurs effectivement contrôlés, la méthode d’authentification, la base de l’autorisation du titulaire, la décision motivée, puis la version et l’heure de publication de la zone parente. Un refus doit être aussi traçable qu’une acceptation. Le chemin permettant de corriger une erreur ou de revenir à l’état précédent doit être décrit avant qu’il serve.

Le titulaire pourrait consulter le détail; des mesures agrégées pourraient être publiques sans divulguer clés privées, jetons API ni dossiers clients.

Ce reçu n’aurait pas à promettre qu’une réponse aurait changé simultanément chez tous les résolveurs. ARIN peut répondre de la zone dont elle maîtrise la publication et d’une vérification indépendante de cette publication. Les caches et calendriers de rafraîchissement extérieurs restent sous d’autres responsabilités. Un ancien DS observé quelque part n’est pas, à lui seul, la preuve qu’ARIN n’a rien publié. Une mention « publié » dans ARIN Online ne prouve pas davantage que toutes les applications clientes se sont adaptées. Garder ces horloges distinctes est le seul moyen de rechercher précisément une défaillance future.

Le DNS inverse paraît secondaire tant qu’on le compare au transport des paquets. Il ne l’est plus pour une migration d’adresses, l’exploitation de la messagerie, l’attribution d’abus ou la preuve qu’un prestataire a remis les commandes au suivant. Une passation DS ambiguë peut créer des coûts réels; rien dans le dossier examiné n’établit qu’un tel coût s’est produit chez ARIN. C’est précisément avant de disposer d’un cas dommageable qu’un registre et ses titulaires peuvent définir comment constater la bonne exécution.

Sources