TTL DNS : la durée de vie d'un enregistrement

Ce que mesure le TTL

Quand un internaute ouvre votre site, son fournisseur d'accès demande l'adresse du domaine aux serveurs DNS qui le gèrent, puis garde la réponse en cache. Tant que le TTL n'est pas écoulé, il resservira cette réponse sans redemander. Si vous changez l'adresse pendant ce temps, ce fournisseur continue d'envoyer ses abonnés vers l'ancienne jusqu'à expiration.

La RFC 2181 fixe le cadre : un TTL est un nombre de secondes, de 0 à 2 147 483 647. Elle précise qu'il s'agit d'une durée maximale, et que chaque serveur reste libre de garder moins longtemps. Elle demande aussi que tous les enregistrements d'un même nom et d'un même type portent le même TTL.

Les valeurs courantes

Il n'y a pas de bonne valeur universelle. Un TTL court rend les changements rapides au prix de requêtes plus nombreuses, sans effet visible pour un site ordinaire. Un TTL long ne fait gagner presque rien et ralentit chaque correction. Chez Cloudflare, la valeur « Auto » vaut 300 secondes, et un enregistrement passé par son proxy garde toujours cette valeur, d'après sa documentation sur le TTL.

Lire le TTL d'un enregistrement

La commande dig, disponible sous macOS et Linux, affiche le TTL dans la deuxième colonne de la réponse :

dig A exemple.fr

exemple.fr.    3600    IN    A    203.0.113.10

Interrogé auprès d'un serveur de cache, ce chiffre décroît à chaque nouvelle demande : il indique le temps qui reste avant que ce serveur ne redemande. Pour lire la valeur réglée dans la zone, interrogez directement un serveur qui fait autorité pour le domaine, dont le nom se trouve avec dig NS exemple.fr +short :

dig A exemple.fr @ns1.netim.net

Remplacez ns1.netim.net par l'un des serveurs que la commande dig NS vous a renvoyés.

Baisser le TTL avant un changement

C'est le seul réglage de TTL qui demande de l'attention. Le principe tient en une règle : baissez le TTL des enregistrements à modifier (A, AAAA, MX) au moins une durée d'ancien TTL avant le changement, puis remontez-le une fois que tout fonctionne. Les deux gestes à retenir :

1. Baisser trop tard ne sert à rien : les caches gardent l'ancienne valeur pour toute la durée qu'ils avaient reçue.
2. Vérifier avec `dig` auprès d'un serveur qui fait autorité, comme plus haut, avant de conclure.

L'ordre complet d'une bascule, ancien hébergement gardé en route compris, est dans La propagation DNS.

Ce que le TTL ne règle pas

• Le changement de serveurs de noms. Les serveurs de noms d'un domaine sont publiés par le registre de l'extension, avec son propre TTL, que vous ne réglez pas. Un changement de serveurs DNS prend donc souvent plus longtemps qu'un changement d'adresse. Voir Changer les serveurs DNS.
• Les réponses négatives. Un nom qui n'existait pas reste « inexistant » dans les caches pendant une durée fixée par l'enregistrement SOA de la zone, d'après la RFC 2308. Un sous-domaine tout juste créé peut donc rester introuvable un moment pour qui l'a cherché trop tôt.
• Les caches locaux. Le navigateur et l'ordinateur gardent aussi les réponses. Vider le cache DNS les remet à zéro.

Chez Hubspace

Nous n'hébergeons pas de zone DNS publique : le TTL se règle chez le gestionnaire de votre zone. Pour un domaine enregistré chez nous, c'est par défaut la zone servie par notre bureau d'enregistrement partenaire, Netim, que vous modifiez vous-même ou que nous réglons pour vous sur simple demande. Lors d'une migration, nous préparons votre site avant de toucher au domaine et vous envoyons les valeurs à saisir : baisser le TTL la veille rend la bascule plus rapide.

Questions fréquentes