Répéter la procédure
Conservez un export protégé et la liste des accès nécessaires. Un test depuis plusieurs résolveurs confirme propagation, certificat, redirections et appels API avant réouverture.
Un exercice réussi prouve que la zone peut être restaurée, que les certificats fonctionnent et que les intégrations répondent. Notez les délais, les accès nécessaires et les corrections. Une révision après changement de fournisseur maintient le runbook utile.
Contrôler le support
Le support doit connaître les domaines touchés, le délai de propagation et le canal d’escalade. Une réponse locale ne suffit pas ; testez plusieurs résolveurs et notez leurs résultats avant de fermer l’incident.
Garder un retour documenté
Conservez zone précédente, accès de secours et résultats de tests. Vérifiez site, APIs, email, webhooks et certificats depuis plusieurs résolveurs. Le runbook doit indiquer qui valide la réouverture du trafic.
Tester chaque usage
Un domaine peut servir site, API, email, authentification et webhook. Interrogez plusieurs résolveurs et régions. Comparez réponse autoritative, réponse mise en cache et TTL restant. Une ancienne valeur peut rester visible pendant le TTL, mais une différence sur l’autorité indique une configuration à corriger.
Après restauration, contrôlez HTTP, HTTPS, www, sous-domaines, APIs et webhooks. Un certificat valide ne prouve pas que le domaine pointe vers le bon service. Une redirection vers une ancienne version peut créer des doublons ou exposer une application oubliée.
Préparer le retour
Conservez export de zone, accès de secours et coordonnées du fournisseur. Testez l’import dans une zone isolée. Le runbook doit préciser personne habilitée, commandes, validation et décision de réouverture. Notez heure, résolveur et résultat pour chaque essai.
Surveiller après changement
Ajoutez une alerte sur expiration, réponse inattendue et erreur d’API. Le support doit savoir que les caches peuvent retarder une correction. Une revue après un cycle de trafic confirme que les intégrations fonctionnent.
Tester les usages
Un domaine peut servir site, API, email, authentification et webhook. Vérifiez chaque usage depuis plusieurs réseaux et résolveurs. Contrôlez le certificat, la chaîne, les redirections et la réponse d’erreur.
Garder un retour
Conservez l’export de zone précédent et les permissions de restauration. Notez qui peut changer la zone, qui valide le trafic et comment annuler une modification. Une procédure testée est plus utile qu’une capture ancienne.
Surveiller après changement
Ajoutez une alerte sur expiration, réponse inattendue et erreur d’API. Le support doit savoir que le cache DNS peut retarder une correction. Documentez l’heure et le résolveur utilisé lors de chaque contrôle.
Inventoriez domaines, sous-domaines, types, fournisseurs, certificats, emails et webhooks. Exportez la zone dans un espace protégé puis testez son import dans une zone isolée. Vérifiez que les enregistrements de validation sont inclus.
Interrogez plusieurs résolveurs et régions. Comparez réponse autoritative, réponse mise en cache et TTL restant. Une ancienne valeur peut rester visible pendant le TTL, tandis qu’une différence sur l’autorité indique une configuration à corriger.
Après restauration, contrôlez HTTP, HTTPS, redirections, APIs et webhooks. Un certificat valide ne prouve pas que le domaine pointe vers le bon service. Une redirection vers une ancienne version peut créer doublons ou erreurs de données.
Le runbook doit préciser compte, personne habilitée, commandes, validation et retour. Notez heure, résolveur, résultat et décision. Testez aussi la reprise vers un autre fournisseur lorsque l’objectif de disponibilité le demande.
Le DNS relie un domaine aux services accessibles. Une configuration incorrecte peut rendre une application invisible même lorsque les serveurs fonctionnent. Une procédure de restauration doit couvrir zones, certificats, TTL et dépendances.
Inventorier les enregistrements
Listez domaines, sous-domaines, types, fournisseurs, propriétaires et valeurs attendues. Notez les enregistrements utilisés pour email, vérification, webhooks et APIs. Une zone exportée doit être stockée de façon contrôlée.
Tester une copie
Restaurez dans une zone de test puis vérifiez les réponses depuis plusieurs résolveurs. Contrôlez CNAME, MX, TXT, certificats et redirections. Le cache peut retarder le résultat, alors mesurez le délai réel.
Préparer le retour
Conservez la zone précédente et définissez qui peut modifier le fournisseur DNS. Une bascule vers un autre service doit prévoir les identifiants, les limites et les validations. Sources : ICANN DNS basics, Google Cloud DNS.
Vérifier les dépendances
Un changement DNS peut toucher certificat, CDN, authentification, emails et webhooks. Testez chaque sous-domaine selon son usage. Une réponse correcte depuis un poste local ne garantit pas que les résolveurs utilisés par les clients ont reçu la nouvelle valeur.
Réduisez le TTL avant une opération planifiée lorsque cela respecte votre fournisseur, puis remettez une valeur adaptée après stabilisation. Ne réduisez pas le TTL comme solution permanente à une configuration instable. Les caches ont des comportements différents et doivent être observés.
Documenter une reprise
Le runbook doit préciser compte, zone, enregistrements, validation et personne habilitée. Conservez un export protégé et testez son import dans une zone isolée. Après restauration, confirmez HTTPS, redirections, email et appels API. Un certificat peut être valide alors que le domaine pointe vers le mauvais service.