Une restauration DNS peut restaurer un état d'infrastructure antérieur tout en supprimant un sélecteur ou politique introduite par la suite. Restaurez la configuration de messagerie actuelle prévue, et non la sauvegarde la plus simple à importer. Déterminez d’abord quelle autorité dessert les noms concernés et ce qui a changé lors de la restauration.
Geler les preuves avant de les réparer
Références : RFC 6376 §3.5.
Capturez l’heure de restauration, l’exportation précédente, l’ensemble d’enregistrements actuel et les modifications autorisées depuis la sauvegarde. Comparez les noms, types et valeurs exacts pour SPF, DMARC, sélecteurs, chemins de retour et itinéraires de réception. Un enregistrement manquant et un enregistrement ancien mais présent sont des échecs différents. Conserver les messages montrant le sélecteur concerné et le domaine de signature ; un tableau de bord du fournisseur à lui seul peut ne pas révéler quel sélecteur est toujours actif.
Ne réintroduisez pas tous les enregistrements supprimés. Une entrée SPF historique peut autoriser un service retiré, et un alias obsolète peut restaurer une dépendance indésirable. Demandez au propriétaire du service quels expéditeurs et clés restent destinés. Traitez la restauration comme une différence approuvée dans l'état actuel avec des exceptions nommées, et non comme un écrasement de zone complète sans restriction.
Réparer le plus petit ensemble correct
Références : RFC 7208 §4.5, RFC 4035 §5.
Relisez la zone en direct immédiatement avant d'appliquer la différence afin que le changement intervenu par une autre équipe ne soit pas perdu. Conservez l’exportation de récupération actuelle et enregistrez chaque ajout, remplacement ou suppression. Assurez-vous qu'une réparation SPF laisse une politique SPF sélectionnée chez le propriétaire plutôt que d'ajouter une deuxième politique à côté de celle qui est cassée.
Vérifiez le DNSSEC chaîne si la restauration a modifié les clés ou l'autorité. La restauration d'enregistrements signés avec des signatures expirées ou une clé enfant incompatible avec le DS parent ne restaure pas une résolution valide. La signature gérée par le fournisseur doit être réparée via son flux de travail pris en charge, les preuves de validation étant conservées séparément de la visibilité DNS ordinaire.
Travaillez sur un appareil à trois instantanés
Dans un appareil hors ligne, la sauvegarde A contient le sélecteur s1 et SPF v=spf1 ip4:192.0.2.10 -all. L'État approuvé B retire cet expéditeur et modifie SPF en v=spf1 ip4:192.0.2.20 -all et ajoute le sélecteur s2. La restauration accidentelle C est égale à A. Le diff de restauration correct remplace la politique SPF et restaure s2 ; si s1 reste, cela nécessite la décision documentée de retrait de clé.
Représentez A, B et C en tant qu'objets JSON saisis par propriétaire et type. Comparez les valeurs des enregistrements triés tout en préservant les valeurs séparées Enregistrements TXT. Le résultat attendu inclut un ensemble TXT apex modifié et le propriétaire s2 manquant. Les adresses de la documentation sont synthétiques. N’appliquez jamais cet exemple de stratégie à un domaine de production.
Pour une version DNS isolée, publiez C puis la réparation approuvée, en interrogeant chaque autorité avec creuser @AUTH exemple.test TXT +norecurse et creuser @AUTH s2._domainkey.example .test TXT +norecurse. Utilisez les données de marqueur pour les sélecteurs et étiquetez-les comme non cryptographiques. Conservez les deux réponses et le différentiel de réparation exact. La récupération en direct et la validation des messages signés sont en attente.
Tenir compte des succès et des échecs périmés
Références : RFC 2308 §5.
Un résolveur peut conserver la bonne réponse avant l'annulation et masquer temporairement l'erreur. Un autre peut mettre en cache une réponse de sélecteur manquant et continuer à échouer après réparation. Enregistrez l'heure de la requête, le résolveur, le code de réponse et le contexte TTL ; ne continuez pas à modifier les données d'autorité correctes pour forcer la modification d'une vue mise en cache.
Après une réparation faisant autorité, observez les chemins récursifs et envoyez des messages de test inoffensifs approuvés via chaque service concerné. Comparez les résultats de l'authentification avec les en-têtes d'origine et le comportement connu du récepteur. Clôturez l'incident avec l'inventaire corrigé, la cause de la restauration et les sauvegardes. DNS restauré est une condition préalable, et non une preuve de livraison ou une excuse pour supprimer largement l'application.
Preuves de laboratoire isolées exécutées
Le laboratoire de sockets isolé retenu le 7 novembre 2026 a servi l'état de sauvegarde, puis a appliqué la réparation synthétique prédéfinie localement. Les requêtes UDP réelles ont observé l'ancienne adresse SPF et le s2 manquant avant la réparation, ainsi que la nouvelle adresse SPF et le marqueur s2 par la suite. Le plan de restauration conserve le matériel de restauration de sauvegarde, l'état actuel prévu, deux modifications exactes et la propriété des dépendances. Aucun dossier de production n'a été modifié. Les étiquettes de capture sont rollback_before_spf ; rollback_before_s2; rollback_after_spf; rollback_after_s2. Le coureur reproductible et les captures brutes sont inclus dans le dossier de preuves. Les résultats de production DNS , DNSSEC et SMTP n'ont pas encore été testés.
Pour cet examen du 8 novembre 2026, les captures de fils retenues et le différentiel de réparation ont été vérifiés hors ligne. Aucun serveur DNS , commande dig, validation DNSSEC ou test SMTP n'a été réexécuté.