TTL DNS : définition, valeurs conseillées et quand le baisser
Ce que signifie le TTL en DNS, comment les résolveurs le décomptent, quelles valeurs choisir, le cache négatif et comment préparer un changement.
Publié: · 7 min de lecture
Le TTL (« time to live », durée de vie) est le nombre attaché à chaque enregistrement DNS qui indique pendant combien de secondes un résolveur peut conserver la réponse en cache avant de devoir la redemander. C'est le seul véritable levier dont vous disposez sur la vitesse à laquelle une modification DNS atteint les utilisateurs, et c'est lui qui explique le temps que prend la fameuse « propagation DNS ».
Comment fonctionne le TTL
Chaque enregistrement d'une zone porte un TTL :
www.example.com. 3600 IN A 192.0.2.10
Lorsqu'un résolveur récursif (celui de votre fournisseur d'accès, de votre entreprise, ou un résolveur public comme 1.1.1.1 ou 8.8.8.8) récupère cet enregistrement auprès du serveur faisant autorité, il le stocke et lance un décompte à partir de 3600. Quiconque interroge ce résolveur dans l'heure qui suit reçoit la copie en cache, accompagnée du TTL restant. Quand le compteur atteint zéro, l'entrée est supprimée et la requête suivante déclenche une nouvelle recherche.
Vous pouvez l'observer vous-même :
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3412 IN A 192.0.2.10
$ dig +noall +answer www.example.com @1.1.1.1
www.example.com. 3397 IN A 192.0.2.10
Le second nombre a diminué. Interrogez directement le serveur faisant autorité, et vous verrez toujours la valeur complète, telle qu'elle est configurée :
$ dig +noall +answer www.example.com @ns1.dns.example
www.example.com. 3600 IN A 192.0.2.10
Cette différence fournit un diagnostic commode : un TTL inférieur à la valeur configurée signifie que vous regardez un cache.
Trois conséquences découlent de ce mécanisme :
- Rien n'est poussé. Modifier un enregistrement ne prévient aucun résolveur. Chaque cache garde l'ancienne réponse jusqu'à la fin de son propre décompte.
- Les caches expirent à des moments différents, puisque chacun a récupéré l'enregistrement à un instant différent. Pendant une durée pouvant aller jusqu'à un TTL après la modification, tous les utilisateurs ne voient pas la même réponse. La propagation DNS n'est rien d'autre.
- Le TTL qui compte, c'est l'ancien. Un résolveur qui a mis l'enregistrement en cache hier avec un TTL de 86400 le conservera jusqu'au bout de ces 24 heures, quelle que soit la valeur que vous fixez aujourd'hui.
Les caches qui vous échappent
Le résolveur récursif n'est pas le seul cache. Systèmes d'exploitation, navigateurs et applications ont le leur, et tous ne respectent pas le TTL à la lettre : les navigateurs conservent les adresses pendant une courte durée fixe, et les applications qui tournent longtemps (les anciennes versions de Java en sont l'exemple classique) peuvent garder un résultat aussi longtemps que vit le processus. Certains résolveurs appliquent en outre un plancher ou un plafond : un TTL de 5 secondes peut être traité comme 30 ou 60, et les TTL très longs peuvent être ramenés à une journée environ. Un résolveur peut aussi servir brièvement des données expirées lorsque les serveurs faisant autorité sont injoignables.
Le TTL est donc une indication forte, pas une garantie, et il serait malhonnête de promettre qu'une modification est visible « partout » au bout d'exactement N secondes.
Le cache négatif : le TTL du « n'existe pas »
Un résolveur met aussi en cache les réponses « ce nom n'existe pas » (NXDOMAIN) et « ce nom n'a aucun enregistrement de ce type ». La durée provient de l'enregistrement SOA de la zone : c'est la plus petite des deux valeurs entre le TTL du SOA lui-même et son dernier champ (historiquement appelé « minimum »).
$ dig +noall +authority nosuch.example.com
example.com. 300 IN SOA ns1.dns.example. hostmaster.example.com. 2026092001 7200 3600 1209600 300
C'est l'explication habituelle du classique « j'ai créé l'enregistrement, le serveur faisant autorité le renvoie, mais mon résolveur persiste à dire qu'il n'existe pas » : quelqu'un (souvent vous, en vérifiant trop tôt) a interrogé le nom avant sa création, et la réponse négative est en cache. Avec un TTL négatif de 300, c'est un désagrément de cinq minutes ; avec 86400, une journée perdue. Restez raisonnable : une valeur comprise entre 300 et 3600 convient.
Quelles valeurs de TTL choisir
Il n'existe pas de bon chiffre unique. C'est un arbitrage entre agilité et résilience :
| TTL court (60–300) | TTL long (3600–86400) | |
|---|---|---|
| Prise d'effet des modifications | rapide | lente |
| Erreurs | corrigées rapidement | persistantes pendant des heures |
| Charge de requêtes sur les serveurs faisant autorité | plus élevée | plus faible |
| Latence de résolution pour les utilisateurs | davantage d'échecs de cache | presque toujours en cache |
| En cas de panne de votre fournisseur DNS | les noms cessent de se résoudre en quelques minutes | les réponses en cache font patienter les utilisateurs |
La dernière ligne est souvent oubliée. Un TTL long est une assurance gratuite contre une courte panne DNS.
Des points de départ raisonnables :
| Enregistrement | TTL habituel | Justification |
|---|---|---|
A/AAAA d'un site stable |
3600 | les changements sont rares et planifiés |
A/AAAA servant à une bascule ou placé derrière un répartiteur de charge |
60–300 | doit bouger vite ; souvent fixé par le fournisseur |
CNAME vers un SaaS ou un CDN |
3600 | c'est le TTL de la cible qui régit l'adresse finale |
MX |
3600–86400 | les serveurs de messagerie changent rarement ; les expéditeurs réessaient de toute façon |
TXT (SPF, DKIM, DMARC) |
3600 | à abaisser avant une modification prévue |
NS et SOA |
86400 | stables ; le TTL de la délégation dans la zone parente ne dépend pas de vous |
CAA |
3600–86400 | les autorités de certification respectent son TTL lors d'une nouvelle vérification |
Si votre fournisseur propose « Auto », cela correspond le plus souvent à 300 secondes, ce qui convient à la plupart des sites.
Préparer un changement grâce au TTL
Voici la marche à suivre pour déplacer un site web, un serveur de messagerie ou tout autre service placé derrière un nom DNS :
- Relevez le TTL actuel auprès du serveur faisant autorité. Appelons-le T.
- Abaissez-le à 300 (pas moins : certains résolveurs ignorent les valeurs très faibles) puis attendez au moins T. C'est seulement une fois T écoulé que vous pouvez être sûr que tous les caches détiennent la version à 300 secondes.
- Effectuez la modification.
- Vérifiez auprès du serveur faisant autorité et de quelques résolveurs publics.
- Laissez l'ancienne cible en service pendant au moins la durée du nouveau TTL, et de façon réaliste pendant quelques heures, à cause des caches qui ne suivent pas les règles.
- Remontez le TTL dès que vous êtes certain de ne pas revenir en arrière.
Abaisser le TTL et modifier l'enregistrement dans la même opération, voilà l'erreur classique : les résolveurs qui comptent détiennent l'ancien enregistrement avec l'ancien TTL, et ne verront même pas votre nouveau TTL avant son expiration.
Notez que, pour un changement de serveurs de noms, un second TTL entre en jeu : celui de la délégation dans la zone parente, couramment de deux jours, et que vous ne pouvez pas modifier. Ce cas particulier relève des serveurs de noms et se prépare séparément.
TTL et chaînes de CNAME
Lorsqu'un nom est un CNAME, le résolveur met chaque maillon en cache séparément, avec son propre TTL :
www.example.com. 3600 IN CNAME site.cdn.example.
site.cdn.example. 60 IN A 203.0.113.20
Le CDN peut déplacer son enregistrement A en une minute, mais si vous voulez faire pointer www vers un autre CDN, c'est votre 3600 qui s'applique. Le délai effectif d'une modification donnée est le TTL de l'enregistrement que vous modifiez, et non le plus petit de la chaîne.
Peut-on vider le cache ?
Le vôtre, oui.
# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
> ipconfig /flushdns
# Linux avec systemd-resolved
$ resolvectl flush-caches
Certains résolveurs publics proposent un formulaire web pour purger un nom de leur cache, ce qui rend service après une erreur. Les résolveurs de tous les autres, vous ne pouvez pas y toucher. Il n'existe pas de purge mondiale, et tout service qui prétend « forcer la propagation » vend un bouton qui ne fait rien.
Erreurs fréquentes
- Abaisser le TTL au moment même du changement, ou cinq minutes avant.
- Tout laisser à 60 secondes pour toujours « pour rester souple », puis tomber en même temps que son fournisseur DNS.
- Un TTL d'une journée sur un enregistrement qui fait partie d'un plan de bascule.
- Oublier la valeur du cache négatif et interroger un nom avant de le créer.
- Prendre une requête lancée depuis son propre ordinateur pour la preuve de ce que voient les utilisateurs.
- Croire que le pourcentage affiché par un « vérificateur de propagation » décrit l'ensemble d'Internet. Il décrit les emplacements que cet outil a interrogés.
Vérifiez avec OrbitProbe
La recherche DNS d'OrbitProbe affiche le TTL à côté de chaque enregistrement renvoyé, tel que les résolveurs publics le voient à cet instant. Avant une migration, servez-vous-en pour repérer les TTL à abaisser ; après le changement, relancez-la pour confirmer la nouvelle valeur et suivre le TTL restant. Pour savoir quels enregistrements existent au départ, lisez les types d'enregistrements DNS expliqués ; et si la modification vise à rétablir la délivrabilité de votre courrier, voyez la liste de contrôle DNS pour les e-mails qui arrivent en spam.