Résumé

  • La révision 02 de Automating DNS Delegation Management via DDNS est un Internet-Draft DNSOP actif, et non un RFC ni la description d’un déploiement.
  • DSYNC indique où envoyer la demande ; une signature SIG(0), correctement amorcée et limitée au nom de l’enfant, indique qui la demande. Le parent conserve ses contrôles et sa décision.
  • NOERROR atteste réception et acceptation. Le texte dit que la publication est attendue ultérieurement : il ne fournit donc ni preuve de publication, ni preuve de convergence des secondaires, ni preuve d’effet chez les résolveurs.
  • La réponse authentique est une pièce utile, mais son retrait du contexte peut autoriser trop tôt l’arrêt d’un ancien serveur ou la suppression d’une voie de retour.

Une réponse authentique peut rester une promesse

L’automatisation préfère les états courts. Requête envoyée, signature valide, code zéro : le tableau de bord veut afficher « terminé ». Le projet de texte refuse implicitement cette compression. Son NOERROR signifie que le récepteur a accepté la modification et que celle-ci devrait apparaître dans la zone parente à un moment futur.

Ce futur contient plusieurs autorités. Le récepteur peut transmettre la décision à une base, une API ou un générateur de zone. Le primaire doit produire une génération. Les secondaires doivent la charger. Les serveurs faisant autorité doivent ensuite répondre avec le nouvel ensemble NS, glue ou DS. Enfin, les caches exposent encore l’ancien état pendant une durée bornée.

Une signature du récepteur répond à la question « qui a formulé cette réponse ? ». Elle ne répond pas à « quelle génération sert maintenant chaque autorité parente ? ». L’authenticité du message ne change pas la portée du message.

Le statut public doit donc progresser avec des verbes précis : reçu, authentifié, accepté par la politique, placé en provisionnement, publié au primaire, distribué aux secondaires, observé sur l’autorité, puis exposé au-delà de l’horizon des caches. Une seule coche ne peut porter ces significations.

L’amorçage est une attribution d’autorité

Le domaine enfant présente une clé SIG(0). Dans le premier échange, une auto-signature démontre la possession de la clé privée correspondante. Elle ne démontre pas que son détenteur peut administrer la délégation. Le récepteur doit conserver la différence entre clé connue et clé de confiance.

La confiance peut venir d’une KEY publiée dans une zone signée, au sommet de l’enfant ou sous le nom spécial d’un serveur de noms, ou d’une vérification manuelle. La méthode non signée est plus faible : elle reconnaît l’opérateur actuel des serveurs faisant autorité, pas nécessairement le titulaire du domaine.

Cette hiérarchie doit rester dans le reçu. Il faut enregistrer la méthode annoncée par le parent, celle choisie, la chaîne DNSSEC éventuelle, le résultat de validation et le moment où la clé est devenue utilisable. Sinon, « signature valide » masque la décision qui a transformé une possession cryptographique en autorité opérationnelle.

Lors d’un réamorçage, l’ancienne clé de confiance ne doit pas disparaître avant validation de la nouvelle. Cette règle évite qu’un candidat auto-signé, finalement invalide, supprime la dernière voie légitime. C’est un exemple net d’irréversibilité : l’ordre des écritures importe davantage que la réussite individuelle des opérations.

Le parent ne délègue pas sa politique au paquet

La règle ordinaire lie le nom de la clé SIG(0) au nom exact de l’enfant. Une clé compromise ne doit pas modifier la délégation d’un voisin. Si le parent autorise une clé de registraire couvrant plusieurs enfants, cette extension est un choix de politique dont il assume les contrôles.

Après la vérification cryptographique, le récepteur applique encore les vérifications utilisées pour CDS/CDNSKEY ou CSYNC. Il examine la cohérence de la modification, ses règles locales, sa piste d’audit et son intégration au système de provisionnement. Le projet parle d’un déplacement de complexité, non de sa disparition.

DSYNC ne change pas cette répartition. Il permet de découvrir un point de synchronisation. Découvrir un endpoint n’est ni prouver son identité, ni obtenir l’autorisation de toute mutation, ni constater le résultat public.

Le reçu utile associe donc l’endpoint découvert, le transport, l’identité du récepteur, le nom enfant, les RRsets demandés, la clé, la fenêtre anti-rejeu, la version de politique et la décision. Il devient possible de savoir si une panne appartient à la découverte, à l’identité, à l’autorisation, à la politique ou au provisionnement.

Le silence contient plusieurs histoires incompatibles

Sans réponse, l’enfant ignore si la requête s’est perdue, si le récepteur l’a appliquée mais que la réponse s’est perdue, ou si le service est indisponible. Réessayer peut être raisonnable ; conclure que rien n’a changé ne l’est pas.

Le texte propose un délai minimal, un recul exponentiel et un nombre borné de tentatives. Ces paramètres protègent le récepteur et limitent l’orage de requêtes. Ils ne fournissent pas un verdict sur la zone parente.

Chaque tentative doit porter une génération d’intention. Une ancienne demande ne doit pas réapparaître après une décision plus récente. Les temps d’inception et d’expiration de SIG(0) réduisent la fenêtre de rejeu, mais le contrôleur doit encore gérer la supersession et comparer l’état public avant de relancer.

L’observation résout l’ambiguïté mieux que la répétition. On interroge les autorités parentes, on conserve réponse, TTL, validation et génération, puis on compare aux RRsets acceptés. Des réponses divergentes décrivent une publication partielle ; elles ne justifient ni « succès » ni « échec » global.

La zone publique produit un reçu différent

Un primaire mis à jour et un secondaire ancien peuvent coexister. Un résolveur peut légitimement retourner des données en cache après la convergence des autorités. Une application peut continuer grâce à une ancienne voie ou échouer pour une cause extérieure au DNS.

Chaque plan demande son observateur. Le système de provisionnement certifie son écriture. Les serveurs parents montrent leur génération. Les requêtes autoritatives montrent le RRset servi. Les résolveurs illustrent l’exposition. Les sondes applicatives montrent l’effet. Aucune couche ne doit signer le reçu de la suivante.

Le retrait d’un ancien serveur de noms est précisément le moment où cette discipline compte. Le code zéro ne suffit pas. Il faut voir la nouvelle délégation sur le parent, tenir compte de l’ancienne durée de cache et conserver un mécanisme d’arrêt si les autorités divergent.

Le retour arrière exige aussi une génération connue. Rejouer une ancienne requête sans savoir ce qui a déjà été publié peut réintroduire une glue obsolète ou écraser une intention plus récente. Le journal doit conserver l’avant, la demande, l’acceptation et le résultat observé.

Le statut du texte borne toute affirmation

Au gel des preuves, la révision 02 était un travail DNSOP actif, daté du 17 juin 2026, mis à jour dans le Datatracker le 25 septembre et expirant le 19 décembre. L’état du groupe était « Waiting for WG Chair Go-Ahead Other - see Comment Log » ; l’état IESG, « I-D Exists ».

Le Datatracker n’affichait aucun statut RFC visé, tandis que l’en-tête disait Standards Track. Cette divergence ne doit pas être corrigée par l’article. Les valeurs de registre proposées, les exemples et les procédures peuvent encore changer.

Aucune source gelée ne prouve qu’un registre ou opérateur nommé utilise ce mécanisme. La scène d’ouverture est construite. La conclusion porte sur la sémantique des reçus, pas sur un incident réel.

Le bon produit est une chaîne de preuves

La chaîne commence par l’intention de l’enfant et l’état qu’elle remplace. Elle ajoute découverte DSYNC, validation des deux clés, portée du nom, contrôles CDS/CSYNC, réponse et décision de politique. Après NOERROR, elle ne s’arrête pas : elle suit la tâche de provisionnement, les générations parentes, les observations autoritatives, les horizons de cache et l’effet applicatif.

Chaque maillon a un propriétaire, un temps et une empreinte. L’inconnu reste explicite. Une équipe peut alors suspendre le retrait, éviter une relance périmée, réparer un amorçage sans supprimer la bonne clé et expliquer l’endroit exact où la transition s’est arrêtée.

La thèse finale est volontairement étroite : SIG(0) peut authentifier une demande limitée, et NOERROR peut attester son acceptation. La réalité publique commence au reçu suivant.

Sources