Propagation DNS : diagnostiquer une ancienne IP après une migration

Votre serveur a changé d’adresse, mais certains visiteurs arrivent encore sur l’ancien site. Le travail de Cloudflare sur son cache DNS rappelle que chaque résolveur conserve ses propres réponses : la « propagation » n’est pas une diffusion instantanée.

Intention de recherche : distinguer une réponse en cache d’une zone mal modifiée, puis préparer une migration. Les domaines et adresses ci-dessous sont fictifs ; remplacez-les par vos valeurs.

1. Diagnostiquer avant de toucher à la zone

Modifier un A change la réponse IPv4 du serveur autoritatif. Un résolveur récursif peut conserver l’ancienne réponse pendant son TTL restant. Les caches du système et de l’application ajoutent d’autres couches ; un AAAA oublié peut envoyer les clients IPv6 ailleurs.

Relevez les NS, puis interrogez chacun directement. Remplacez ns1.example.net par un NS réellement délégué :

L’autoritatif doit présenter le drapeau aa et la nouvelle IP. Si plusieurs NS divergent, corrigez leur cohérence avant d’accuser les caches. Dans une réponse fictive example.com. 240 IN A 192.0.2.10, 240 est le TTL restant en secondes. Si tous les autoritatifs donnent 192.0.2.20 mais un résolveur donne encore 192.0.2.10, une ancienne réponse en cache est plausible. Relevez l’heure et répétez après expiration ; ce test n’est pas une preuve universelle, notamment avec un DNS géographique.

Un NXDOMAIN récent peut aussi être mémorisé : créer le nom ne supprime pas immédiatement ce cache négatif.

2. Préparer puis effectuer la bascule

Risque : couper l’ancien serveur trop tôt interrompt les utilisateurs encore dirigés vers lui. Deux bases acceptant des écritures indépendantes peuvent aussi diverger.

1. Exportez les valeurs A/AAAA et TTL actuels. Testez le nouveau serveur, son certificat et ses données avant la modification.
2. Abaissez le TTL des enregistrements concernés, par exemple de 3600 à 300 secondes si le fournisseur l’autorise. Attendez au moins l’ancien TTL avant la bascule : une baisse n’écourte pas les réponses déjà mémorisées.
3. Préparez la continuité applicative : stockage partagé, réplication contrôlée ou fenêtre sans écritures. Conservez l’ancien service opérationnel.
4. Remplacez uniquement les adresses prévues, IPv4 et IPv6 selon votre architecture. Exemple de nouvelle entrée :

1. Comparez à nouveau les NS et les résolveurs. Notez erreurs HTTP, connexions et trafic restant sur l’ancienne machine avant de relever le TTL.

Retour arrière

Restaurez les anciennes valeurs sauvegardées si le nouveau serveur échoue. Gardez les deux destinations disponibles pendant la convergence inverse et réconciliez les écritures avant de réouvrir un ancien jeu de données. Le rollback DNS est lui aussi soumis aux caches.

3. Vérification finale

Tous les NS doivent être cohérents ; les résolveurs échantillonnés doivent progressivement répondre avec la destination attendue. Testez le site depuis un autre réseau, en IPv4 et IPv6 si disponibles. Si les IP sont correctes mais le contenu reste ancien, examinez le cache HTTP, le proxy et le déploiement.

Erreurs courantes

Vider votre cache local ne vide pas ceux des visiteurs. Un TTL de 300 n’est pas une garantie mondiale de cinq minutes. Ne changez pas les nameservers pour corriger un simple A, et ne prenez pas une IP de proxy pour celle du serveur d’origine.

Sources : Cloudflare, fonctionnement de son cache DNS, ISC, outils BIND.