Combien de temps les clients ont-ils continué à utiliser l'ancienne adresse après un changement DNS, et quels résolveurs ou clients ont ignoré le TTL ?

Question ouverte

La RFC 1035 définit le TTL d'un enregistrement de ressource comme l'intervalle de temps pendant lequel l'enregistrement peut être mis en cache avant qu'il ne faille consulter de nouveau la source de l'information. La procédure de changement standard en découle : abaisser le TTL bien avant le changement, laisser s'écouler l'ancien TTL, basculer l'enregistrement, puis observer l'ancienne adresse se vider progressivement de son trafic. La RFC 8767 ajoute une exception documentée, serve-stale, selon laquelle un résolveur récursif peut continuer à utiliser des données expirées lorsque les serveurs faisant autorité sont inaccessibles. Au-delà des standards, le folklore est long : des résolveurs qui relèvent les TTL très courts, des environnements d'exécution applicatifs qui mettent en cache les résolutions pour toute la durée de vie du processus, des pools de connexions qui ne résolvent jamais de nouveau parce que leurs connexions ne se ferment jamais, et des réseaux mobiles avec leurs propres couches de cache.

Ce qui manque au wiki, ce sont des courbes de vidange mesurées. Après un changement d'enregistrement sur un site à trafic significatif, comment le taux de requêtes vers l'ancienne adresse a-t-il décru dans le temps : l'essentiel dans le délai du TTL, un coude correspondant au minimum de certains résolveurs, et une traîne durant plusieurs jours ? Qu'y avait-il dans cette traîne : quels réseaux de résolveurs, quelles bibliothèques clientes, quels types de processus (workers de longue durée, sondes de supervision, robots d'indexation) ? Abaisser au préalable le TTL à une valeur très faible a-t-il réellement raccourci la vidange, ou certains grands résolveurs ont-ils ignoré les valeurs en dessous d'un plancher ? Pendant combien de temps l'ancienne adresse a-t-elle dû rester en service avant que le trafic résiduel ne soit assez faible pour être coupé, et à quoi ressemblaient les dernières requêtes ?

La réponse transformerait une procédure aujourd'hui menée par intuition (« attendre un jour, puis un peu plus ») en une procédure dont le temps de vidange serait connu pour chaque population de clients.

Ce qu'une réponse utile contient

Le type d'enregistrement et le TTL avant l'abaissement, après l'abaissement et au moment du basculement ; le délai entre l'abaissement et le basculement. Le nombre de requêtes vers l'ancienne et la nouvelle adresse par heure après le basculement, pendant au moins plusieurs fois la durée du TTL, idéalement sous forme de tableau plutôt que de description. L'attribution de la traîne : par résolveur (à partir de l'adresse du résolveur interrogateur relevée au serveur faisant autorité, si elle est journalisée), par agent utilisateur du client, par réseau client. Quelles sources de la traîne ont été corrigées côté client (un worker redémarré, une mise à niveau de bibliothèque) et lesquelles ont simplement expiré. Si un comportement serve-stale a été observé, c'est-à-dire des requêtes sur l'ancien enregistrement après une interruption du service faisant autorité. Si un changement effectué avec un TTL long a déjà été comparé à un changement avec un TTL court sur la même population. Un seul changement bien journalisé constitue déjà une réponse utile ; plusieurs sur le même site permettent une comparaison réelle.