TTL DNS : définition, valeurs à choisir et délai de mise à jour

Le TTL DNS (Time To Live, « durée de vie ») est un nombre de secondes attaché à chaque enregistrement DNS. Il indique aux résolveurs combien de temps ils peuvent garder la réponse en cache avant de la redemander au serveur faisant autorité. Un TTL court (300 secondes) permet de changer vite d’adresse IP ou de serveur mail, un TTL long (plusieurs heures) accélère la navigation et réduit la dépendance à vos serveurs DNS. Pour la plupart des sites, 3600 secondes (1 heure) est un bon réglage par défaut, à abaisser un ou deux jours avant une migration.

Le TTL est le réglage DNS le plus souvent ignoré, jusqu’au jour où un changement d’hébergeur « ne se propage pas » ou où des e-mails partent encore vers l’ancien serveur. On explique ici ce que fait réellement cette valeur, les valeurs à choisir enregistrement par enregistrement, le calcul du vrai délai de mise à jour, la procédure pour préparer une migration sans coupure et les commandes pour vérifier un TTL sur Mac, Linux ou Windows.

• Qu’est-ce que le TTL d’un enregistrement DNS ?
• Comment le TTL fonctionne-t-il concrètement ?
• Pourquoi les réponses DNS sont-elles mises en cache ?
• Quelle valeur de TTL choisir ?
• TTL court ou TTL long : que gagne-t-on, que perd-on ?
• Combien de temps faut-il pour qu’une modification DNS soit visible ?
• Comment préparer une migration en jouant sur le TTL ?
• Comment vérifier le TTL d’un enregistrement ?
• Peut-on vider un cache DNS ou forcer la mise à jour ?
• Où régler le TTL chez OVHcloud ou Cloudflare ?
• Quelles erreurs éviter avec le TTL ?
• Questions fréquentes
• Sources

Qu’est-ce que le TTL d’un enregistrement DNS ?

Le DNS (Domain Name System) sert d’annuaire à Internet : il traduit un nom lisible comme osmova.com en adresse IP que les machines savent joindre. Si le fonctionnement général du DNS ne vous est pas familier, notre article sur le serveur DNS pose les bases, et celui sur le nom de domaine explique la partie administrative.

Chaque enregistrement d’une zone DNS (A, AAAA, CNAME, MX, TXT, NS…) porte un champ TTL. Ce champ est défini depuis l’origine du DNS par la RFC 1035 : c’est un entier sur 32 bits, exprimé en secondes. La RFC 2181 a précisé sa plage de valeurs, de 0 à 2 147 483 647 secondes (2³¹ moins 1), et surtout son sens : le TTL est une durée maximale de conservation, pas une durée obligatoire. Un résolveur a le droit de jeter la réponse plus tôt, il n’a pas le droit de la garder plus longtemps.

Concrètement, si l’enregistrement A de votre site a un TTL de 3600, un résolveur qui vient de le récupérer pourra répondre à tous ses utilisateurs avec cette adresse IP pendant une heure, sans interroger à nouveau vos serveurs DNS. Au bout d’une heure, la réponse expire et la prochaine requête déclenche une nouvelle recherche.

Comment le TTL fonctionne-t-il concrètement ?

Quand un visiteur tape l’adresse de votre site, la question « quelle est l’IP de ce nom ? » traverse plusieurs couches, et chacune peut avoir sa propre copie en cache :

1. Le navigateur garde quelques réponses récentes en mémoire.
2. Le système d’exploitation (Windows, macOS, Android…) a son propre cache DNS.
3. Le résolveur récursif, celui de votre fournisseur d’accès, de votre entreprise ou un résolveur public comme 8.8.8.8 (Google) ou 1.1.1.1 (Cloudflare), stocke les réponses pour des milliers d’utilisateurs.
4. Le serveur faisant autorité, chez votre hébergeur DNS, détient la version officielle de la zone. Lui ne met rien en cache : c’est la source.

À chaque étape, la logique est la même : si une réponse est en cache et que son TTL n’est pas écoulé, elle est servie immédiatement. Sinon, la question remonte d’un cran. Le point important, souvent mal compris, est que le TTL décompte. Si un résolveur a mis en cache une réponse de TTL 3600 il y a 40 minutes, il la transmet à un nouvel utilisateur avec un TTL restant d’environ 1200 secondes. Les caches situés en aval ne peuvent donc jamais prolonger la durée de vie fixée à la source.

Prenons un exemple chiffré. Votre enregistrement A a un TTL de 1800 secondes (30 minutes). Pendant ces 30 minutes, les 100 ou 10 000 personnes qui passent par le même résolveur reçoivent la même adresse IP sans que vos serveurs DNS ne soient sollicités. Si vous changez l’adresse IP à la minute 10, ces utilisateurs continueront d’aller sur l’ancienne adresse pendant les 20 minutes restantes, puis basculeront sur la nouvelle.

Pourquoi les réponses DNS sont-elles mises en cache ?

Sans cache, chaque chargement de page déclencherait une chaîne de requêtes vers les serveurs racine, puis vers ceux de l’extension (.fr, .com), puis vers vos serveurs faisant autorité. Le cache apporte trois bénéfices :

• La vitesse : une réponse déjà en cache chez le résolveur arrive bien plus vite qu’une résolution complète. C’est un petit gain par requête, mais une page moderne appelle souvent plusieurs domaines (le site, un CDN, des polices, des outils de mesure), et les gains s’additionnent. Le DNS n’est qu’une des briques de la vitesse d’un site : notre article sur le cache d’un site internet détaille les autres niveaux de cache.
• La charge : vos serveurs DNS ne reçoivent qu’une fraction des requêtes réelles, ce qui compte si votre hébergeur DNS facture au volume.
• La résilience : si vos serveurs DNS tombent, les résolveurs qui ont encore la réponse en cache continuent de servir votre site jusqu’à expiration du TTL. Plusieurs résolveurs (BIND, Unbound et d’autres) savent même servir une réponse expirée quand la source ne répond plus : c’est le mécanisme « serve-stale », normalisé par la RFC 8767 en mars 2020, qui recommande de renvoyer ces réponses périmées avec un TTL de 30 secondes et de ne pas les garder plus de 1 à 3 jours.

La contrepartie est simple : tant qu’une réponse est en cache, une modification faite sur la zone n’est pas vue par les utilisateurs de ce cache. Tout l’art du TTL consiste à arbitrer entre ces deux besoins.

Quelle valeur de TTL choisir ?

Il n’existe pas de valeur officielle idéale, mais quelques repères font consensus. Les TTL s’expriment toujours en secondes :

Valeur	Durée	Qualification	Usage typique
60 à 300	1 à 5 minutes	Très court	Migration en cours, bascule de secours (failover), équilibrage de charge par DNS
3600	1 heure	Court à moyen	Valeur par défaut raisonnable pour la plupart des enregistrements d’un site vitrine ou e-commerce
14 400 à 43 200	4 à 12 heures	Long	Enregistrements stables : TXT de vérification, SPF, DKIM, MX d’une messagerie installée depuis longtemps
86 400	24 heures	Très long	Enregistrements quasi figés, NS
604 800	7 jours	Extrême	Rarement utile : beaucoup de résolveurs plafonnent de toute façon la durée de cache

Sur ce dernier point, les plafonds existent bien : le résolveur Unbound, très répandu, limite par défaut la durée de cache à 86 400 secondes (1 jour) avec son paramètre cache-max-ttl. Mettre 7 jours ne garantit donc pas 7 jours de cache partout.

Recommandations par type d’enregistrement

Enregistrement	Rôle	TTL conseillé en régime normal	Remarque
A / AAAA	Adresse IPv4 / IPv6 du serveur	3600	Descendre à 300 avant tout changement d’hébergement
CNAME	Alias vers un autre nom (souvent www ou un service tiers)	3600	Si la cible est un CDN ou un SaaS, c’est le TTL de la cible qui compte aussi
MX	Serveurs de messagerie	3600 à 14 400	Descendre avant un changement de messagerie (passage vers Microsoft 365, Google Workspace…)
TXT	SPF, DKIM, DMARC, vérifications de propriété	3600 à 43 200	Un TTL court aide pendant la mise au point d’un SPF ou d’un DMARC
NS	Serveurs faisant autorité de la zone	86 400 et plus	Le TTL qui compte vraiment est celui fixé par le registre de l’extension (voir plus bas)
SOA (champ minimum)	Durée de cache des réponses négatives (« ce nom n’existe pas »)	3600 à 10 800	La RFC 2308 juge 1 à 3 heures raisonnable et plus d’un jour problématique

Le cache négatif mérite une explication, car il piège souvent. Si quelqu’un interroge nouveau.votresite.fr avant que vous ayez créé l’enregistrement, le résolveur mémorise « ce nom n’existe pas ». Selon la RFC 2308, la durée de ce souvenir est le plus petit entre le TTL de l’enregistrement SOA et son champ « minimum ». Si cette valeur vaut une journée, votre nouveau sous-domaine restera introuvable pour ces utilisateurs pendant une journée, quel que soit le TTL que vous donnez au nouvel enregistrement.

TTL court ou TTL long : que gagne-t-on, que perd-on ?

	TTL court (60 à 300 s)	TTL long (plusieurs heures)
Changement d’IP ou de serveur	Visible en quelques minutes	Peut prendre des heures pour une partie des visiteurs
Bascule de secours automatique	Possible	Inefficace
Vitesse perçue	Plus de résolutions complètes, donc un peu plus de latence en moyenne	Réponses servies depuis le cache la plupart du temps
Charge sur les serveurs DNS	Plus élevée	Plus faible
Panne de l’hébergeur DNS	Le site devient injoignable rapidement (sauf serve-stale)	Le site reste joignable pour les visiteurs dont le résolveur a la réponse en cache

En pratique, on raisonne par profil :

• Site vitrine ou boutique hébergés sur un serveur stable : 3600 partout, sans chercher plus loin. On baisse ponctuellement avant une intervention.
• Infrastructure avec bascule automatique ou répartition de charge par DNS : TTL de 60 à 300 sur les enregistrements concernés, sinon la bascule ne sert à rien.
• Site derrière un CDN ou un proxy (Cloudflare, par exemple) : c’est le fournisseur qui gère les adresses et le TTL de ses enregistrements proxifiés, vous n’avez pas à y toucher.
• Enregistrements de messagerie et de vérification : plutôt longs une fois la configuration validée, puisqu’ils changent rarement.

Combien de temps faut-il pour qu’une modification DNS soit visible ?

On parle couramment de « propagation DNS », comme si la modification voyageait de serveur en serveur. Ce n’est pas ce qui se passe : votre modification est immédiatement active sur les serveurs faisant autorité, et chaque cache dans le monde la verra quand sa copie expirera. On lit parfois qu’il faudrait multiplier le TTL par le nombre d’étapes de la chaîne : c’est faux, puisque le TTL décompte et que les caches en aval héritent du temps restant.

Le délai maximum se calcule donc ainsi :

• Pour un enregistrement modifié (A, MX, CNAME…) : l’ancien TTL de cet enregistrement, celui qui était en place au moment où les résolveurs ont mis la réponse en cache. Si l’enregistrement avait un TTL de 86 400 et que vous le baissez à 300 en même temps que vous changez l’IP, certains visiteurs attendront quand même jusqu’à 24 heures.
• Pour un enregistrement nouvellement créé : le TTL de cache négatif (SOA) si quelqu’un l’a cherché avant sa création, zéro sinon.
• Pour un changement de serveurs DNS (NS) chez le registraire : le TTL de délégation fixé par le registre de l’extension. Nous l’avons vérifié avec la commande dig en septembre 2026 : les délégations en .com sont publiées avec un TTL de 172 800 secondes (48 heures), celles en .fr avec 3600 secondes (1 heure). C’est pourquoi un changement d’hébergeur DNS sur un .com demande plus de patience que sur un .fr.

Viennent s’ajouter quelques facteurs moins maîtrisables : des résolveurs d’entreprise ou de fournisseurs d’accès qui imposent un TTL minimum, un navigateur resté ouvert qui garde son propre cache, ou des applications (Java, certains objets connectés) qui mettent en cache sans respecter le TTL. D’où le « jusqu’à 24 heures » affiché par beaucoup d’hébergeurs : OVHcloud indique par exemple que la propagation d’une modification de zone peut prendre jusqu’à 24 heures. C’est une marge de sécurité, pas un délai incompressible.

Comment préparer une migration en jouant sur le TTL ?

C’est l’usage le plus utile du TTL pour une entreprise. Changer d’hébergeur, de serveur ou de messagerie sans que des visiteurs arrivent sur un site éteint ou que des e-mails se perdent tient en quelques étapes :

1. Relever les TTL actuels des enregistrements concernés (A, AAAA, CNAME de www, MX si la messagerie bouge). Notez la valeur la plus longue : c’est votre délai d’attente.
2. Baisser ces TTL à 300 secondes au moins une fois ce délai à l’avance. Si le TTL actuel est de 86 400, faites-le au moins 24 heures avant l’intervention ; en pratique on prend souvent 48 heures de marge.
3. Préparer la nouvelle infrastructure et la tester sans toucher au DNS, par exemple en modifiant le fichier hosts de votre poste pour pointer le domaine vers la nouvelle IP.
4. Changer les enregistrements le jour J. Les résolveurs ayant tous un TTL de 5 minutes maximum en cache, la bascule se fait pour l’essentiel des visiteurs en quelques minutes.
5. Laisser l’ancien serveur actif quelques jours : quelques caches récalcitrants peuvent encore y envoyer du trafic, et pour la messagerie, des e-mails peuvent y arriver. Sur un site dynamique, pensez à geler les contenus ou les commandes pendant la fenêtre de bascule pour ne rien perdre côté base de données.
6. Remonter les TTL à 3600 (ou à votre valeur habituelle) une fois que tout est vérifié, en général au bout de 24 à 48 heures.

Deux pièges fréquents : oublier le sous-domaine www (souvent un CNAME ou un A séparé avec son propre TTL) et oublier que le TTL baissé à J moins 1 ne s’applique qu’aux caches qui se renouvellent après ce changement. C’est exactement le type d’intervention qu’on prend en charge dans nos contrats d’hébergement et maintenance (le budget dépend du niveau de service, voir nos tarifs indicatifs), justement pour éviter qu’une migration se transforme en journée de panne.

Comment vérifier le TTL d’un enregistrement ?

Sur Mac ou Linux, avec dig

La commande dig est installée par défaut sur macOS et sur la plupart des distributions Linux. Dans un terminal :

dig votresite.fr A +noall +answer

votresite.fr.    2754    IN    A    203.0.113.10

Le nombre après le nom (ici 2754, donné à titre d’exemple) est le TTL restant dans le cache du résolveur que vous utilisez. Relancez la commande : il diminue. Pour lire le TTL configuré, il faut interroger directement un serveur faisant autorité :

dig votresite.fr NS +short
dig votresite.fr A @ns1.exemple-hebergeur.net +noall +answer

La première commande liste les serveurs DNS de la zone, la seconde interroge l’un d’eux : la valeur affichée est alors fixe, c’est celle que vous avez saisie dans votre zone. Remplacez A par MX, TXT ou CNAME selon l’enregistrement à contrôler, et ajoutez www. devant le domaine pour le sous-domaine.

Sur Windows, avec nslookup ou PowerShell

Ouvrez l’invite de commandes (touche Windows, tapez cmd) et utilisez le mode debug de nslookup, qui affiche le TTL de chaque réponse :

nslookup -debug -type=A votresite.fr
nslookup -debug -type=A votresite.fr ns1.exemple-hebergeur.net

Dans le bloc « ANSWERS », la ligne « ttl = » donne la valeur en secondes. La deuxième ligne interroge directement le serveur faisant autorité. Dans PowerShell, la commande Resolve-DnsName votresite.fr -Type A affiche également une colonne TTL, plus lisible.

En ligne, sans rien installer

L’outil Dig de la Google Admin Toolbox interroge n’importe quel type d’enregistrement depuis un navigateur et affiche le TTL. Les sites de « vérification de propagation » qui interrogent des résolveurs dans plusieurs pays sont aussi utiles pendant une migration, à condition de garder en tête qu’ils montrent l’état de quelques caches à un instant donné, pas celui de tous vos visiteurs.

Peut-on vider un cache DNS ou forcer la mise à jour ?

Vous ne pouvez pas forcer à distance le résolveur d’un fournisseur d’accès à oublier votre ancien enregistrement : c’est pour cela qu’on anticipe en baissant le TTL. En revanche, vous pouvez vider les caches que vous contrôlez, ce qui est utile pour vérifier vous-même le résultat :

• Windows : ipconfig /flushdns dans l’invite de commandes.
• macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder dans le Terminal.
• Chrome et navigateurs basés sur Chromium : la page chrome://net-internals/#dns propose un bouton pour vider le cache de l’hôte.
• Résolveurs publics : Google Public DNS et Cloudflare 1.1.1.1 proposent chacun une page publique pour purger leur cache sur un nom de domaine donné (liens dans les sources). Google précise que si le registraire ou l’hébergeur DNS a changé récemment, il faut purger le domaine principal avant les sous-domaines.

Où régler le TTL chez OVHcloud ou Cloudflare ?

Chez OVHcloud, le TTL se règle soit enregistrement par enregistrement (au moment de l’ajout ou de la modification d’une entrée), soit pour toute la zone via le menu « Actions sur ma zone » puis « Modifier le TTL par défaut ». La documentation OVHcloud indique une valeur par défaut de 3600 secondes.

Chez Cloudflare, la documentation distingue deux cas. Les enregistrements proxifiés (nuage orange) ont un TTL « Auto », fixé à 300 secondes, que vous ne pouvez pas modifier. Les enregistrements en « DNS only » acceptent un TTL entre 60 secondes (30 secondes pour les comptes Enterprise) et 1 jour.

La plupart des autres registraires et hébergeurs proposent un champ TTL dans leur éditeur de zone, parfois avec une liste de valeurs prédéfinies. Si l’interface affiche « 0 » ou « Par défaut », c’est généralement le TTL par défaut de la zone qui s’applique : vérifiez-le avec dig plutôt que de le supposer.

Quelles erreurs éviter avec le TTL ?

• Baisser le TTL le jour même de la migration. Les résolveurs qui ont mis la réponse en cache avec l’ancien TTL long ne verront la baisse qu’à expiration de ce TTL. La baisse doit précéder le changement d’au moins la durée de l’ancien TTL.
• Laisser un TTL de 60 secondes en permanence « au cas où ». Vous multipliez les requêtes vers vos serveurs DNS, ajoutez de la latence à une partie des visites et perdez l’effet tampon du cache en cas de panne de votre hébergeur DNS, sans bénéfice si vous ne changez jamais d’IP.
• Mettre un TTL de plusieurs jours pour « gagner en vitesse ». Le gain est marginal au-delà de quelques heures, une partie des résolveurs plafonne la durée de cache, et vous vous privez de toute réactivité le jour où il faut changer quelque chose.
• Oublier le cache négatif. Tester un sous-domaine avant de l’avoir créé peut vous bloquer pendant la durée du champ minimum du SOA.
• Confondre TTL DNS et cache du site. Si vous voyez encore l’ancienne version d’une page alors que le DNS pointe bien vers le nouveau serveur, le coupable est probablement un cache applicatif, un CDN ou le cache du navigateur, pas le TTL.
• Donner des TTL différents à des enregistrements d’un même ensemble. La RFC 2181 l’interdit et les résolveurs retiennent la plus petite valeur, ce qui rend le comportement difficile à prévoir.

Le choix du TTL rejoint d’ailleurs une autre décision de configuration DNS souvent sous-estimée : l’adresse principale de votre site. Si vous hésitez, notre article sur les URL avec ou sans www fait le point.

Questions fréquentes

Que signifie TTL en DNS ?

TTL signifie Time To Live, « durée de vie ». C’est le nombre de secondes pendant lesquelles un résolveur DNS peut conserver un enregistrement en cache avant de devoir le redemander au serveur faisant autorité.

Quel est le TTL le plus courant ?

3600 secondes (1 heure) est la valeur par défaut de nombreux hébergeurs, dont OVHcloud, et un bon réglage pour la plupart des sites. 300 secondes (5 minutes) est la valeur courante pour un TTL court, notamment pendant une migration ou derrière un CDN.

Un TTL court ralentit-il mon site ?

Légèrement, pour une partie des visites : plus le TTL est court, plus souvent un résolveur doit refaire une résolution complète. L’effet reste faible face au poids des images, des scripts ou du temps de réponse du serveur, mais il n’y a aucune raison de garder un TTL très court si vos adresses ne changent pas.

Peut-on mettre un TTL à 0 ?

Techniquement oui, la RFC 2181 autorise la valeur 0, qui signifie « ne pas mettre en cache ». En pratique, beaucoup d’interfaces l’interprètent comme « TTL par défaut de la zone », et certains résolveurs appliquent un minimum. C’est à réserver à des cas très particuliers.

Pourquoi mon changement DNS n’est-il pas visible au bout de 24 heures ?

Vérifiez d’abord avec dig, directement sur le serveur faisant autorité, que la modification est bien enregistrée dans la bonne zone (erreur fréquente : modifier une zone chez un hébergeur alors que les serveurs NS du domaine pointent ailleurs). Si c’est le cas, videz vos caches locaux et testez depuis un autre réseau, par exemple en 4G.

Sources

• RFC 1035 : Domain Names, Implementation and Specification (IETF)
• RFC 2181 : Clarifications to the DNS Specification, sections 5.2 et 8 (IETF)
• RFC 2308 : Negative Caching of DNS Queries (IETF)
• RFC 8767 : Serving Stale Data to Improve DNS Resiliency (IETF, mars 2020)
• Documentation Unbound : unbound.conf, paramètre cache-max-ttl (NLnet Labs)
• OVHcloud : modifier une zone DNS OVHcloud
• Cloudflare : Time to Live (TTL)
• Google Public DNS : Flush Cache
• Cloudflare 1.1.1.1 : Purge Cache
• Google Admin Toolbox : Dig