Déplacement des modifications DNS faisant autorité là où les résolveurs obtiennent les données du domaine. Un succès serveur de noms le changement ne prouve pas que SPF, DKIM, DMARC ou les routes de réception ont survécu. Préservez les enregistrements et les dépendances efficaces avant de modifier la délégation, et gardez l'ancien et le nouveau service disponibles pendant que les caches peuvent utiliser l'un ou l'autre.
Inventorier la zone efficace
Références : RFC 1034 §4.2, RFC 1035 §3.3.14, RFC 6376 §3.1.
Identifiez la délégation parent actuelle et tous les serveurs faisant autorité. Obtenez une exportation autorisée ou un inventaire d'API auprès de l'hôte DNS réel. Une requête ordinaire ne peut pas énumérer tous les Sélecteur DKIM, combinez donc l'exportation avec la configuration du service d'envoi et les en-têtes de messages signés récents. Inclut Apex SPF , DMARC , sélecteurs actifs et retirés, personnalisés chemin de retour enregistrements, MX , leurs dépendances d'adresse et les enregistrements de politique de transport lorsqu'ils sont déployés.
Enregistrez les noms exacts des propriétaires, les types, les durées de vie et les valeurs. Préservez les limites des enregistrements de ressources TXT et les fragments de chaînes. Alias d’inventaire et délégations enfants plutôt que de copier uniquement la valeur terminale vue par une recherche récursive. Les fonctionnalités du fournisseur telles que l'aplatissement ou les enregistrements gérés nécessitent un équivalent explicite à la destination ; ils risquent de ne pas survivre à une exportation de base d'un fichier de zone.
Construisez la destination avant de changer
Références : RFC 4034 §5, RFC 4035 §2.4.
Importez les données examinées dans la destination, inspectez la différence et interrogez directement chaque nouveau serveur faisant autorité. Ses valeurs SOA et apex NS peuvent intentionnellement différer de celles de l'ancien fournisseur ; les données d'authentification ne doivent différer que lorsque le plan de migration autorise explicitement un changement. Vérifiez que la saisie du nom relatif n'a pas dupliqué le suffixe de zone.
Pour les zones signées, coordonnez la transition DS parent et DNSKEY enfant avec la procédure de migration prise en charge par les fournisseurs. Copie d'enregistrements ordinaires sans coordination DNSSEC peut obliger un résolveur de validation à rejeter des données autrement visibles. Ne supprimez pas le DS et ne désactivez pas la validation par défaut. Déterminez la procédure exacte de continuité ou de transition avant de planifier le déménagement.
Reproduire un échec de sélecteur manquant
Utilisez une zone de laboratoire isolée nommée example.test. L'ancienne autorité a exemple.test. 300 DANS TXT " v=spf1 -all ", _dmarc.example.test. 300 IN TXT "v=DMARC1; p=none" et s1._domainkey.example .test. 300 IN TXT "luminaire=sélecteur-présent". La dernière valeur est un marqueur, pas une clé DKIM . Préparez une copie de destination qui omet délibérément s1.
Courir creusez @OLD_IP s1._domainkey.example .test. TXT +norécurse et creusez @NEW_IP s1._domainkey.example .test. TXT +norécurse, en remplaçant les adresses des serveurs de laboratoire. La comparaison attendue identifie le marqueur manquant au niveau de la nouvelle autorité. Restaurez-le, répétez toutes les requêtes exactes de propriétaire/type et conservez les réponses avant et après. Cet appareil teste l'exhaustivité de l'inventaire, pas un test valide Signature DKIM.
Changez et observez les deux chemins
Références : RFC 1034 §4.2, RFC 2308 §5, RFC 8767 §4.
Réduisez les TTL applicables suffisamment à l’avance si le plan pris en charge l’exige ; les anciennes durées de vie mises en cache ne sont pas raccourcies rétroactivement. RFC 8767 autorise également une diffusion limitée dans des conditions d'échec de rafraîchissement spécifiées, de sorte qu'une durée de vie n'est pas une date limite de disparition universelle. Mettez à jour la délégation parent via le flux de travail d'enregistrement autorisé, puis observez les références parentales et la résolution récursive ainsi que les réponses directes du nouveau serveur. La délégation, les réponses positives et les réponses négatives peuvent avoir des historiques de mise en cache différents.
Conservez l'ancien service DNS jusqu'à ce que le cache et les conditions opérationnelles pertinents de la migration soient effacés. Une restauration est un autre changement distribué, pas une annulation instantanée. Fermez uniquement une fois que les enregistrements sont acceptés, que la résolution fonctionne le cas échéant et que les chemins de messagerie légitimes et représentatifs ont été testés. La migration en production et les tests de messagerie restent en attente. L'élément historique retenu ci-dessous fournit un exemple limité de préservation DNS .
Preuves historiques conservées en laboratoire
La capture conservée du 7 novembre 2026, inspectée mais non réexécutée ici, enregistre que le laboratoire de sockets isolé a interrogé les anciennes et les nouvelles autorités de zone fixe pour s1._domainkey.example .test. La destination renvoyait initialement NXDOMAIN , tandis que l'ancienne autorité renvoyait le marqueur. Après l'ajout synthétique décrit dans le coureur historique, la destination a rendu le marqueur. La capture conservée préserve les noms exacts des requêtes et les réponses avant/après pour ce cas restreint de conservation des enregistrements ; il ne s'agit pas d'un plan de migration ou d'une approbation du client. Les étiquettes de capture sont migration_missing_s1 ; migration_old_s1; migration_after_repair. Le coureur historique et la capture brute sont inclus dans ce package de révision ; leur présence ne constitue pas une nouvelle demande d’exécution. Les résultats de production DNS , DNSSEC et SMTP n'ont pas encore été testés.