Après une migration, l'ancien site continue d'apparaître. Avant d'attendre davantage, découvrez lequel des trois c'est : le changement ne s'est pas propagé, quelque chose de local met en cache, ou l'enregistrement que vous avez modifié n'est pas celui qui sert.

Interroger directement le serveur faisant autorité

dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @ns1.yourprovider.com    # the authority itself

Si l'autorité renvoie déjà la nouvelle IP, le changement est fait et tout le reste est du cache. Si elle renvoie l'ancienne, l'enregistrement n'a pas été enregistré, ou il l'a été chez un prestataire qui n'assure plus votre DNS.

Quels serveurs de noms sont réellement aux commandes

dig +short NS yourdomain.com
whois yourdomain.com | grep -i "name server"
C'est la panne qui coûte une journée : la zone a été modifiée chez l'ancien hébergeur alors que le registraire fait pointer le domaine vers un autre prestataire. L'enregistrement est parfait et personne ne le lit.

Si c'est du cache

# your own machine
sudo systemd-resolve --flush-caches || sudo resolvectl flush-caches
# then check what the TTL was
dig yourdomain.com | grep -A1 "ANSWER SECTION"

Le TTL indique combien de temps on a dit aux résolveurs de garder l'ancienne réponse. Un TTL de 86400 veut dire jusqu'à un jour, et rien de ce que vous faites n'accélère cela pour quelqu'un d'autre. Abaissez le TTL à 300 un jour AVANT un déménagement prévu.

Et les enregistrements oubliés

  • www en plus du domaine nu.
  • L'enregistrement AAAA, s'il y a de l'IPv6 - voyez IPv6 sur un VPS.
  • Un CNAME qui pointe encore sur l'ancien hébergeur.
  • Un CDN, qui a sa propre idée de votre origine indépendamment du DNS.
Testez le nouveau serveur avant de déplacer quoi que ce soit, avec une entrée dans le fichier hosts de votre propre machine. Le changement DNS devient alors la dernière étape et non l'expérience - voyez migrer sans interruption.