# Un runbook de basculement de domaine, DNS et TLS pour un nouveau serveur | SwissOctet Insights https://swissoctet.com/fr/insights/dns-tls-cutover-runbook/ SwissOctet / Analyses / Web et onion Web et onion Appliqué · 4 min de lecture Un runbook de basculement de domaine, DNS et TLS pour un nouveau serveur Préparez ensemble le routage par nom d'hôte, les certificats et le retour arrière afin qu'une migration change le serveur sans rompre l'identité du site ni les connexions sécurisées. Par SwissOctet Editorial Enregistrer le guide Copier le lien SUR CETTE PAGE 01 Inventorier les noms et les dépendances 02 Préparer le routage par nom d'hôte sur le nouveau serveur 03 Choisir une méthode de validation de certificat 04 Planifier la fenêtre de cache avant de modifier DNS 05 Vérifier DNS et TLS séparément 06 Faire du retour arrière aussi une décision de données 07 Observer le site après la bascule Votre liste de contrôle pratique Sources et lectures complémentaires Retour à la bibliothèque LA RÉPONSE DIRECTE Préparez le serveur et le certificat pour le nom d'hôte prévu, testez l'application avant de modifier le DNS public, et gardez l'ancien environnement disponible pendant la transition. Vérifiez séparément les enregistrements faisant autorité, les réponses mises en cache et TLS. Une simple mise à jour DNS n'établit pas que l'application et le certificat corrects sont servis. 01 Inventorier les noms et les dépendances Listez chaque nom d'hôte utilisé par le site, y compris le domaine principal, les alias, les points de terminaison API et les callbacks applicatifs. Consignez qui contrôle l'enregistrement et le DNS faisant autorité. Héberger une application n'enregistre pas automatiquement son domaine et ne donne pas à l'opérateur du serveur le contrôle de ses enregistrements. Conservez l'accès à l'environnement existant jusqu'à ce que le nouveau soit validé. Identifiez aussi les enregistrements de vérification d'e-mail et de tiers que le déplacement doit préserver. Une migration de site web ne devrait pas remplacer sans précaution une zone DNS entière. Établissez un plan de modification au niveau des enregistrements avec les adresses prévues et une valeur de retour arrière. Stockez les identifiants en privé ; le runbook a besoin de responsables et de procédures plutôt que de mots de passe réels ou de jetons API. 02 Préparer le routage par nom d'hôte sur le nouveau serveur Une machine qui reçoit une connexion doit servir l'application prévue pour son nom d'hôte. Configurez le serveur web ou le panneau d'hébergement en conséquence, avec la racine publique des documents séparée de la configuration privée et des identifiants. Testez tous les noms et redirections requis, et pas seulement une page d'accueil générique atteinte via l'adresse du serveur. Utilisez une méthode de test contrôlée qui envoie le nom d'hôte prévu vers le nouveau point de terminaison avant le changement public. Vérifiez la connexion, les téléversements et les liens générés par l'application le cas échéant. Désactivez les tâches susceptibles de dupliquer des actions de production pendant les tests. Le test doit prouver le comportement de l'application sans envoyer de vrais e-mails, prendre des paiements ni modifier involontairement l'ancienne base de données en production. 03 Choisir une méthode de validation de certificat L'émission d'un certificat exige une preuve de contrôle des noms demandés. Let's Encrypt documente HTTP-01 et DNS-01 parmi ses méthodes de validation. La validation HTTP dépend de la bonne diffusion du défi requis ; la validation DNS utilise un enregistrement DNS spécifié et peut prendre en charge l'émission de certificats wildcard. Choisissez une méthode adaptée au déploiement réel et pouvant être maintenue en toute sécurité. Limitez autant que possible la portée des identifiants de validation. L'automatisation DNS est particulièrement sensible, car des identifiants DNS étendus peuvent affecter plusieurs sites web. Planifiez le renouvellement du certificat et la manière dont les fichiers renouvelés parviennent au processus de service. Une première émission réussie est utile, mais un site a aussi besoin d'un processus de renouvellement fonctionnel et d'une surveillance du certificat qu'il présente réellement. 04 Planifier la fenêtre de cache avant de modifier DNS Les enregistrements DNS portent un temps de vie utilisé par les résolveurs lors de la mise en cache des réponses. Une modification d'enregistrement ne remplace pas instantanément chaque résultat mis en cache. Si une transition bénéficie d'un TTL plus court, planifiez l'ajustement suffisamment tôt pour que les réponses déjà mises en cache puissent expirer. Gardez les anciens et nouveaux environnements capables de gérer la transition que vous avez conçue. Cette séquence illustrative sépare la préparation du basculement public. Son calendrier doit être adapté au domaine, au comportement des résolveurs et à l'application. Ce n'est pas un calendrier universel de propagation. Une migration impliquant des écritures en direct nécessite aussi un basculement de données spécifique à l'application, car deux serveurs web fonctionnels peuvent sinon accepter des changements dans des jeux de données différents. Étape Action Condition avant de poursuivre Préparation Inventorier les enregistrements et configurer le nouveau point de terminaison L'application fonctionne pour les noms prévus Certificat Émettre et installer le certificat La chaîne et le nom d'hôte corrects sont validés Transition Mettre à jour uniquement les enregistrements DNS prévus Le basculement des données et le retour arrière sont définis Observation Vérifier les résultats faisant autorité et ceux des clients Les parcours utilisateurs réussissent via le nouveau point de terminaison Achèvement Retirer l'ancien service après validation Trafic résiduel et besoins de reprise examinés 05 Vérifier DNS et TLS séparément Consultez d'abord l'enregistrement faisant autorité, puis comparez les réponses des clients ou des résolveurs impliqués dans la transition. Une valeur faisant autorité correcte et une valeur en cache plus ancienne peuvent coexister. Inspectez le point de terminaison atteint par le navigateur plutôt que de supposer que chaque connexion utilise déjà la nouvelle adresse. Horodatez les observations pour que la transition soit compréhensible. Pour TLS, validez le nom d'hôte prévu, la validité du certificat et la chaîne au moyen d'une connexion client réelle. Inspectez chaque alias et chemin de redirection requis. La documentation TLS de Mozilla explique l'authentification du serveur et les problèmes de contenu mixte : la page et ses sous-ressources doivent être livrées de manière sécurisée. Un certificat sur un nom d'hôte ne couvre pas automatiquement un autre point de terminaison d'application. 06 Faire du retour arrière aussi une décision de données Un retour en arrière DNS peut rediriger le trafic, mais il n'annule pas les écritures effectuées sur la nouvelle application. Définissez comment vous traiterez ces données avant la bascule. Pour une publication statique, le retour en arrière peut être simple ; pour un service acceptant des téléversements ou des commandes, l'état de l'application nécessite un responsable clair et une procédure de réconciliation. Imaginez la migration d'un petit site de publication avec commentaires. Vous pouvez préparer une fenêtre de maintenance ou une transition contrôlée en lecture seule pendant la copie des données finales. Testez la procédure de réouverture et gardez l'ancien déploiement prêt. Choisissez l'approche adaptée à l'application plutôt que d'utiliser une modification DNS comme substitut à une planification de la cohérence. 07 Observer le site après la bascule Vérifiez les parcours utilisateurs réels, les taux d'erreur, la présentation des certificats et les tâches en arrière-plan après que le nouveau point de terminaison reçoit du trafic. Confirmez que les sauvegardes couvrent désormais l'application et les données prévues. Examinez les accès à l'ancien serveur avant sa mise hors service et supprimez les identifiants obsolètes une fois les besoins de reprise et de retour en arrière résolus. Consignez la configuration finale DNS et du certificat. Lorsque vous choisissez un hébergement web ou des ressources de calcul SwissOctet, confirmez le domaine réel, le certificat et les responsabilités d'administration pour la configuration. Le catalogue fournit une destination d'hébergement et des ressources ; il n'établit pas que votre domaine a déjà été connecté ni que le renouvellement du certificat a été configuré. Gardez ces étapes concrètes et vérifiables dans le plan de déploiement. PASSEZ À L'ACTION Votre liste de contrôle pratique. ✓ Inventoriez chaque nom d'hôte et préservez les enregistrements DNS sans rapport. ✓ Testez le routage des noms d'hôte avant la bascule publique. ✓ Choisissez et automatisez une méthode de validation de certificat adaptée. ✓ Planifiez les modifications de TTL et la transition des données. ✓ Vérifiez DNS et TLS au moyen de contrôles distincts. ✓ Conservez l'accès au retour en arrière et résolvez les nouvelles écritures avant de revenir en arrière. Télécharger la liste de contrôle QUESTIONS FRÉQUENTES Les détails qui comptent. La modification d'un enregistrement A active-t-elle HTTPS ? + Non. DNS choisit un point de terminaison ; ce point de terminaison a toujours besoin du routage de nom d'hôte correct et d'un certificat valide installé. Puis-je revenir uniquement sur l'enregistrement DNS si quelque chose casse ? + Le trafic peut être redirigé, mais les écritures applicatives nécessitent un traitement distinct. Définissez un plan de retour en arrière ou de réconciliation des données avant la migration. Un certificat wildcard est-il toujours nécessaire ? + Non. Choisissez les noms de certificat et la validation en fonction des noms d'hôte réels. Un wildcard a des exigences de couverture et de validation spécifiques ; ce n'est pas un raccourci de migration universel. RÉFÉRENCES PRINCIPALES Allez à la source. Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production. Let's Encrypt : types de validation letsencrypt.org IETF RFC 1034 : concepts et fonctionnalités de DNS datatracker.ietf.org Mozilla MDN : Transport Layer Security developer.mozilla.org Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément. CONNECTEZ LES CONNAISSANCES Infrastructure associée. Canvas Web Suisse Vector VPS Suisse Pulse NVMe Suisse GARDEZ LE FIL Vos prochaines notes de terrain. Explorez tous les guides NOTE DE TERRAIN / 01 + Cloud et VPS Fondation Comment choisir un VPS sans deviner Transformez une idée d'application en un budget de ressources utile, puis comparez ensemble le CPU, la mémoire, le stockage et le transfert. 4 min de lecture Lire le guide NOTE DE TERRAIN / 02 + Web et onion Fondation Hébergement web ou un VPS : choisissez le travail que vous voulez assumer Comparez les exigences applicatives, le contrôle et les responsabilités de maintenance plutôt que de considérer un VPS comme l'étape suivante automatique pour chaque site web. 6 min de lecture Lire le guide NOTE DE TERRAIN / 03 + Web et onion Appliqué Publier un service onion sans négliger l'application Planifiez une publication onion légitime avec une exposition contrôlée du backend, une revue attentive du contenu, une récupération des clés de service et un modèle explicite d'accès du public. 4 min de lecture Lire le guide