Écrire la décision avant de modifier le système
Ce guide est un exercice de planification pour un opérateur d'application. Il ne représente pas un déploiement, une action d'assistance ou un résultat client mesuré de PrivacyNodes. Notez l'ancien et le nouvel endpoint, le propriétaire du certificat TLS, la réponse de santé et la condition de retour avant d'abaisser un TTL DNS. Les connexions existantes et les caches de résolveurs peuvent survivre à une fenêtre de modification prévue.
Répéter la modification avec des entrées contrôlées
Ne publiez la nouvelle cible qu'après qu'elle sert une requête synthétique authentifiée et une erreur contrôlée. Observez les deux noms d'hôte depuis plusieurs résolveurs et gardez l'endpoint précédent capable du chemin de retour documenté.
Utilisez des requêtes synthétiques et des identités de test pendant la vérification de la modification. N'exposez pas de secrets ni de données clients dans une commande, un extrait de journal ou une note d'assistance.
Vérifier le résultat et consigner la limite restante
Consignez les horodatages UTC, les réponses observées, les noms de certificats et la décision de finaliser ou de revenir. Un TTL bas est une indication de cache, pas une garantie de basculement instantané.
Consignez l'heure UTC, la révision de l'artefact ou de la configuration, les symptômes expurgés et le prochain responsable.
Référence officielle
Cette source a été examinée pour la limite technique de ce guide ; elle ne documente pas un test ou une capacité fournisseur de PrivacyNodes.