Comprendre le TTL DNS : pourquoi les changements tardent

Chaque enregistrement DNS porte un TTL (durée de vie) exprimé en secondes. C'est une instruction du serveur de noms faisant autorité du domaine à tout résolveur qui récupère l'enregistrement : « vous pouvez réutiliser cette réponse pendant cette durée avant de redemander ». Un TTL de 300 secondes signifie qu'un résolveur qui vient de chercher un domaine ne prendra pas la peine de redemander avant cinq minutes, même si l'enregistrement change entre-temps.

Le compromis que le TTL équilibre

Un TTL plus long signifie moins de requêtes DNS, des recherches plus rapides en moyenne (puisque davantage de demandes sont servies depuis le cache) et moins de charge sur les serveurs de noms faisant autorité. Un TTL plus court signifie qu'une modification de l'enregistrement se propage plus vite, au prix de requêtes plus fréquentes. Il n'existe pas de valeur universellement correcte : elle dépend de la fréquence à laquelle l'enregistrement devrait changer et de la tolérance de la situation aux réponses périmées.

Ce qui se passe réellement lors d'un changement

Mettre à jour un enregistrement DNS ne pousse pas la modification vers tous les résolveurs de l'internet. Cela change seulement ce que le serveur de noms faisant autorité répondra la prochaine fois qu'on l'interrogera. Chaque résolveur qui a déjà mis l'ancienne réponse en cache continue de la servir jusqu'à l'expiration du TTL de sa copie : c'est pourquoi un même domaine peut brièvement se résoudre vers des adresses différentes selon le résolveur, et le cache, qui répond.

• Une démarche pratique courante avant une migration planifiée consiste à abaisser le TTL un jour ou deux à l'avance, pour que la bascule finale se propage plus vite.
• Après la migration, le TTL est généralement remonté à sa valeur normale.
• Un enregistrement sans changement récent et avec un TTL long peut tout de même nécessiter toute la fenêtre de ce TTL pour disparaître entièrement des caches dans le monde une fois qu'il change.

Choisir un TTL en pratique

Les réponses négatives sont elles aussi mises en cache, ce qui se remarque peu. Lorsqu'un domaine n'existe pas, la réponse NXDOMAIN elle-même est mise en cache, régie par une valeur distincte (le TTL minimal de l'enregistrement SOA, et non le TTL d'un enregistrement qui n'a jamais existé). Un domaine fraîchement enregistré peut parfois sembler ne pas se résoudre pendant un court laps de temps simplement parce qu'un résolveur avait déjà mis en cache son NXDOMAIN d'avant la fin de l'enregistrement.

Le TTL est une demande, pas une garantie

Il faut savoir qu'un TTL est indicatif, et qu'aucune autorité extérieure ne l'impose. Un résolveur est techniquement libre de conserver une réponse en cache plus longtemps que le TTL indiqué (certains le font, sous forte charge, pour réduire le volume de requêtes) ou de l'évincer plus tôt (un résolveur à court de mémoire peut abandonner des entrées de cache prématurément). Dans l'immense majorité des cas, les résolveurs publics et de FAI bien exploités respectent les TTL de près et de façon prévisible ; mais c'est la raison pour laquelle une estimation de propagation fondée sur le TTL est une solide règle empirique plutôt qu'une garantie ferme et contractuelle. Si un changement n'est toujours pas visible de façon significative au-delà de l'ancienne fenêtre de TTL, un cache intermédiaire particulièrement agressif est l'une des explications moins courantes, mais bien réelles, à garder à l'esprit.

Si vous vérifiez qu'un changement DNS est bien entré en vigueur, une seule recherche ne vous dit que ce qu'un résolveur a actuellement en cache. Relancer la recherche à quelques minutes d'intervalle, ou planifier une vérification récurrente, est un moyen bien plus fiable de confirmer qu'un changement s'est effectivement propagé, plutôt que de tomber une fois sur une ancienne réponse en cache et de la croire définitive.