Le TTL d’un enregistrement DNS, c’est sa durée de mise en cache : à 24 heures, un résolveur qui a lu votre adresse la conserve jusqu’à 24 heures avant de redemander. Toute la difficulté d’une bascule tient dans ce chiffre. Vous changez l’adresse le jour J, mais une partie des résolveurs de la planète gardent l’ancienne tant que leur cache n’a pas expiré, et vos visiteurs continuent d’arriver sur le serveur que vous vouliez éteindre.
Voici la séquence que j’applique, dans l’ordre.
Une bascule DNS propre se joue surtout en amont : on abaisse le TTL plusieurs jours avant pour que le changement se propage en minutes le jour J, on laisse l’ancien et le nouveau serveur tourner ensemble le temps que les caches expirent, et on n’éteint l’ancien que quand ses journaux ne montrent plus aucun trafic.
1. J-7 : abaisser le TTL. Je descends la valeur à 300 secondes, une semaine avant la date. C’est l’étape qu’on rate le plus souvent en la faisant trop tard. J’ai vu une équipe baisser le TTL le matin même de la bascule : la valeur de 24 h était déjà partie en cache la veille, et il a fallu attendre presque une journée pleine que les derniers résolveurs lâchent prise. Un TTL ne s’applique qu’aux requêtes encore à venir. Une fois la vieille valeur logée chez un résolveur, elle y reste jusqu’à son terme. D’où le délai : on l’abaisse avant que les caches se remplissent, donc des jours plus tôt.
2. Jour J, avant tout : synchroniser le dernier delta. Le delta, c’est l’écart accumulé : tout ce qui a changé depuis la copie initiale. Sur un site qui prend des écritures, commandes, comptes, paniers, tout ce qui a atterri sur l’ancien serveur depuis cette copie doit être rejoué sur le nouveau. Sinon ces données disparaissent dans la bascule. Je rejoue donc ce delta juste avant de toucher à l’enregistrement, quand l’écart est le plus petit possible.
3. Changer l’enregistrement, et laisser les deux serveurs tourner. Pendant la fenêtre de propagation, l’ancien et le nouveau servent en même temps. Le trafic glisse de l’un vers l’autre au rythme où les caches expirent. Si les deux exposent la même application sur des données synchronisées, le visiteur ne perçoit aucune transition. Cette synchronisation est le point sensible de tout l’exercice ; c’est pour elle qu’on garde les deux machines vivantes.
4. Lire les journaux, pas l’horloge. Je ne déclare jamais une bascule réussie au seul vu du changement DNS. Je surveille les logs des deux serveurs. Tant que l’ancien reçoit des requêtes, la propagation n’est pas finie. Attendez-vous à une traîne : un résolveur d’entreprise mal réglé, un client qui ignore votre TTL, un script avec l’IP en dur. Ce sont eux qui maintiennent un filet de requêtes longtemps après que le gros du trafic a basculé.
5. J+quelques jours : éteindre l’ancien. On ne coupe l’ancien serveur que lorsque ses journaux ne montrent plus rien depuis un délai franc, pas depuis dix minutes. Le double run a un coût, une semaine de facturation en parallèle côté hébergeur, et c’est précisément ce coût qui rend chaque étape réversible jusqu’au dernier moment.
Avant de débrancher, je relance un tail -f sur l’access log de l’ancien serveur et je le regarde rester muet pendant une bonne heure pleine. S’il l’est, je coupe.
À lire aussi
- Passer à Scaleway
- Répondre à un appel d’offres exigeant la souveraineté des données
- Lire et décomposer une facture AWS pour préparer sa sortie
- Cloud à l’usage ou dédié : le vrai calcul pour une charge stable
- Souveraineté et RGPD : ce que change un hébergement en France
- Migrer une base managée (RDS) vers un PostgreSQL auto-géré