Résumé

  • CDS et CDNSKEY expriment l’état de délégation souhaité par l’opérateur DNS enfant. L’agent parental doit cependant authentifier cette intention, interroger toutes les adresses de tous les serveurs faisant autorité, vérifier l’accord des deux formats et préserver au moins un chemin de validation.
  • Une notification peut accélérer la découverte sans autoriser le changement. L’acceptation, l’apparition du DS dans la zone parente, l’expiration des anciennes valeurs en cache et la validation externe doivent être mesurées séparément.

La réponse dissidente

Le nouveau jeu de clés est prêt. La zone enfant sert une DNSKEY signée ainsi que les CDS et CDNSKEY attendus. Trois serveurs répondent avec la nouvelle empreinte. Le quatrième, joint sur une autre adresse du même nom de serveur, renvoie encore l’ancien jeu.

Un contrôle rapide conclurait que le roulement peut commencer. Un agent parental conforme à la règle de cohérence l’annule.

Ce refus n’est pas un incident réel attribué à un opérateur nommé ; c’est le cas analytique qui permet de voir la fonction du protocole. La zone enfant n’a pas publié une intention unique sur l’ensemble de son service faisant autorité. Transformer la majorité des réponses en DS parent reviendrait à inventer quelle version représente la volonté de l’enfant. L’automatisation sûre préfère une attente explicable à une supposition irréversible.

La scène oblige aussi à définir le mot « publié ». Une donnée présente dans le système de provisionnement n’est pas nécessairement servie par chaque secondaire. Une réponse obtenue à proximité n’est pas l’état de toutes les adresses. Un CDS signé n’est pas le DS de la zone parente. Et le DS fraîchement publié n’est pas encore la valeur que détient chaque résolveur récursif.

La coupure de zone distribue l’autorité

DNSSEC construit la confiance entre deux zones grâce au DS publié par le parent. Ce DS désigne une clé DNSKEY de l’enfant. L’enfant peut signer son propre sommet, mais il ne peut pas signer une modification de la zone parente. Le parent, lui, ne choisit pas les opérations internes du serveur DNS enfant ; il publie le lien auquel les validateurs tiers se fient.

RFC 7344 a créé deux formes de signalisation. CDS transporte les données dans un format identique au DS. CDNSKEY transporte la clé à partir de laquelle l’agent parental calcule le DS. Leur publication au sommet de l’enfant décrit les paramètres souhaités, sans fournir une écriture à distance dans le parent.

Cette frontière est utile, car elle évite deux fictions opposées. L’institution parente ne devient pas propriétaire de la clé de l’enfant. L’enfant ne devient pas non plus administrateur de la zone parente. Chacun conserve la responsabilité opérationnelle de sa surface, et un protocole vérifiable organise le passage entre les deux.

L’agent parental peut être un registre, un bureau d’enregistrement, un revendeur ou une autre partie autorisée. Lorsque registre et bureau peuvent tous deux agir, il faut déclarer le canal responsable, l’ordre de priorité et la conduite à tenir après une intervention manuelle. Deux automatisations compétentes peuvent produire une course si aucun acteur ne sait laquelle définit le nouvel état de référence.

Toutes les adresses comptent

RFC 9975 ferme une faiblesse classique des contrôles par échantillon. L’agent parental ne se contente pas d’un serveur choisi arbitrairement. Il récupère, avec un résolveur validant, toutes les adresses de chaque nom de serveur inscrit dans la délégation parente, y compris les colles disponibles. Il interroge ensuite chacune de ces adresses.

La granularité est importante. Un nom peut annoncer plusieurs adresses IPv4 et IPv6. Un service anycast peut exposer des états différents selon le point atteint. Une configuration multi-fournisseur possède plusieurs chaînes de publication. La bonne question n’est donc pas : « le nom de serveur répond-il ? », mais : « les services que la délégation donne aux utilisateurs décrivent-ils une intention plausible et cohérente ? »

NODATA est une réponse, pas une absence de preuve à ignorer. Si les réponses reçues divergent, l’opération doit être abandonnée sans créer, modifier ni supprimer les enregistrements que la procédure aurait touchés. Le parent ne vote pas entre les réponses.

Une adresse muette appelle une autre stratégie : nouvelle tentative, temporisation exponentielle et, si nécessaire, interrogation depuis un autre réseau. L’indisponibilité temporaire n’équivaut ni à l’accord ni au désaccord. Une journalisation sérieuse garde donc trois résultats distincts : réponse incohérente, réponse invalide et absence de réponse.

Deux représentations doivent décrire la même clé

Le choix entre CDS et CDNSKEY déplace le choix du condensat. Avec CDS, l’enfant fournit directement la représentation DS. Avec CDNSKEY, le parent calcule le condensat et peut appliquer sa préférence. Il n’existe pas de mécanisme général permettant à l’enfant de découvrir le format attendu par chaque parent.

La recommandation opérationnelle actuelle est donc de publier les deux, sauf préférence connue. Cette redondance évite une négociation préalable, mais elle n’autorise aucune divergence. Les deux jeux doivent désigner les mêmes clés. L’agent parental qui constate un désaccord ne choisit pas le plus récent, le plus fort ou le plus pratique : il rejette la demande.

Les listes IANA des algorithmes de signature et de condensat restent la référence vivante. Une valeur autrefois courante ne doit pas devenir une hypothèse éternelle cachée dans le logiciel. Le dossier de décision doit conserver la version de la politique cryptographique, le calcul effectué et la raison précise pour laquelle le chemin résultant était acceptable.

La continuité donne sa légitimité au contrôle

Une intention cohérente peut encore casser la délégation. RFC 10026 exige de vérifier que le DS résultant permettrait de continuer à valider DNSSEC. Au moins une clé référencée par le nouveau DS doit valider la signature du jeu DNSKEY enfant avec des paramètres appropriés.

Cette condition autorise le chevauchement nécessaire au roulement et interdit de remplacer l’unique chemin valable par une référence inutilisable. Elle définit aussi une limite institutionnelle nette. Le parent vérifie l’interopérabilité et la sécurité du lien qu’il publie. Il n’a pas besoin d’approuver le fournisseur choisi, l’économie du domaine ou la motivation commerciale de l’opérateur.

Des exigences locales supplémentaires peuvent exister, notamment en matière de cryptographie nationale. Elles doivent être connues, versionnées et reliées à une règle. Un refus opaque augmente la dépendance sans améliorer la sécurité, tandis qu’un échec déterministe peut être reproduit et corrigé.

La primauté du code en fonctionnement apporte ici une discipline. Une recommandation, un enregistrement ou une reconnaissance institutionnelle ne suffit pas. Le nouvel état devient réel lorsque des mises en œuvre compatibles l’authentifient, l’acceptent, le publient et le valident effectivement. Le rôle commun doit rester limité à ce qui protège cette compatibilité.

L’amorçage part de zéro

Lors d’un roulement ultérieur, la délégation existante permet d’authentifier les CDS/CDNSKEY. Lors du premier enrôlement, aucun DS parent ne relie encore la zone enfant à la chaîne de confiance. La signature du sommet enfant ne peut donc pas se certifier elle-même par un lien absent.

RFC 9615 introduit un signal d’amorçage authentifié sous des zones de signalisation signées liées aux serveurs faisant autorité. L’agent parental valide ces zones, retrouve les informations _dsboot propres à l’enfant, puis authentifie les données CDS/CDNSKEY du domaine encore non sécurisé.

Ce mécanisme ne couvre pas toutes les formes de délégation. Les noms très longs et les domaines dont tous les serveurs sont internes au domaine font partie des limites documentées. Une interface ne devrait donc pas annoncer un simple « automatique ». Elle devrait distinguer l’amorçage authentifié, le roulement d’une délégation déjà sûre et le canal conventionnel de récupération.

RFC 8078 définit également un signal explicite de suppression DNSSEC : un CDS avec algorithme 0, type de condensat 0 et condensat 00. La disparition des CDS ne vaut jamais ordre de suppression. Elle peut résulter d’un retard de secondaire ou d’une erreur de publication. La désactivation exige un état reconnaissable, authentifié et traité avec prudence.

La notification n’accorde aucune permission

La recherche périodique de changements peut être lente à grande échelle. RFC 9859 permet au parent de publier un enregistrement DSYNC indiquant où un service accepte les notifications. L’opérateur enfant découvre cette cible et envoie NOTIFY(CDS) lorsqu’un nouveau jeu apparaît.

Cette notification est une sonnette. Elle demande au service de regarder immédiatement ; elle ne contient pas l’autorité nécessaire pour modifier le DS. Après réception, l’agent doit toujours interroger les sources faisant autorité, valider les réponses, établir leur cohérence, calculer le DS et vérifier la continuité.

Cette séparation rend le système résistant aux notifications perdues, dupliquées ou forgées. Une perte augmente le délai et peut être compensée par un balayage de réconciliation. Un doublon relance une opération idempotente. Une notification malveillante ne crée aucune donnée acceptable si les RRsets authentifiés n’ont pas changé.

Les indicateurs doivent refléter cette architecture : cible découverte, notification reçue, collecte commencée, cohérence obtenue, demande acceptée, parent publié et validation observée. « Notification réussie » ne doit jamais devenir un synonyme de « DS modifié ».

Le TTL sépare publication et observation

Même après l’acceptation, une chaîne de provisionnement peut différer la génération de la zone parente. La preuve de publication est le DS observé sur les serveurs faisant autorité du parent, accompagné d’un numéro de série ou d’un identifiant de version, et non la réponse positive de l’API de l’agent.

Les résolveurs récursifs conservent ensuite l’ancien DS pendant sa durée de vie. Deux validateurs peuvent donc voir des états différents sans que l’un soit défectueux. Le roulement doit maintenir un chemin valable pour les deux populations.

RFC 10026 recommande de réduire temporairement le TTL du nouveau jeu DS à environ cinq à quinze minutes afin de faciliter un retour arrière, puis de restaurer le TTL normal seulement lorsque l’ancien jeu a eu le temps de disparaître des caches. Réduire le nouveau TTL ne modifie pas les copies anciennes déjà stockées.

Une vérification responsable suit donc au moins l’horizon de l’ancien TTL. Elle compare les réponses faisant autorité, plusieurs résolveurs depuis plusieurs réseaux et le résultat de la validation avec les DNSKEY enfant. Une sonde réussie prouve un chemin à un instant ; elle ne prouve pas la convergence mondiale.

L’automatisation doit laisser une sortie

La maintenance des clés est une opération normale. Un verrou de mise à jour du bureau ou du registre ne doit pas, à lui seul, suspendre l’automatisation DS : ce verrou protège souvent le portail client, pas les actes du registre ou du bureau lui-même.

Mais aucun mécanisme automatique ne doit devenir l’unique moyen d’entretien. La clé de signature peut être perdue, un fournisseur peut refuser de coopérer, ou deux canaux peuvent se contredire pendant une migration. RFC 10026 exige un autre canal, y compris manuel, pour restaurer un état sûr.

Ce canal de secours doit être authentifié indépendamment de la clé perdue, laisser une trace et établir clairement le nouvel état de référence. Une intervention manuelle peut suspendre l’automatisation le temps de résoudre le conflit. Elle ne doit pas produire un blocage indéfini sans explication.

Sources