Après avoir modifié l'enregistrement DNS, tout le monde ne peut pas voir le même résultat en même temps. Les couches TTL et cache sont des éléments essentiels de la planification de la migration.

Approche de base

TTL spécifie la durée pendant laquelle une réponse DNS peut être mise en cache. La mise à jour que vous effectuez sur le serveur autorisé ne raccourcit pas rétroactivement la durée de vie restante d'un enregistrement précédemment acquis. Le client, le navigateur et le résolveur récursif peuvent avoir différentes couches de mise en cache.

Étapes de candidature

  1. Enregistrez la valeur TTL avant le changement et l'heure de commutation prévue.
  2. Comparez la réponse du serveur proxy avec la réponse du résolveur utilisé par le client.
  3. Planifier pour garantir que l'ancienne et la nouvelle cible puissent être servies pendant la transition ; Ne comptez pas uniquement sur la suppression du cache local.

Exemple pratique

Si l'IP est modifiée à 14h00 alors que le TTL est d'une heure, un résolveur qui reçoit l'ancienne réponse à 13h59 peut l'utiliser pour le temps restant. Réduire la durée de vie juste avant le changement ne rafraîchit pas instantanément les anciens caches.

Interpréter correctement le résultat

Tous les retards ne sont pas des propagations DNS. Un proxy incorrect, un enregistrement manquant ou un cache d'application peuvent également créer la même image. Noter l'heure, le serveur interrogé et la valeur renvoyée montre ensemble quelle couche est laissée pour compte.

Source et lecture de suivi

Détails du protocole ou de la commande : RFC1034. Les étapes et l'exemple de scénario sont le récit éditorial d'IPScans.