Résumé

  • RFC 8901 est un document informatif issu du consensus de l’IETF, et non une norme imposée ni la preuve qu’un fournisseur nommé prend en charge le DNSSEC multi-signataire.
  • Dans ses deux modèles, le RRset DNSKEY de chaque fournisseur doit contenir tous les ZSK actifs des autres signataires. Sinon, un résolveur peut mettre en cache les clés d’A, recevoir la signature de B lors d’un basculement et rejeter la réponse.
  • Le titulaire de la zone doit coordonner l’échange des clés, le lien KSK–DS parent, les algorithmes et le calendrier des rotations avant la panne. Le deuxième prestataire n’est qu’un chemin possible tant que ces preuves manquent.

La réponse est arrivée, mais pas la preuve

Une zone utilise deux prestataires DNS faisant autorité. Un résolveur validant suit la délégation sécurisée, récupère chez le fournisseur A le RRset DNSKEY, l’authentifie grâce au DS du parent et le conserve en cache. Plus tard, alors que ce cache est encore valable, A devient indisponible. Le résolveur interroge B, qui renvoie la donnée demandée avec une RRSIG produite par son propre ZSK.

Le service de B fonctionne. Pourtant, si le jeu de clés obtenu auparavant chez A ne contient pas le ZSK actif de B, le résolveur ne peut pas vérifier la signature. Il pourra tenter un autre serveur, payer des allers-retours supplémentaires, dépasser son budget de latence ou perdre le client en aval. RFC 8901 ne modifie pas le résolveur : il décrit l’état commun que les signataires doivent construire pour que la validation ordinaire survive à ce changement de chemin.

Deux réseaux, deux contrats et plusieurs NS prouvent une diversité potentielle. Ils ne prouvent pas qu’une réponse DNSSEC de B reste vérifiable avec l’état mis en cache auprès d’A. La redondance n’existe donc pleinement que lorsque le chemin cryptographique traverse lui aussi le basculement.

Un invariant sous deux régimes de garde

Dans le modèle 1, le titulaire de la zone garde un KSK commun et administre le DS parent. Chaque fournisseur possède son ZSK. Le titulaire collecte les ZSK publics, assemble un RRset DNSKEY commun, le signe avec le KSK puis le distribue à tous. Il doit aussi renouveler la signature du RRset avant son expiration, même si aucune clé n’a changé.

Ce modèle donne au parent un point d’entrée unique et aux résolveurs le même objet signé partout. Il concentre aussi le risque opérationnel : garde du KSK, ressignature périodique, accès aux API et livraison cohérente forment une chaîne commune. Une copie périmée chez un seul fournisseur suffit à créer deux réalités.

Dans le modèle 2, chaque fournisseur possède son KSK et son ZSK. Chacun importe les ZSK publics des autres dans son RRset DNSKEY et signe celui-ci avec son propre KSK. Le RRset DS du parent comporte une entrée pour chaque KSK de fournisseur. Un résolveur peut ainsi authentifier l’objet reçu de A ou de B au moyen du DS correspondant.

La garde privée reste distribuée, mais l’état public à synchroniser augmente. Une rotation de KSK modifie la branche DS du fournisseur concerné. Une rotation de ZSK modifie la vue DNSKEY que tous les autres doivent publier. L’indépendance des clés privées n’abolit pas la dépendance envers une vérité publique commune.

La rotation n’est pas une action locale

Dans le modèle 1, A ne peut pas commencer immédiatement à signer avec un nouveau ZSK. Le titulaire doit récupérer cette clé, l’ajouter au jeu combiné, signer l’ensemble et le déployer partout. L’activation attend la propagation et le TTL DNSKEY ; le retrait attend que les données signées par l’ancienne clé et leurs TTL n’en dépendent plus. Une rotation de KSK traverse en outre la publication DS du parent.

Dans le modèle 2, A peut signer son RRset DNSKEY avec son KSK, mais doit quand même transmettre le nouveau ZSK au titulaire, qui le fait importer chez B. A attend l’importation, la diffusion sur toutes les autorités et le TTL DNSKEY avant de signer les données ordinaires avec la nouvelle clé. Le retrait suit le même chemin en sens inverse.

Le reçu utile n’est donc pas « clé créée » ou « API 200 ». Il relie export, acceptation par le titulaire, import chez chaque prestataire, présence sur chaque surface autoritative, écoulement des TTL, validation indépendante depuis les réponses de chaque signataire, puis seulement activation ou retrait.

Algorithmes et réponses négatives

Les fournisseurs doivent utiliser un algorithme DNSSEC commun, ou le même ensemble d’algorithmes. Lorsque plusieurs algorithmes figurent dans DNSKEY, les règles de signature de DNSSEC s’appliquent aux RRsets de la zone. Deux choix incompatibles ne deviennent pas compatibles parce que deux entreprises les opèrent.

Les preuves NSEC et NSEC3 voyagent avec la réponse négative, ce qui permet techniquement des méthodes distinctes. Mais mélanger NSEC et NSEC3 affaiblit la protection de NSEC3 contre l’énumération facile ; des configurations permanentes différentes peuvent aussi réduire l’efficacité du cache négatif. RFC 8901 préfère une méthode commune et demande de limiter les variantes lorsqu’elles sont inévitables.

Un test limité à l’adresse positive du site manque donc une partie du risque. Une réponse A peut valider tandis qu’une inexistence de nom ou de type révèle une autre combinaison de signatures, de preuves et de caches.

Une recommandation, pas un résultat de production

RFC 8901 est informatif. Il ne démontre ni prise en charge d’API, ni import correct de ZSK externes, ni disponibilité, ni incident, ni taux d’adoption. Il ne garantit pas davantage que DNSSEC prouve l’autorisation commerciale, la santé de l’application ou le basculement du trafic. La validation établit une relation cryptographique bornée pour les données observées.

La conclusion exploitable est plus sobre : le deuxième fournisseur réduit une dépendance seulement si le titulaire peut reconstituer, avant la panne, la vue commune des clés, les entrées DS, le choix d’algorithme et la chronologie de rotation.

Sources