Aller au contenu
DomainVigil
S'inscrire

Guide de référence

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

Le TTL est la durée pendant laquelle le reste d'Internet a le droit de garder votre réponse en mémoire. C'est ce qui rend un changement DNS instantané pour les uns et invisible pendant une journée pour les autres.

7 min de lectureMis à jour le 12 septembre 2026

En bref

Le TTL, ou durée de vie, est un nombre de secondes attaché à chaque enregistrement DNS. Il indique combien de temps un résolveur peut réutiliser la réponse sans la redemander. Un TTL court rend les changements rapides et multiplie les requêtes ; un TTL long fait l'inverse. Baisser un TTL ne prend effet qu'au bout de l'ancienne durée.

À quoi sert le TTL

Le DNS ne serait pas tenable sans cache. Si chaque visite d'un site déclenchait une requête complète jusqu'aux serveurs faisant autorité, ces serveurs crouleraient et chaque page mettrait une demi-seconde de plus à s'ouvrir. Le TTL est le contrat qui organise ce cache : c'est vous, propriétaire de la zone, qui dites au reste du monde combien de temps il peut se fier à une réponse sans la redemander.

Ce contrat a une conséquence qu'on sous-estime toujours : quand vous modifiez un enregistrement, personne n'est prévenu. Les résolveurs qui détiennent l'ancienne valeur la gardent jusqu'au bout de son TTL, puis la redemandent. Pendant cet intervalle, une partie d'Internet voit l'ancienne réponse et l'autre la nouvelle, et les deux ont raison.

D'où la seule règle qui compte : le TTL se règle avant le changement, pas pendant. Et comme l'ancienne valeur gouverne encore les caches au moment où vous la modifiez, l'abaissement lui-même met un TTL complet à produire son effet.

Les valeurs de TTL et ce qu'elles font vraiment

Un TTL ne se choisit pas en fonction d'une bonne pratique abstraite mais du délai de correction qu'on accepte. Voici ce que chaque valeur courante donne et ce qu'elle coûte.

ValeurDuréeCe que ça permetCe que ça coûte
601 minuteUne bascule quasi immédiate, utile pendant les quelques heures d'une migration.Un grand nombre de requêtes et aucune tolérance : si vos serveurs DNS tombent, le domaine disparaît en une minute.
3005 minutesLa valeur de travail d'une migration : assez court pour corriger vite, assez long pour absorber un incident bref.Des requêtes fréquentes. Acceptable sur quelques jours, pas comme régime permanent.
36001 heureLe compromis courant en régime normal, pour les adresses et les serveurs de courrier.Une erreur reste visible jusqu'à une heure après sa correction.
144004 heuresPeu de requêtes, une zone qui bouge rarement.Une demi-journée de travail perdue si une valeur est fausse et qu'on s'en aperçoit tard.
8640024 heuresLa valeur par défaut de beaucoup d'interfaces. Convient à ce qui ne change jamais.Une erreur reste en circulation une journée entière, y compris pendant une mise en production.
6048007 joursRéservé aux enregistrements figés, comme une vérification de propriété.Toute correction devient un chantier d'une semaine.

Une valeur à zéro demande de ne rien mettre en cache. Elle existe, elle fonctionne, et elle transforme chaque visite en requête complète : à réserver à des bascules très courtes et surveillées.

Vérifiez sur votre domaine, tout de suite

Entrez un nom de domaine : l'outil affiche ses serveurs de noms et la durée de vie annoncée pour chaque réponse.

Sans inscription, sans e-mail à laisser. Vous pouvez coller une adresse complète : nous en extrayons le domaine.

Le calendrier d'une migration sans coupure

Cinq moments, et un seul piège : l'abaissement du TTL doit être fait assez tôt pour que l'ancienne valeur ait fini d'expirer partout.

  1. 1

    Abaisser le TTL, au moins un ancien TTL avant

    Si l'enregistrement est à 24 heures, l'abaissement doit avoir lieu plus de 24 heures avant la bascule. Sinon, les caches qui détiennent encore l'ancienne valeur ignoreront la nouvelle durée.

    86400 → 300

  2. 2

    Attendre que l'ancienne durée soit écoulée

    Pendant cette attente, rien ne change côté visiteur. C'est le temps qu'il faut pour que tous les résolveurs aient redemandé l'enregistrement et connaissent désormais le TTL court.

  3. 3

    Changer l'enregistrement

    La bascule se propage maintenant à la vitesse du TTL court. En cas de problème, le retour arrière prend le même temps : c'est tout l'intérêt de la manœuvre.

  4. 4

    Vérifier depuis plusieurs réseaux

    Un résultat vu depuis un seul poste ne prouve rien : il peut venir d'un cache local. Il faut voir la nouvelle valeur depuis au moins deux résolveurs différents.

  5. 5

    Remonter le TTL

    Une fois la bascule confirmée, revenir à une valeur de régime. Laisser un TTL d'une minute en permanence rend le domaine fragile pour un bénéfice nul.

    300 → 3600

Le cache négatif, celui qu'on oublie

Une réponse « ce nom n'existe pas » est mise en cache elle aussi. C'est ce qui explique le scénario le plus frustrant du métier : vous créez un sous-domaine, vous le testez immédiatement, il n'existe pas — et il continue de ne pas exister pendant des heures alors que l'enregistrement est bien là.

Cette durée-là n'est pas gouvernée par le TTL de l'enregistrement que vous venez de créer, puisqu'il n'existait pas au moment de la question. Elle vient de l'enregistrement de début d'autorité de la zone, celui qui porte les paramètres généraux. Vous ne le voyez pas toujours dans les interfaces simplifiées, mais c'est lui qui décide.

La conséquence pratique tient en une phrase : ne testez pas un nom avant de l'avoir créé. Une seule requête faite trop tôt suffit à installer l'absence dans le cache de votre propre résolveur, pour la durée entière du cache négatif.

Les erreurs de TTL les plus coûteuses

  • Le TTL a été baissé le matin même de la migration

    Ce qui le provoque : L'abaissement est lui-même soumis à l'ancienne durée : les résolveurs qui détiennent la valeur à 24 heures ne reviendront pas la chercher avant la fin de cette journée.

    Le geste qui corrige : Programmer l'abaissement au moins une ancienne durée complète avant la bascule. C'est la seule étape qu'on ne peut pas rattraper le jour même.

  • Le sous-domaine créé reste introuvable

    Ce qui le provoque : Il a été interrogé avant d'exister, et la réponse négative est installée dans les caches pour la durée fixée par la zone.

    Le geste qui corrige : Attendre l'expiration du cache négatif, ou tester depuis un résolveur qui n'a pas encore posé la question. Créer d'abord, tester ensuite.

  • Tous les enregistrements sont à une minute en permanence

    Ce qui le provoque : Une migration passée a laissé les valeurs basses, et personne ne les a remontées.

    Le geste qui corrige : Revenir à une valeur de régime. Un TTL très court rend le domaine dépendant de la disponibilité permanente de ses serveurs de noms.

  • Le changement de serveurs de noms met deux jours

    Ce qui le provoque : La délégation n'est pas servie par votre zone mais par le registre de l'extension, avec un TTL que vous ne réglez pas et qui se compte souvent en dizaines d'heures.

    Le geste qui corrige : Garder les deux hébergements DNS actifs et synchronisés pendant toute la bascule, plutôt que d'espérer une propagation rapide.

Les questions qu'on se pose ensuite

Le TTL ralentit-il mon site ?

Indirectement et faiblement. Un TTL très court oblige le navigateur d'un nouveau visiteur à attendre une résolution complète plus souvent, ce qui se compte en dizaines de millisecondes. Ce n'est un sujet de performance que sur des valeurs extrêmes.

Peut-on forcer la purge des caches ?

Pas globalement : il n'existe aucun mécanisme pour dire au monde entier d'oublier une réponse. Quelques grands résolveurs publics offrent un formulaire pour purger le leur, ce qui ne règle que leur part du trafic.

Mon TTL est-il toujours respecté ?

Pas exactement. Certains résolveurs appliquent un plancher ou un plafond à ce qu'ils acceptent de garder. Le TTL est une demande sérieuse et largement suivie, pas une garantie à la seconde près.

Quel TTL choisir pour les enregistrements de courrier ?

Une heure convient en régime normal. Ces enregistrements changent rarement, mais quand ils changent, l'erreur se paie en messages perdus : mieux vaut pouvoir corriger dans l'heure que dans la journée.

Le TTL décide de la durée de vos pannes

Un enregistrement faux à 24 heures de durée de vie reste faux pendant 24 heures, même corrigé. DomainVigil relit les enregistrements de chacun de vos domaines tous les jours et vous écrit dès qu'une valeur change, pour que la correction commence tout de suite.

Commencer gratuitement

Cinq domaines gratuits, pour toujours. Sans carte bancaire.

Les autres guides de référence