Une fenêtre de maintenance est une période de coordination et non une promesse que chaque récepteur verra le nouvel état DNS au même moment. Planifiez le changement en fonction des flux métier critiques, de la mise en cache DNS et du temps nécessaire pour observer les résultats. Dites aux parties prenantes ce qui est connu à chaque point de contrôle au lieu d'annoncer le succès aussitôt un enregistrement est sauvegardé.
Choisissez une fenêtre autour des conséquences du service
Répertoriez les applications concernées, les périodes d'envoi de pointe, les tâches planifiées et les personnes qui peuvent les vérifier. Évitez une exécution de paie ou une migration de récupération de mot de passe à moins que l'entreprise n'ait accepté ce calendrier. Incluez les opérateurs DNS et de messagerie, un contact en cas d’incident et une personne habilitée à invoquer le plan de récupération approuvé.
Définissez le changement exact et sa ligne de base avant de sélectionner la fenêtre. La stratégie d'authentification peut interagir avec les expéditeurs en dehors de la plate-forme de boîte aux lettres principale. Inventaire des relais applicatifs et signatures de tiers ainsi que du courrier des collaborateurs. DMARC alignement et la manipulation du récepteur sont distincts du test d'acceptation du propriétaire du service. RFC 9989.
Tenir compte des caches existants
DNS TTL contrôle la durée pendant laquelle un enregistrement de ressource peut être mis en cache, sous réserve du comportement du résolveur. Réduire une durée de vie n'efface pas les enregistrements déjà mis en cache sous l'ancienne valeur. RFC 1035 , format d'enregistrement de ressources et implémentation du résolveur. Prévoyez du temps pour les entrées préalables dans le cache positif lors de la planification d'un changement ; Tenez également compte des réponses négatives, des dépendances et du comportement du prestataire, le cas échéant.
Un exemple de planification hypothétique commence avec le TTL 3600. Un TTL 300 inférieur est publié à 01h00 UTC et le changement prévu est 02h10 UTC. Un intervalle ancien TTL après 01h00 est 02h00 ; le changement prévu à 02h10 a lieu dix minutes plus tard. Il s’agit d’une arithmétique manuelle sur des durées supposées, et non d’une vérification de planification exécutée. Cela ne prouve pas une convergence faisant autorité, une propagation mondiale ou l’expiration des caches négatifs. Confirmez les observations réelles avant de vous fier au calendrier.
Communiquer en trois étapes
Avant la fenêtre, envoyez au public autorisé la portée, l'effet attendu, le calendrier, les propriétaires de vérification et le contact de secours. Ne décrivez pas le changement comme étant sans risque. Pendant la mise en œuvre, enregistrez l’état réel observé et le prochain point de contrôle. Si les tests échouent ou si la ligne de base diffère, signalez le bloqueur spécifique et la décision nécessaire plutôt qu'un retard inexpliqué.
Après la mise en œuvre, faites la distinction entre les contrôles immédiats terminés et les observations différées en attente. Les rapports DMARC décrivent les observations du récepteur et peuvent arriver après la période de maintenance. RFC 9990. Indiquez quels tests de service ont réussi, lesquels n'ont pas été testés et qui examinera les preuves ultérieures. Un message d'état interne autorisé ne doit pas exposer le contenu du message, les informations d'identification ou les détails inutiles du destinataire.
Maintenir le personnel chargé du rétablissement et du suivi
Conservez l’ancien RRset et les critères de récupération approuvés. L'inversion de la configuration peut elle-même prendre du temps à être observée et ne peut pas annuler les décisions antérieures du récepteur. Maintenez la surveillance et la propriété des incidents au-delà de la fenêtre planifiée lorsque le risque le justifie. Si le test commercial ne peut pas être exécuté avant la prochaine campagne planifiée, enregistrez cette limitation au lieu de traiter le service comme vérifié.
Par exemple, une vérification de configuration immédiate peut se terminer pendant la fenêtre alors qu'une campagne trimestrielle ne peut pas être exercée avant son calendrier approuvé. Nommez le vérificateur de campagne, le prochain point de contrôle et le contact d’escalade lors du transfert. Indiquez que la mise en œuvre est terminée mais que la vérification de la campagne reste en attente. Cette distinction d'état hypothétique n'est pas un message envoyé ou un véritable événement de maintenance. Clôturez les travaux immédiats sans clôturer silencieusement l’obligation d’assurance ultérieure.
Le workflow de changement ci-dessus est une recommandation opérationnelle et non une exigence protocolaire. Les contrôles NIST SP 800-53 Rév. 5 CM-3 et CM-5 fournissent une base générale pour examiner, approuver et restreindre les modifications ; le calendrier de maintenance, les points de contrôle de communication et la propriété du suivi sont ici la mise en œuvre proposée. Catalogue de contrôle NIST.