Résumé

  • La révision 02 de draft-ietf-dnsop-delegation-mgmt-via-ddns permettrait à un enfant d’envoyer au parent les modifications exactes de NS, de glue ou de DS par DNS UPDATE signé avec SIG(0), vers une destination annoncée par DSYNC.
  • La première requête est autosignée. Elle établit que l’émetteur possède la clé privée proposée, mais non que cette clé est autorisée à gouverner la délégation. Le récepteur doit la conserver comme known avant de la promouvoir éventuellement en trusted.
  • Une trace de transition d’autorité devrait relier ancienne clé, méthode d’amorçage, preuves, politique, acceptation puis publication effective. Il s’agit d’une recommandation de gouvernance, non d’une obligation DNSOP.

Le message d’amorçage contient une tension remarquable. Il demande au parent de supprimer l’ancien jeu de clés et d’ajouter la nouvelle clé ; puis il signe cette demande avec la clé nouvelle. La vérification cryptographique peut être impeccable. Elle ne fournit pourtant aucune réponse indépendante à la question « qui vous a donné ce pouvoir ? ».

La distinction est centrale pour une délégation DNS. Les enregistrements NS, les données de glue et les enregistrements DS relient le nom de l’enfant au service qui l’exploite et, le cas échéant, à sa chaîne DNSSEC. Lorsque les données du parent et celles de l’enfant divergent, le service peut continuer à fonctionner par un chemin restant. La perte de redondance n’apparaît vraiment qu’à la panne suivante.

Le projet Automating DNS Delegation Management via DDNS, révision 02, a été publié le 17 juin 2026. C’est un Internet-Draft actif du groupe DNSOP, donc un document de travail susceptible d’évoluer ou d’expirer. L’en-tête rendu indique Standards Track, alors que la fiche Datatracker ne renseigne pas de statut RFC visé. Ce n’est pas un RFC, et sa publication ne démontre aucun déploiement.

L’objectif opérationnel est raisonnable. Les scanners CDS et CSYNC obligent le parent à interroger périodiquement de nombreux enfants. Ici, l’enfant qui vient de changer sa configuration calcule la différence et la pousse au moyen d’un DNS UPDATE sécurisé. Le parent annonce, dans DSYNC, qu’il accepte ce mécanisme et indique l’adresse du récepteur. Le délai de convergence peut baisser, la charge de balayage aussi, et un enfant non signé peut participer.

Le déplacement de la charge déplace aussi la responsabilité de preuve.

Une signature n’est pas une procuration

DNS UPDATE transporte une modification précise. SIG(0) permet d’attribuer le paquet à la possession d’une clé privée et d’en protéger l’intégrité. Si la clé publique figure déjà dans l’ensemble de confiance du récepteur, cette vérification est très utile. Lors du tout premier échange, c’est justement cette confiance qui manque.

Le projet souligne que la primitive de signature peut être aussi robuste que celle employée par DNSSEC, sans partager automatiquement son modèle de confiance. DNSSEC permet normalement de suivre une chaîne jusqu’à une ancre configurée. Une clé SIG(0) de mise à jour est acceptée individuellement, après amorçage. La taille d’algorithme ne tranche pas la question institutionnelle.

Le récepteur n’est donc pas un serveur qui écrit aveuglément tout paquet bien signé dans la zone parente. Il peut être séparé du serveur primaire, exploité par le parent ou confié à un tiers, par exemple un registrar. Il doit limiter la portée aux données prévues, appliquer les contrôles de correction associés à CDS et CSYNC, conserver une piste d’audit et intégrer la demande au système de provisionnement réel.

La règle ordinaire lie aussi le nom de la clé au nom de l’enfant : une modification de child.parent. doit venir d’une clé de confiance nommée child.parent.. Cette limitation empêche la clé d’un enfant de modifier son voisin. Si le parent accepte à la place une clé de registrar capable de gérer de nombreux enfants, il doit assurer par un autre mécanisme l’autorisation de chaque opération.

La portée répond à « quel objet ? ». L’amorçage doit encore répondre à « au nom de quelle autorité ? ».

Le statut known protège le temps de la décision

Lorsqu’une autosignature se vérifie, le récepteur peut apprendre la nouvelle clé. Le projet nomme cet état known. La promotion en trusted n’intervient qu’après une validation distincte, automatique ou manuelle. Un échec de validation maintient la nouvelle clé hors de l’ensemble de confiance et conserve l’ancienne.

Cette temporisation bloque une attaque élémentaire. Un adversaire peut fabriquer sa propre paire, présenter la clé publique et signer la demande avec la clé privée correspondante. Si la demande supprimait immédiatement l’ancienne clé, le simple fait de tenter un amorçage provoquerait déjà une éviction. Le texte impose au contraire de ne jamais retirer la clé précédemment approuvée avant validation de sa remplaçante.

Dans un logiciel, cette nuance mérite plus qu’un commentaire. Une base qui ne conserve qu’un champ active, ou un écran qui affiche « clé reçue » comme « clé approuvée », détruit la séparation. Il faut pouvoir voir la proposition, la preuve de possession, la validation en cours, son résultat, la promotion et la révocation comme des événements différents.

Trois chemins automatiques, trois qualités d’identité

Un enfant signé peut publier sa clé SIG(0) au sommet de sa zone. Le récepteur la récupère et valide la chaîne DNSSEC. Un enfant non signé peut parfois s’appuyer sur la zone signée d’un de ses serveurs de noms : l’opérateur de ce serveur republie la clé sous un nom spécial, et la preuve DNSSEC porte alors sur cette publication. Cette méthode ajoute une coordination avec le fournisseur DNS que le projet recommande de signaler, sans en normaliser le processus interne.

Lorsque ni l’enfant ni un emplacement de serveur utilisable ne fournit une chaîne, le récepteur peut recourir à la méthode unsigned. Il observe la même clé depuis plusieurs points du réseau, à plusieurs moments et, si possible, via plusieurs transports. Cette constance rend une interception ponctuelle plus difficile. Elle établit toutefois le contrôle durable des réponses faisant autorité, non l’identité du titulaire. Le projet la présente comme la méthode automatique la plus faible.

Enfin, l’amorçage manuel peut employer un portail authentifié, un formulaire, un échange de support ou une procédure propre au parent. Le mot « manuel » ne mesure pas sa qualité. Une vérification du titulaire fondée sur un registre d’autorité, avec défi lié et double contrôle, peut être forte ; un courrier récupérable par la même boîte que le compte compromis peut être faible.

Le choix d’une méthode doit donc commencer par le principal que l’on entend autoriser. Exploitant DNS actuel, titulaire, compte registrar et administrateur de la zone signée peuvent être la même personne ; ce n’est pas garanti. Une preuve exacte d’un principal ne doit pas être présentée comme preuve d’un autre.

L’annonce des capacités fait partie de la décision

Le parent peut publier au point cible DSYNC un enregistrement SVCB dont le paramètre bootstrap énumère les méthodes proposées : validation au sommet, validation par un serveur de noms, méthode non signée ou procédure manuelle. L’enfant choisit une méthode qu’il peut satisfaire.

Cette souplesse crée un risque de rabaissement. Si l’annonce n’est pas protégée, un attaquant capable de la forger peut cacher une méthode plus forte et orienter l’enfant vers unsigned. Le projet recommande au parent disposant de DNSSEC de signer l’annonce et à l’enfant de préférer la méthode disponible la plus forte.

Un journal qui conserve seulement « méthode utilisée : unsigned » est alors incomplet. Il devrait également garder l’ensemble annoncé, l’état de validation de cette annonce, les capacités de l’enfant et la règle de sélection. On peut réussir le test choisi après avoir manipulé le choix du test.

NOERROR ne signifie pas « visible »

Après amorçage, un UPDATE signé par la clé de confiance passe encore par la politique locale et les contrôles de correction du parent. La réponse NOERROR confirme réception et acceptation ; le projet précise que la modification doit être attendue dans la zone parente ultérieurement. L’étape de publication reste donc ouverte.

Confondre ces instants est dangereux lors d’une migration. Si l’enfant retire trop tôt les anciens serveurs, la délégation visible peut pointer vers une configuration intermédiaire. Si la supervision clôt le changement à la réponse, elle ne mesure pas le retard du provisionnement ni une divergence entre serveurs faisant autorité.

Quatre états doivent rester observables : le récepteur connaît la clé ; il lui fait confiance ; il accepte l’UPDATE ; la zone parente publie le résultat. BADKEY, clé connue mais non approuvée, refus de politique et délai de publication demandent des remèdes différents. Une seule étiquette « échec DNS » ne guide personne.

L’autre sens de l’authentification compte aussi. Le parent valide la clé de l’enfant, mais l’enfant doit valider la clé du récepteur pour croire ses réponses d’état. Sans cela, une réponse forgée peut provoquer un nouvel amorçage inutile. Elle ne permet pas de modifier la délégation, mais elle peut perturber le service. Une transaction possède deux locuteurs ; sécuriser un seul sens n’en fait pas un dialogue fiable.

Construire une trace de transition d’autorité

Je propose de conserver une trace d’autorité pour chaque amorçage et réamorçage. Ce n’est pas un nouveau format IETF. C’est la preuve opératoire que l’état trusted résulte d’une décision explicable plutôt que d’une vérification circulaire.

La trace identifie parent, enfant, récepteur, réponse DSYNC, version de politique, ancienne clé de confiance et empreinte de la clé proposée. Elle lie l’UPDATE initial, son autosignature, les horaires, la liste des méthodes annoncées et la méthode sélectionnée.

Elle indique ensuite le principal autorisé et la preuve employée. Pour DNSSEC : noms interrogés, chaîne, validateurs et résultat. Pour unsigned : points d’observation réellement indépendants, moments, transports, réponses complètes et verdict de constance. Pour une procédure manuelle : session authentifiée, rôle vérifié, défi, approbateur, exception et chemin de récupération, avec des références contrôlées plutôt que des données personnelles publiques.

La décision enregistre séparément les passages known, validation, trusted, remplacement et révocation. Elle démontre que l’ancienne clé a survécu jusqu’au succès de la nouvelle. L’UPDATE opérationnel qui suit ajoute le delta NS/glue/DS, le verdict de politique, la réponse et l’identifiant de provisionnement. Une observation finale date l’apparition réelle des RRsets sur les serveurs du parent.

L’automatisation mérite d’être adoptée lorsqu’elle raccourcit le délai sans raccourcir la mémoire. Le paquet autosigné peut présenter une clé. Seule une chaîne d’autorité vérifiable peut lui donner le droit de commander.

Sources

  1. Automatisation de la gestion des délégations DNS par DDNS — révision 02
  2. Fiche Datatracker du projet DNSOP
  3. Historique du projet
  4. Documents DNSOP
  5. Groupe de travail DNSOP
  6. RFC 9859 — Notifications DNS généralisées
  7. RFC 2136 — Mise à jour dynamique du DNS
  8. RFC 2931 — Signatures de requêtes et transactions DNS
  9. RFC 3007 — Mise à jour dynamique sécurisée
  10. RFC 8078 — Gestion parentale des enregistrements DS
  11. RFC 7477 — Synchronisation enfant-parent
  12. The Policy Mirror