Enregistrements DNS et TTL : préparez un changement vérifiable
DNS indique aux clients où chercher un service. Cela ne déplace pas les données applicatives, n'installe pas de certificat et ne rend pas un nouveau serveur prêt. Un changement fiable commence par un inventaire des enregistrements et se termine par des preuves DNS et une application fonctionnelle.
L'essentiel à retenir
Modifiez les enregistrements qui contrôlent réellement le service, tenez compte des durées de cache existantes, vérifiez séparément les réponses faisant autorité et les réponses récursives, et gardez le point de terminaison précédent sous contrôle.
Sachez à quoi sert chaque enregistrement
| Type | Rôle | À vérifier avant un changement d'hébergement |
|---|---|---|
| A | Associe un nom à une adresse IPv4 | La cible sert le nom d'hôte prévu et la configuration HTTPS |
| AAAA | Associe un nom à une adresse IPv6 | IPv6 atteint le même service fonctionnel qu'IPv4 |
| CNAME | Crée un alias d'un nom vers un autre nom | La cible est un nom d'hôte, pas une adresse IP ni une URL complète |
| MX | Identifie les destinations de livraison du courrier | Les changements du site ne redirigent pas involontairement le courrier entrant |
| TXT | Porte des vérifications et d'autres politiques textuelles | Les enregistrements de propriété et d'authentification de la messagerie requis restent intacts |
| CAA | Restreint la délivrance de certificats par les autorités de certification | L'émetteur de certificat prévu est compatible avec la politique |
Par exemple, example.com peut avoir un enregistrement A et www.example.com peut le référencer via un CNAME. Vérifiez les deux noms visibles par les utilisateurs. Un changement d'adresse du premier peut affecter l'alias, tandis qu'un nom d'hôte sans rapport peut toujours pointer directement vers l'ancien serveur. Les fonctionnalités d'alias à l'apex de zone varient selon le fournisseur DNS ; suivez son mécanisme documenté plutôt que de supposer que toute interface accepte un CNAME ordinaire à l'apex.
Ne laissez pas un ancien enregistrement AAAA en place lorsque la destination IPv4 change. Certains clients peuvent continuer à atteindre le service IPv6 obsolète tandis que d'autres utilisent la nouvelle adresse IPv4. Confirmez la disponibilité IPv6 prévue avant de publier ce chemin. De même, un déplacement de site web n'est pas une raison de remplacer les enregistrements MX ou TXT lorsque le service de messagerie reste où il est.
Tenez compte des réponses déjà en cache
TTL attribue une durée de cache à une réponse DNS. La réduire sur l'enregistrement faisant autorité ne raccourcit pas une réponse plus ancienne déjà mise en cache ailleurs. Si la valeur existante est de 86 400 secondes et que vous souhaitez une valeur de 300 secondes pour un basculement prévu, abaissez-la suffisamment à l'avance pour que l'ancienne durée soit écoulée. Ces valeurs illustrent la planification ; les options disponibles dépendent du service DNS et de l'enregistrement.
DNS peut aussi mettre en cache une réponse indiquant qu'un nom n'existe pas ou ne possède pas l'enregistrement demandé. Ce cache négatif est régi par les règles DNS et les informations de zone, et non par le TTL d'un enregistrement que vous ajoutez ensuite. Évitez de le découvrir lors d'un lancement en ne testant le nouveau nom d'hôte qu'après l'avoir délibérément publié et pris en compte dans le plan.
Un TTL n'est pas un compte à rebours vers une bascule mondiale simultanée. Les clients, les résolveurs récursifs et les connexions applicatives existantes ne se rafraîchissent pas tous ensemble. Maintenez l'ancien point de terminaison sous contrôle pendant la période de chevauchement. Si l'application accepte les écritures, le plan de migration doit définir une autorité de données unique tant que le trafic peut encore arriver sur plusieurs adresses.
Vérifiez la réponse DNS, puis le service qui se trouve derrière
- Consignez la valeur précédente et le remplacement exact prévu.
- Interrogez chaque serveur de noms faisant autorité pour le nom et le type d'enregistrement concernés.
- Comparez les réponses de plusieurs résolveurs récursifs et notez les TTL restants.
- Vérifiez chaque nom d'hôte public et les deux familles d'IP réellement publiées.
- Testez HTTPS et le comportement applicatif représentatif en utilisant le vrai nom d'hôte.
- Observez le trafic résiduel avant d'augmenter le TTL ou de retirer l'ancien point de terminaison.
Distinguez une erreur faisant autorité d'une ancienne réponse mise en cache. Si les serveurs faisant autorité divergent, examinez la publication de la zone ou la délégation. Si l'autorité est correcte mais qu'un résolveur conserve encore une réponse plus ancienne, comparez sa durée de vie restante avant d'effectuer une autre modification sans rapport. Des changements de valeurs répétés peuvent rendre la fenêtre d'observation plus difficile à interpréter.
Une réponse d'adresse correcte ne prouve ni un certificat valide ni un hôte virtuel fonctionnel. HTTPS utilise le nom d'hôte demandé, et l'application doit le reconnaître. Si un proxy ou un CDN fait partie de la conception, identifiez quelle adresse renvoyée représente cet intermédiaire et quel réglage d'origine contrôle son backend. Conservez le résultat DNS et le test du service d'origine comme des vérifications distinctes.
Protégez la validation DNSSEC et gardez un retour arrière réaliste
Si DNSSEC est activé, une migration de serveur de noms ou de fournisseur de signature doit tenir compte de l'enregistrement DS parent et des nouvelles clés de signature. Une incohérence peut amener les résolveurs validants à rejeter les réponses. Suivez la procédure de migration documentée pour les deux fournisseurs et le registraire, y compris les durées de cache applicables. Ne supprimez pas les enregistrements de confiance et ne désactivez pas la validation comme première réponse improvisée à une erreur web inexpliquée.
Conservez les valeurs DNS précédentes avec le journal des modifications, mais gardez à l'esprit ce qu'elles peuvent annuler. Restaurer une ancienne adresse modifie la destination des résolutions futures ; cela ne recopie pas les données client acceptées par la nouvelle application. Utilisez le plan de migration distinct pour décider quand un retour arrière du trafic est sûr et quand une réconciliation des données est nécessaire. Ne terminez qu'après avoir vérifié l'application, les dépendances de messagerie et les copies de récupération.
