Le TTL DNS est le nombre de secondes pendant lesquelles un résolveur peut réutiliser une réponse en cache sans interroger à nouveau votre serveur DNS. Pour les enregistrements qui changent rarement, mettez 3600 secondes (une heure) ou plus ; avant une migration, baissez le TTL à 300 au moins un ancien TTL avant la bascule, donc une journée entière avant s’il était de 86400. Le baisser au moment où vous changez l’IP ne sert à rien : sur notre banc de test, un tel enregistrement a continué à renvoyer l’ancienne adresse pendant encore 59 minutes 53 secondes.
Comment nous avons testé
Le 10 novembre 2026, nous avons fait tourner dans un conteneur Ubuntu 24.04 isolé un serveur faisant autorité BIND 9.18.39 et trois résolveurs avec cache : Unbound 1.19.2 avec la configuration par défaut, un second Unbound avec des limites de TTL imposées (au moins 300 et au plus 900 secondes) et dnsmasq 2.91 dans le rôle d’un routeur domestique. Nous avons modifié les enregistrements avec nsupdate, interrogé les résolveurs toutes les 5 à 10 secondes et noté l’adresse et le TTL restant ; le scénario le plus long a duré 67 minutes. Les règles viennent des RFC 1035, 2181, 2308 et 8767, les limites des services publics de la documentation de Google, Cloudflare et NLnet Labs (vérifiée le 10/11/2026). Ce sont des résultats de banc de test, pas des mesures sur les serveurs de RichHost.
Ce que le TTL contrôle vraiment
Le TTL (time to live, durée de vie) s’applique à un ensemble d’enregistrements : tous les enregistrements A d’un même nom partagent un TTL, alors que le MX du même domaine peut en avoir un autre. La RFC 2181 le définit comme un nombre entier de secondes entre 0 et 2147483647. Trois points sont souvent mal compris.
- Le compte à rebours démarre quand un résolveur interroge, pas quand vous faites la modification. Un résolveur qui a récupéré l’enregistrement à 10:00 avec un TTL de 3600 le garde jusqu’à 11:00 ; un autre qui a demandé à 10:40 le garde jusqu’à 11:40. C’est pourquoi une modification « s’applique » à des moments différents selon les personnes.
- Les caches en chaîne ne s’additionnent pas. Votre navigateur, votre système d’exploitation, votre box et le résolveur de votre fournisseur d’accès peuvent tous se trouver entre vous et le serveur DNS. Sur le banc, le routeur (dnsmasq) a interrogé le résolveur 40 secondes après que celui-ci avait mis en cache un enregistrement avec un TTL de 120 et a reçu les 80 restantes, pas 120. Après la modification, les deux ont basculé dans la même seconde.
- Le champ minimum du SOA n’est pas le TTL par défaut. Il l’était dans la RFC 1035, mais depuis la RFC 2308 il fixe la durée du cache négatif. Le TTL par défaut d’un fichier de zone vient de la directive
$TTLou du champ TTL de votre panneau de contrôle.
La façon dont ces caches déterminent ensemble l’attente après toute modification DNS est mesurée à part dans notre article sur le délai de propagation DNS. Celui-ci porte sur la valeur à choisir et le moment où la changer.
Quel TTL pour chaque type d’enregistrement
| Enregistrement | TTL normal | Avant un changement | À prendre en compte |
|---|---|---|---|
| A, AAAA, CNAME du site | 3600 | 300 | Changement d’IP lors d’une migration ; le mode Auto de Cloudflare vaut 300 |
| MX | 3600-14400 | 300 | Tant que l’ancien TTL n’a pas expiré, une partie du courrier va vers l’ancien serveur, qui doit donc continuer à l’accepter |
| TXT pour SPF et DMARC | 3600 | 300 | Ajoutez un nouveau service d’envoi au SPF avant d’envoyer par lui |
| TXT pour DKIM | 3600 | inutile | Publiez la nouvelle clé à l’avance sous un nouveau sélecteur et ne l’interrogez pas avant qu’elle existe |
| NS et glue | 86400 | n’aide pas | C’est le TTL de la délégation dans la zone du registre qui compte (.com 172800), pas le vôtre |
| SOA (TTL et minimum) | 3600 et 300-3600 | 300 pour le minimum | La plus petite des deux valeurs fixe la durée de mise en cache de « cet enregistrement n’existe pas » |
Un TTL bas en permanence ne rend pas un site plus rapide : toutes les N secondes, chaque résolveur interroge de nouveau votre serveur DNS, et un visiteur dont le cache a expiré attend une résolution supplémentaire. Un TTL très élevé ralentit toute modification urgente. Un juste milieu raisonnable pour la plupart des sites : 3600 en temps normal et 300 pendant quelques jours autour d’une migration. L’ordre des opérations pour les enregistrements de messagerie est détaillé dans notre guide pour configurer SPF, DKIM et DMARC.
Les enregistrements NS sont un cas à part : les résolveurs prennent la durée de cache de la délégation dans la zone parente, si bien que le TTL de votre propre zone compte à peine. La bascule elle-même est décrite dans l’article pour changer les serveurs DNS d’un domaine.
Baisser, basculer, remonter : le test sur banc
Nous avons pris deux enregistrements avec un TTL de 3600 et la même adresse. Le résolveur les a mis en cache tous les deux à 15:12:10. À 15:12:20, l’enregistrement late a reçu en même temps une nouvelle IP et un TTL de 300, comme on le fait souvent à la dernière minute. Pour l’enregistrement plan, seul le TTL a été baissé à 300 ; son IP a été changée une heure plus tard, à 16:12:43. Dans la sortie, R1 est Unbound par défaut, R2 est Unbound avec les limites 300/900, et le nombre entre parenthèses indique les secondes écoulées depuis la modification.
15:12:10 R1 late.lab A NOERROR 192.0.2.10 3600 15:12:10 R1 plan.lab A NOERROR 192.0.2.10 3600 15:12:20 nsupdate: late.lab A 198.51.100.20 TTL 300; plan.lab A 192.0.2.10 TTL 300 15:27:04 R2 late.lab A NOERROR 192.0.2.10 6 15:27:15 R2 late.lab A NOERROR 198.51.100.20 300 (+895 s) 16:12:03 R1 late.lab A NOERROR 192.0.2.10 7 16:12:13 R1 late.lab A NOERROR 198.51.100.20 300 (+3593 s) 16:12:13 R1 plan.lab A NOERROR 192.0.2.10 300 16:12:43 nsupdate: plan.lab A 198.51.100.20 TTL 300 16:17:06 R1 plan.lab A NOERROR 192.0.2.10 7 16:17:16 R1 plan.lab A NOERROR 198.51.100.20 300 (+273 s)
L’enregistrement dont le TTL a été baissé en même temps que la modification a atteint le nouveau serveur au bout de 59 minutes 53 secondes : le résolveur a honnêtement attendu les 3600 anciennes secondes. L’enregistrement préparé a basculé 4 minutes 33 secondes après le changement d’IP. Le résolveur plafonné à 900 secondes a basculé late au bout de 14 minutes 55 secondes seulement. Dans la vraie vie, certains visiteurs voient donc le nouveau site plus tôt et d’autres plus tard, et l’ancien serveur doit rester en service jusqu’à l’expiration du TTL le plus long.
Le plan de travail :
- Vérifiez le TTL actuel :
dig +norec @ns1.your-dns.example example.com A. Ce nombre est votre délai minimal d’anticipation. - Baissez le TTL à 300 un ancien TTL plus une marge à l’avance : 2 heures avant pour 3600, un à deux jours avant pour 86400.
- Vérifiez les résolveurs publics :
dig @8.8.8.8 example.comdoit afficher un TTL de 300 ou moins. - Changez l’IP ou le MX. Gardez l’ancien serveur en marche au moins un jour de plus : certains résolveurs appliquent leurs propres règles.
- Au bout de 1 à 2 jours, remontez le TTL à 3600 ou plus.
Le déplacement des fichiers, de la base de données et de la messagerie étape par étape est expliqué dans notre article pour migrer WordPress vers un autre hébergeur.
Les résolveurs qui réécrivent votre TTL
La spécification autorise les résolveurs à limiter les TTL, et ils ne s’en privent pas. Par défaut, Unbound ne garde rien plus d’un jour (cache-max-ttl 86400) ni aucune réponse négative plus d’une heure ; un opérateur peut aussi fixer un plancher avec cache-min-ttl, même si la documentation d’Unbound prévient que des valeurs au-delà d’une heure environ donnent des données en cache qui ne correspondent plus aux données réelles. Voici ce que les deux résolveurs ont renvoyé pour les mêmes enregistrements :
| TTL dans la zone | Unbound par défaut | Unbound avec limites 300/900 |
|---|---|---|
| 0 | 0, nouvelle adresse dès la première requête après la modification | 300, ancienne adresse encore 4 min 58 s |
| 30 | 30, bascule au bout de 27 s | 300, ancienne adresse encore 4 min 58 s |
| 3600 | 3600 | 900 |
| 172800 | 86400 | 900 |
| négatif 120 | 120 | 300 |
| négatif 86400 | 3600 | 900 |
Les services publics ont aussi leurs limites. La FAQ de Google Public DNS (mise à jour le 06/11/2026) indique que les TTL sont en général limités à six heures, même si le TTL réel est plus long. Cloudflare en tant qu’hébergeur DNS n’accepte pas moins de 60 secondes (30 en Enterprise) ni plus d’un jour, et les enregistrements proxifiés reçoivent toujours 300. À retenir : un TTL inférieur à 60 ou 300 secondes ne garantit pas une bascule plus rapide, et un TTL supérieur à 6 heures sera de toute façon raccourci dans une partie du monde.
Cache négatif : un enregistrement qui n’existait pas encore
Si quelqu’un a interrogé un nom avant que vous ne le créiez, le résolveur mémorise la réponse « ce nom n’existe pas » (NXDOMAIN) ou « le nom existe mais n’a pas d’enregistrement de ce type » (NODATA). Selon la RFC 2308, cette durée est la plus petite de deux valeurs : le TTL de l’enregistrement SOA lui-même et son champ minimum. BIND place déjà la valeur calculée dans la réponse négative :
dig @127.0.21.10 new.neg1.lab +norec (SOA TTL 3600, minimum 300) status: NXDOMAIN neg1.lab. 300 IN SOA ... 1 7200 3600 1209600 300 dig @127.0.21.10 new.neg2.lab +norec (SOA TTL 120, minimum 3600) status: NXDOMAIN neg2.lab. 120 IN SOA ... 1 7200 3600 1209600 3600 15:12:21 R1 new.neg2.lab A NXDOMAIN SOA-ttl 120 15:12:26 nsupdate: add new.neg1.lab A, new.neg2.lab A, www.neg1.lab AAAA 15:14:26 R1 new.neg2.lab A NOERROR 198.51.100.20 300 15:17:24 R1 new.neg1.lab A NOERROR 198.51.100.20 300 15:17:24 R1 www.neg1.lab AAAA NOERROR 2001:db8::20 3600
Un nouvel enregistrement dans la zone au TTL négatif de 120 est apparu au bout de 2 minutes ; dans la zone à 300, au bout de 4 minutes 58 secondes. NODATA se comporte de la même façon : quand nous avons ajouté un enregistrement AAAA à un nom existant, l’adresse IPv6 n’est apparue qu’à l’expiration du cache négatif. La RFC 2308 suggère une à trois heures comme valeur par défaut raisonnable, mais si vous créez souvent des sous-domaines ou publiez des enregistrements TXT pour valider des services, un minimum de 300 est plus pratique. Pour distinguer un tel cache d’un enregistrement vraiment absent, voyez notre article sur l’erreur DNS_PROBE_FINISHED_NXDOMAIN. Encore un piège : le résolveur avec plancher a relevé le TTL négatif de 120 secondes à 300.
Les caches du navigateur et du système
Il existe deux couches de plus entre vous et le résolveur. Chromium garde les adresses fournies par le résolveur du système pendant 60 secondes et, avec son résolveur intégré, suit le TTL avec un minimum d’une minute (comme l’explique Eric Lawrence, 2022). Videz ce cache avec le bouton Clear host cache sur chrome://net-internals/#dns ; Firefox a un bouton sur about:networking#dns. Le cache du système suit lui aussi les TTL : sous Windows, ipconfig /displaydns affiche le TTL restant de chaque entrée, et sous Linux avec systemd-resolved, resolvectl flush-caches le vide. Ces caches sont courts et causent rarement des retards d’une heure ; le vrai retard vient de votre fournisseur d’accès ou d’un résolveur public, que vous ne pouvez pas vider depuis votre ordinateur.
Si X, faites Y
| Situation | Que faire |
|---|---|
| Migration dans une semaine, TTL actuel 86400 | Baissez A et MX à 300 aujourd’hui, basculez au plus tôt un jour après |
| Migration demain, TTL 86400 | Baissez maintenant et repoussez la bascule d’un jour ; si c’est impossible, gardez l’ancien serveur en service un jour de plus |
| Changement de serveur de messagerie | MX à 300 à l’avance ; l’ancien serveur continue d’accepter le courrier pendant l’ancien TTL, puis vérifiez qu’il n’y reste rien |
| Ajout d’un nouveau service d’envoi d’e-mails | Mettez d’abord à jour le SPF, envoyez par le nouveau service au plus tôt un TTL TXT plus tard |
| Rotation d’une clé DKIM | Publiez le nouveau sélecteur un jour avant la bascule, supprimez l’ancien une semaine après |
| Création fréquente de sous-domaines | Minimum SOA à 300, et ne testez pas un nom avant que l’enregistrement existe |
| Changement de serveurs DNS | Les TTL des enregistrements n’aident pas ; attendez le TTL de délégation dans la zone du registre |
| Les enregistrements ne changent jamais | 3600 à 86400 pour A et MX, 86400 pour NS |
| Envie d’un TTL de 0 ou 10 « pour la vitesse » | Mettez au moins 60 : un résolveur avec plancher relèvera la valeur de toute façon |
Si vous migrez un site vers un hébergement avec un panneau de contrôle, comme les offres RichHost, baissez le TTL chez votre ancien fournisseur DNS avant de commencer à copier les fichiers : quand le transfert sera terminé, l’ancienne valeur aura expiré.
FAQ
J’ai baissé le TTL à 300, pourquoi le changement a-t-il quand même pris une heure ?
Les résolveurs avaient mis l’enregistrement en cache avec l’ancien TTL de 3600 et le gardent jusqu’à son expiration. Ils ne voient la nouvelle valeur qu’à leur requête suivante. Baissez le TTL un ancien TTL avant le changement.
Puis-je mettre un TTL de 0 ?
Oui, et Unbound par défaut ne réutilise alors pas la réponse depuis le cache. Mais sur notre banc, un résolveur avec plancher a continué à servir un tel enregistrement pendant 300 secondes après la modification, et certains hébergeurs DNS n’acceptent pas moins de 60.
Comment savoir combien de temps l’ancienne réponse va encore vivre ?
Interrogez le résolveur concerné, par exemple dig @8.8.8.8 example.com : le nombre de la deuxième colonne est le TTL restant dans son cache. Le vrai TTL de l’enregistrement s’affiche quand vous interrogez votre propre serveur DNS avec +norec.
Le TTL influe-t-il sur la vitesse du site ?
À peine. Un visiteur fait au plus une résolution DNS supplémentaire par TTL, et le navigateur la met en cache. Pour un site classique, la différence entre 300 et 3600 se remarque à peine, donc 3600 est une valeur tout à fait normale en période calme.
Faut-il remonter le TTL après la migration ?
Oui, au bout de 1 à 2 jours, une fois sûr de ne pas devoir revenir en arrière. Laisser 300 pour toujours ne fait pas de mal, mais ajoute des requêtes à votre serveur DNS sans rien apporter.
