Résumé

  • Le projet en dernier appel de groupe de travail propose qu'un enfant transmette au parent les changements exacts de NS, glue et DS par un DNS UPDATE ordinaire signé avec SIG(0), après découverte du récepteur par DSYNC.
  • L'auto-signature ne prouve que la possession de la clé privée. Le parent doit conserver la clé comme « connue », puis la promouvoir comme « fiable » selon une méthode d'amorçage explicite.
  • Lors d'un nouvel amorçage, l'ancienne clé fiable ne doit disparaître qu'après validation de sa remplaçante. NOERROR confirme ensuite une acceptation, pas encore une publication ni un résultat de résolution.

Le premier message d'amorçage contient une contradiction apparente : il présente la preuve nécessaire pour vérifier sa propre signature, tout en demandant d'effacer la preuve précédemment admise. Si le récepteur exécutait immédiatement cette suppression, n'importe quel auteur d'une paire de clés pourrait évincer l'autorisation en place avant d'échouer au contrôle suivant.

La révision 02 de draft-ietf-dnsop-delegation-mgmt-via-ddns évite ce piège par deux états. Une clé reçue dont l'auto-signature est correcte devient connue. Le mot décrit une observation et une possession vérifiable, non une délégation de pouvoir. Elle ne devient fiable qu'après le contrôle choisi par le parent. Pendant ce temps, l'ancienne clé reste active. La suppression ne prend effet qu'après la promotion de la nouvelle.

Cette mécanique arrive à un moment éditorial précis. DNSOP a lancé le dernier appel le 20 août, avec le 7 septembre comme date de clôture. Le 4 septembre, un président a réclamé davantage d'avis positifs et de commentaires constructifs : l'absence d'objection ne suffisait pas. Geoff Huston a estimé le mécanisme plus efficace que le balayage parental. Johan Stenstam a insisté sur les zones enfants non signées et a déclaré connaître une implémentation complète dont il est responsable.

Michael Richardson a jugé le texte assez précis pour écrire du code, tout en demandant de mieux rendre le diagramme d'états, la différence KEY/DNSKEY et les questions d'algorithmes. Ce sont des contributions individuelles, non une décision du groupe ni une preuve de déploiement.

Le transport réemploie des briques existantes. L'enfant construit un UPDATE conforme à la RFC 2136 ; SIG(0), selon les RFC 2931 et 3007, protège la transaction. DSYNC, défini par la RFC 9859, publie l'existence et la destination du service. Le récepteur logique peut être séparé du primaire parental et transmettre la demande à une base de provisionnement. Une signature valide n'oblige donc ni à modifier immédiatement le fichier de zone ni à contourner la politique du parent.

Le récepteur doit limiter les changements aux données de délégation prévues et aux opérations KEY encadrées. Par défaut, une clé fiable portant exactement le nom de l'enfant ne peut agir que sur cette délégation. Après authentification, les contrôles de fond issus de CDS/CDNSKEY et CSYNC restent nécessaires. Le push réduit le coût de découverte ; il ne supprime pas l'autorité de décision parentale.

Trois chemins automatiques ne prouvent pas la même chose. Une KEY à l'apex d'un enfant signé peut être validée par DNSSEC. Pour un enfant non signé servi aussi par une zone de serveur de noms signée, le fournisseur peut publier la KEY sous un nom spécial dans sa propre zone signée. Le parent peut également recourir à une vérification manuelle.

Le quatrième cas, celui d'un enfant non signé sans chaîne exploitable, dépend d'observations répétées. Le récepteur compare la KEY annoncée avec les réponses autoritatives vues depuis plusieurs endroits, à plusieurs moments et par plusieurs transports. Cela augmente le coût d'une interception, sans créer un titre juridique. Le projet précise que la méthode authentifie l'opérateur actuel des serveurs autoritatifs, et non le titulaire du nom. Le niveau de confiance dépend donc de la provenance retenue.

La précision lexicale évite une autre fusion. Le protocole utilise le type KEY pour SIG(0), pas DNSKEY. DNSKEY sert à la signature de zone DNSSEC ; KEY sert ici à authentifier une transaction. Une console qui regroupe les deux sous « clé DNS » efface les responsables de stockage, de rotation, de compromission et de preuve.

Les codes de réponse ne ferment pas la chaîne. NOERROR signifie que le récepteur a reçu et accepté l'UPDATE et qu'une modification des données parentales est attendue plus tard. REFUSED peut traduire une politique, une limitation de débit ou une mauvaise configuration. BADKEY signale l'absence de la clé publique nécessaire, sans toujours décrire l'état intermédiaire. L'absence de réponse ne permet pas de savoir quel sens du trajet a échoué.

Un registre exploitable doit relier la découverte DSYNC, l'empreinte de l'UPDATE, les préconditions, l'identité KEY, la méthode d'amorçage, les horodatages known et trusted, la décision du récepteur, le travail de provisionnement, le numéro de série parental, l'observation autoritative et les vues de résolveurs après TTL. Le résultat applicatif vient encore après.

La discipline rejoint celle de Heng Lu : une inscription exacte peut décrire une réalité étroite sans devenir le souverain des réalités suivantes. « Clé connue » peut être parfaitement vrai alors que « autorité établie » reste faux. Le projet peut être techniquement mûr sans être adopté. L'acceptation parentale peut être réelle alors que le DNS public n'a pas encore changé.

Sources