Le déplacement d’une zone signée est une transition de confiance coordonnée. Le registraire peut contrôler la délégation et les modifications DS, tandis que les anciens et les nouveaux fournisseurs DNS contrôlent les données de zone et les clés de signature. Une importation réussie ne prouve pas que la validation des résolveurs peut suivre chaque état intermédiaire.
Inventorier l’ancien chemin de confiance
Références : RFC 6781 §4.3.5.
Exportez les enregistrements ordinaires, les données DNSKEY et DS, la configuration de signature, les TTL pertinents et les adresses d'autorité. Enregistrez qui peut modifier les données parentales NS et DS. Confirmez si le nouveau fournisseur prend en charge l'importation de clés existantes, la signature coordonnée ou uniquement un nouvel ensemble de clés indépendant. N’exportez pas de clés de signature privées à moins qu’une procédure sécurisée approuvée et des fournisseurs compatibles ne l’exigent.
Avant de choisir une méthode de migration, vérifiez que les nouvelles autorités desservent l'ensemble de la zone de manière cohérente. Inclut MX , les sélecteurs, l'authentification TXT et TLSA enregistrements. Préservez le comportement de réponse négative et les délégations existantes. Un nouvellement en bonne santé DNSSEC la chaîne ne compense pas les enregistrements de courrier manquants.
Choisissez une transition documentée
Références : RFC 6781 §4.1, RFC 6781 §4.3.5, RFC 8767 §4.
RFC 6781 décrit les considérations relatives au basculement DNSSEC et au changement d'opérateur. Il n’existe pas de séquence universelle sûre indépendante des capacités du fournisseur. Une transition coordonnée peut conserver les anciens et les nouveaux chemins de validation utilisables tandis que les informations DS, DNSKEY et NS mises en cache se chevauchent. Si les prestataires ne peuvent pas soutenir l’approche sélectionnée, organisez avec eux une transition documentée plutôt que d’inventer un raccourci temporel.
Une migration délibérée de signé vers non signé vers signé est une dégradation de la sécurité avec son propre ordre de dépendance et ses propres périodes d'attente. Le DS parent ne doit pas continuer à pointer vers une clé enfant inutilisable. À l’inverse, l’ajout d’un nouveau DS avant que l’enfant signé correspondant ne soit accessible peut créer des échecs. Réduire la durée de vie juste avant le changement ne réduit pas la durée de vie des enregistrements déjà mis en cache avec une durée de vie plus ancienne. RFC 8767 autorise le service obsolète dans des conditions spécifiées d'échec de rafraîchissement ; ne considérez pas l'expiration du TTL uniquement comme une preuve que chaque chemin dépendant a retiré les anciennes données.
Répéter les états mis en cache incompatibles
Références : RFC 6781 §4.3.5, RFC 4035 §5.
Construisez un parent jetable et deux services pour enfants faisant autorité. Définissez l'ancienne DS/clé A et la nouvelle DS/clé B, ainsi que les données de test MX et TLSA fixes. Testez au moins quatre états du résolveur : ancienne délégation avec d'anciennes données de confiance, nouvelle délégation avec des données de confiance compatibles, ancien DS mis en cache avec de nouvelles clés uniquement et nouveau DS mis en cache avec d'anciennes clés uniquement. Les deux derniers cas sont des cas d’incompatibilité délibérés et non des états de transition acceptables.
Pour chaque état, conservez les données DSparent, DNSKEY et RRSIG enfants, la configuration du cache du résolveur, l'horloge, la requête exacte et la trace du validateur. Répétez avant, pendant et après le chevauchement choisi. Vérifiez l'association certificat-TLSA séparément si le point de terminaison de messagerie change. Il s’agit des conditions requises pour un test de migration basé sur un résolveur. La matrice cryptographique hors ligne conservée ci-dessous couvre uniquement la compatibilité des données signées, et non une migration en direct.
Faire de la restauration une opération de confiance
Références : RFC 6781 §4.3.5, RFC 4035 §5.
La modification de NS ne supprime pas les informations DS ou DNSKEY mises en cache. Un plan de restauration doit spécifier quelles clés restent disponibles et quelles combinaisons mises en cache sont toujours valides. Conservez l'ancien service et le matériel de signature requis à disposition pour la période de chevauchement approuvée, avec des critères de retraite surveillés plutôt qu'une date calendaire pratique.
Après la transition, comparez chaque serveur faisant autorité, plusieurs chemins de résolution pertinents et des tests de messagerie représentatifs. Confirmez la validation après les transitions de cache attendues, puis retirez l'ancienne infrastructure via le processus de modification. Conservez le DS final exact et les preuves de délégation afin que l'opérateur suivant puisse expliquer le chemin de confiance qui en résulte.
Matrice de migration synthétique observée
Références : RFC 4035 §5.
Un laboratoire cryptographique retenu le 7 novembre 2026, inspecté mais non réexécuté pour cet examen, a testé sept états de données signées. L'ancien DS/clé A, le DS A/B superposé avec la clé A, le DS superposé avec la clé B et le DS/clé B final sont tous validés. L'ancien DS uniquement avec la nouvelle clé B uniquement a échoué, tout comme le retour à la clé A après le remplacement du DS par B seul. Restauration de l'appariement Un matériau à nouveau validé. Il s'agit de signatures réelles et de contrôles DS avec des clés de test générées, et non d'étiquettes de réussite simulées. Ils démontrent des combinaisons de données mises en cache incompatibles mais n'émulent pas un cache de résolution, une API de fournisseur ou une transition TTL écoulée. La migration en direct du fournisseur, le calendrier et l'exécution de la restauration restent en attente.