Réduire le TTL avant une migration

Chaque enregistrement DNS a un TTL (durée de vie) en secondes. Il indique aux résolveurs combien de temps ils peuvent réutiliser une réponse en cache avant de redemander. Avec un TTL de 86400, un résolveur qui a consulté votre domaine juste avant la bascule peut continuer d’envoyer ses utilisateurs vers l’ancien serveur pendant une journée entière.

Réduire le TTL n’accélère rien en soi. Cela raccourcit la prochaine période de cache. C’est pourquoi le moment compte : le TTL court ne prend effet qu’une fois l’ancien TTL, plus long, écoulé dans chaque cache qui détient l’enregistrement.

1. 1

   Étape 1 : Vérifier le TTL actuel

   Relevez le TTL de chaque enregistrement que vous allez modifier avec le vérificateur de TTL ou dig, et notez la valeur la plus élevée.

2. 2

   Étape 2 : Passer le TTL à 300 secondes

   Dans le panneau de votre fournisseur DNS, modifiez uniquement le TTL de ces enregistrements pour le passer à 300. Laissez-les pointer vers l’ancien serveur.

3. 3

   Étape 3 : Attendre un ancien TTL

   Attendez au moins la durée de l’ancien TTL noté, pour que toutes les copies en cache avec le TTL long aient expiré.

4. 4

   Étape 4 : Basculer les enregistrements

   Faites pointer les enregistrements vers le nouveau serveur. La plupart des visiteurs y arrivent en cinq minutes ; suivez la progression avec le vérificateur de propagation DNS.

5. 5

   Étape 5 : Remonter le TTL

   Quelques jours après la migration, une fois sûr de ne pas revenir en arrière, repassez le TTL à 3600 secondes ou plus.

Le vérificateur de TTL gratuit affiche le TTL de chaque enregistrement d’un domaine. Dans un terminal, le nombre qui suit le nom est le TTL en secondes :

dig example.com A +noall +answer
# example.com.   3600   IN   A   198.51.100.7

Resolve-DnsName -Name example.com -Type A | Format-Table Name, TTL, IPAddress

• A et AAAA pour le domaine et pour www, ainsi que tout autre nom d’hôte qui pointe vers l’ancien serveur, comme shop ou api.
• CNAME qui pointeront vers une nouvelle destination.
• MX seulement si la messagerie migre aussi. Si elle reste en place, ne touchez pas aux MX.
• TXT comme SPF, si les serveurs d’envoi changent.

Les enregistrements que vous ne modifiez pas peuvent garder leur TTL. Si vous transférez la zone DNS chez un autre fournisseur (changement de serveurs de noms), le TTL de chaque enregistrement aide moins : la délégation au registre a son propre TTL, que vous ne pouvez pas modifier, souvent un à deux jours. Dans ce cas, copiez d’abord tous les enregistrements dans la nouvelle zone et comparez les deux côtés avec le Comparateur DNS avant de changer les serveurs de noms. Le vérificateur de serveurs de noms montre ce que le registre distribue.

300 secondes est le choix habituel. C’est assez court pour qu’une bascule ou un retour en arrière atteigne la plupart des visiteurs en quelques minutes, et assez long pour ne pas surcharger votre fournisseur DNS. Descendre plus bas, par exemple à 60 secondes, aide rarement en pratique : certains résolveurs appliquent de toute façon une durée de cache minimale, et les navigateurs et systèmes d’exploitation ont leurs propres caches courts.

Certains panneaux DNS refusent les valeurs sous un minimum, ou présentent le TTL sous forme de menu avec des noms comme « Auto ». Avec un enregistrement proxifié sur un CDN comme Cloudflare, le TTL choisi n’a aucune importance pour la bascule : les visiteurs résolvent vers le CDN, et c’est l’origine dans le CDN que vous modifiez.

• Le réduire le jour de la bascule. Les caches qui détiennent déjà l’enregistrement avec un TTL d’un jour le gardent jusqu’à un jour, TTL court ou non.
• Modifier la mauvaise zone. Si les serveurs de noms du domaine pointent vers Cloudflare, modifier la zone chez le registrar ne sert à rien. Vérifiez d’abord quels serveurs de noms font autorité.
• Oublier www et l’IPv6. Le domaine nu bascule en quelques minutes alors que www ou un enregistrement AAAA porte encore l’ancienne IP avec un TTL long.
• Ne jamais le remonter. Un TTL permanent de 300 secondes fonctionne, mais implique plus de requêtes et moins de protection en cas de panne de votre fournisseur DNS.
• Attendre du TTL qu’il règle un CDN. Avec un enregistrement proxifié, les visiteurs résolvent vers le CDN dans tous les cas ; le changement se fait dans les réglages d’origine du CDN.

Un TTL court est aussi votre filet de sécurité. Si quelque chose se passe mal après la bascule, repointer l’enregistrement vers l’ancien serveur atteint les visiteurs tout aussi vite, tant que l’ancien serveur tourne encore. Gardez-le jusqu’à ce que la migration soit stabilisée. La journée entre la réduction du TTL et la bascule est le moment idéal pour vérifier le nouveau serveur. Ouvrez le site sur la nouvelle IP avec un lien d’aperçu DNSPeek, lancez un rapport QA et envoyez le lien aux personnes qui doivent le valider. Le rapport QA lit aussi le DNS du domaine et vous rappelle de réduire le TTL s’il est encore long.