Résumé

  • Le DS qui ouvre la chaîne de confiance appartient à la zone parente. CDS/CDNSKEY décrit l’état souhaité par le côté enfant ; quand un DS valide existe déjà, cette chaîne peut authentifier une rotation, mais elle manque précisément lors du premier enrôlement.
  • RFC 9615 emprunte alors la confiance aux zones de signalisation sécurisées des serveurs de noms hors domaine. Tous les opérateurs concernés doivent présenter le même contenu. Cette unanimité prouve un consentement opérationnel, pas le titre du titulaire.
  • L’admission parentale, le choix des algorithmes de condensat, la publication, l’écoulement des TTL et le résultat chez les résolveurs restent des preuves distinctes. La demande fondée sur l’algorithme zéro pour une suppression totale constitue une opération destructive autonome.

Une signature sans point de départ

Un hébergeur DNS active DNSSEC pour une entreprise. Les serveurs publient un DNSKEY, un CDS et un CDNSKEY cohérents. Les signatures se vérifient avec la clé visible dans la même zone. L’interface annonce que la configuration est prête, tandis que le parent ne contient encore aucun DS.

Pour un résolveur validant, ce dernier détail change tout. Il ne peut pas accepter la clé de l’enfant parce qu’elle signe correctement sa propre présentation. Il a besoin du DS parental pour savoir quelle clé de l’enfant relier à la confiance déjà établie. Sans cette ancre, la réponse est cohérente mais autoréférentielle.

Le problème n’est donc pas de trouver une signature supplémentaire. Il faut savoir quelle autorité existante permet au parent d’interpréter le signal. L’opérateur DNS contrôle la publication technique. Le titulaire contrôle normalement le choix du prestataire. Le bureau d’enregistrement authentifie une relation de compte. Le registre ou un autre agent a le pouvoir d’insérer le DS. Ces pouvoirs peuvent coopérer ; aucun RR ne les rend identiques.

L’automatisation est née d’un vrai coût. Transmettre manuellement une nouvelle empreinte à chaque KSK ou CSK expose aux erreurs, aux retards et aux rotations évitées. Elle mérite pourtant une comptabilité d’autorité plus rigoureuse, précisément parce qu’elle supprime les pauses humaines qui rendaient autrefois le changement visible.

Le message de l’enfant n’est pas la donnée du parent

Le DS effectif réside dans la zone parente. Il associe une étiquette de clé, un algorithme, un type de condensat et une empreinte à un DNSKEY enfant. CDS reprend les champs de DS sous un autre type. CDNSKEY publie la clé publique dont l’agent parental peut calculer un ou plusieurs DS.

RFC 7344 traite le RRset comme un état de remplacement souhaité. Le consommateur compare cet état au DS actuel et prépare les ajouts et retraits nécessaires. Le mécanisme ne donne pas à l’enfant un DNS UPDATE direct contre le parent. Le parent reste l’auteur de sa zone ; le signal est une entrée dans sa décision de provisionnement.

L’absence de signal a un sens protecteur : aucune action. Après synchronisation, l’enfant peut retirer CDS/CDNSKEY pour alléger la zone. Une interrogation vide, une panne de collecte ou cette suppression normale ne doit jamais devenir une suppression implicite du DS.

Le parent choisit aussi comment consommer. Il peut privilégier CDS, préférer CDNSKEY et calculer le DS, ou utiliser l’un en repli de l’autre. Sa politique de condensat peut écarter un type non pris en charge. Le résultat peut donc différer du CDS publié par la liste des condensats, sans changer la clé visée.

Ce partage est une architecture de compétence. L’enfant indique le matériel de confiance souhaité. L’agent parental vérifie la source et l’admissibilité. Le parent inscrit. Le résolveur valide. Dire « la zone a demandé » ne suffit pas à documenter les quatre actes.

La rotation utilise la confiance déjà disponible

Lorsque le DS parental correspond à une clé actuelle, le chemin existe pour authentifier un nouveau CDS/CDNSKEY. Le signal au sommet de l’enfant doit être signé par une clé représentée dans le DNSKEY actuel et dans le DS parental. La continuité exige que l’application du remplacement ne rende pas immédiatement la délégation invalide.

Cette règle autorise une transition limitée. Elle ne dit pas que toute donnée signée reflète une décision humaine correcte. L’agent parental récupère le RRset, le valide, le compare et protège l’ordre des observations. Un ancien signal ne doit pas écraser le nouveau. Le début de validité de RRSIG et le numéro de série SOA apportent des indices, mais une exploitation sérieuse conserve aussi l’état précédemment accepté.

La publication du DS n’achève pas encore la rotation. Les anciens DS, DNSKEY et RRSIG vivent dans des caches différents. La nouvelle clé doit être présente sur toutes les autorités avant que les références parentales ne l’atteignent ; l’ancienne ne peut disparaître tant qu’un résolveur peut encore détenir son DS.

Le guide BIND actuel rend cette attente observable. BIND peut publier CDS/CDNSKEY, interroger des parental-agents et suspendre la rotation jusqu’à ce que chacun confirme le DS attendu. Si le parent ne sait pas consommer ces enregistrements, la voie manuelle reste indispensable. La capacité de l’enfant ne prouve jamais celle du parent.

Le premier DS doit emprunter une autre confiance

Pour le premier enrôlement, RFC 8078 proposait plusieurs politiques : canal de compte authentifié, vérifications supplémentaires, observation prolongée depuis plusieurs points, challenge ou traitement au moment de la délégation. Elles peuvent encadrer le risque, mais ne créent pas une chaîne DNSSEC partant de l’enfant non sécurisé.

RFC 9615 fournit une méthode intégrée au DNS plus forte lorsque la délégation contient au moins un serveur de noms hors du domaine enfant. Pour chaque nom de serveur indiqué par le parent, l’opérateur construit un domaine de signalisation en ajoutant _signal. Sous ce domaine, un nom _dsboot identifie l’enfant et porte une copie du CDS/CDNSKEY.

Cette copie est signée dans une zone de signalisation qui possède déjà sa propre chaîne de confiance. Le parent peut donc authentifier la déclaration sous le nom de l’opérateur de serveurs, puis vérifier qu’elle est identique à celle publiée au sommet de l’enfant. La confiance n’est pas inventée ; elle est transférée depuis un espace déjà sécurisé.

L’agent parental commence par confirmer l’absence de DS et lire le NS du côté parent. Il interroge directement chaque serveur faisant autorité, sans cache, pour le CDS/CDNSKEY de l’enfant. Il résout ensuite chaque signal hors domaine avec validation DNSSEC. Il compare enfin les RRsets par type.

Un désaccord suffit à arrêter : réponse manquante, validation impossible, signal vide d’un côté et présent de l’autre, ou contenu différent. Si tous les serveurs sont sous le domaine enfant, aucune chaîne extérieure n’existe et la méthode ne s’applique pas.

Cette sévérité protège les configurations multi-opérateurs. Un fournisseur ne peut pas faire publier son seul KSK pendant que les autres autorités annoncent un état incompatible. RFC 8901 étend la même discipline aux systèmes multi-signataires : les prestataires doivent construire une vue CDS/CDNSKEY commune avant que le parent ne puisse l’utiliser.

Consentement d’opérateur et mandat du titulaire

L’accord cryptographique décrit qui contrôle les autorités listées et qui accepte d’agir comme signataire. Il ne démontre pas la chaîne contractuelle qui a confié le domaine à ces autorités. RFC 9615 reconnaît qu’un fournisseur peut ajouter les signaux sans connaissance explicite du titulaire et recommande de l’informer.

Une erreur d’activation, un compte fournisseur compromis ou une migration incomplète peut donc produire des RRsets authentiques mais contestés. Le bon contrôle n’est pas de nier leur validité cryptographique. Il est d’enregistrer séparément la relation qui autorise l’agent parental à agir, le droit du titulaire à être averti et la possibilité d’interrompre un premier enrôlement inattendu.

La minimisation QNAME réduit aussi une exposition technique. Sans elle, un ancêtre du domaine de signalisation peut voir la requête complète et tenter de répondre sous sa propre autorité au lieu de déléguer. La minimisation ne donne aucun mandat ; elle aide le résolveur à atteindre et valider la bonne zone avec moins de surface de substitution.

Zéro signifie retirer la chaîne, pas choisir une clé

RFC 8078 réserve deux formes exactes : CDS 0 0 0 0 et CDNSKEY 0 3 0 0. L’algorithme zéro n’est pas un algorithme de signature utilisable. Dans ces formes, il ordonne de supprimer tout le RRset DS du parent.

Le parent doit d’abord valider le signal et ses autres critères d’acceptation. Après suppression du DS, l’enfant attend l’expiration pertinente du côté parent avant d’arrêter la signature. Faire disparaître les DNSKEY trop tôt crée une délégation invalide pour les résolveurs qui possèdent encore l’ancien DS.

Les états publiés par Cloudflare illustrent cette chronologie : ses phases de désactivation continuent à signer et servent le signal zéro pendant que le DS parental existe encore ; un état ultérieur retire le matériel DNSSEC. Cette conduite appartient au produit, mais la séparation des réalités est générale : demande, DS publié, caches et signature enfant ne changent pas au même instant.

Le retour à l’insécurité mérite donc une autorisation propre, une notification et un plan de ré-enrôlement. Une liste vide ou un échec de collecte n’est jamais un raccourci équivalent. L’irréversibilité commence lorsque la dernière chaîne authentifiée disparaît et que le seul recours est redevenu hors bande.

La preuve se termine chez un validateur

Avant le changement, le dossier conserve le NS parental, le DS existant, les réponses de chaque autorité enfant, chaque nom de signalisation, la chaîne qui le valide, l’égalité des contenus, leur fraîcheur, la politique d’admission et l’écart DS proposé. Il identifie aussi l’autorité de compte ou de délégation qui permet à l’agent parental d’agir.

Après publication, il observe chaque serveur du parent, attend les TTL définis, vérifie la présence des clés et signatures sur toutes les autorités enfant et teste plusieurs résolveurs validants. Un tableau de bord vert prouve l’acceptation d’une commande. Un DS vu sur un serveur prouve un état parental. Seule la chaîne complète observée prouve l’effet pour un chemin donné.

Les refus font partie de la preuve. Un premier enrôlement arrêté parce qu’un opérateur diverge préserve l’unanimité. Un condensat rejeté révèle une politique parentale. Une délégation dont tous les serveurs sont dans le domaine enfant, envoyée vers une procédure authentifiée manuelle, respecte la limite du protocole. Nommer ces résultats empêche de traiter la sécurité comme un obstacle à contourner.

Sources