// OUTIL GRATUIT · CALCULATEUR DE TTL DNS
Calculateur et convertisseur de TTL DNS
Saisissez un TTL : vous obtenez la durée qu’il représente et, surtout, le calendrier qui compte vraiment. Avant de changer de serveurs DNS ou d’hébergeur, baissez le TTL des enregistrements à 300 secondes au moins un ancien TTL complet à l’avance — une heure avant si le TTL vaut 3600, un jour avant s’il vaut 86400 — puis basculez, attendez un TTL bas le temps que tous les caches suivent, et remettez la valeur d’origine une fois que c’est stable. Le calculateur fait aussi l’arithmétique du cache négatif de la RFC 2308 : la durée pendant laquelle un domaine réparé continue de répondre NXDOMAIN. Gratuit, immédiat, sans inscription, entièrement dans votre navigateur.
Des secondes, ou une durée : 3600, 1h, 90min, 1d 12h, 04:00:00. Tout ce qui dépasse une semaine est refusé.
Valeurs courantes — cliquez sur l’une d’elles :
Le TTL utilisé pendant que le changement est en cours. 300 secondes est le choix habituel ; en dessous de 60 vous n’achetez que du volume de requêtes.
Les deux se lisent dans le SOA de la section authority d’une réponse NXDOMAIN : dig SOA exemple.fr. La RFC 2308 retient le plus petit des deux. Les valeurs pré-remplies sont celles de la zone fr. (600 et 600) ; en com. ce serait 900, en de. 7200.
Mode d’emploi du calculateur de TTL
Trois champs, aucun compte, et le calcul se fait en local : rien de ce que vous tapez n’est envoyé où que ce soit.
- Saisissez le TTL actuel. Le TTL présent sur les enregistrements que vous vous apprêtez à modifier, en secondes ou sous forme de durée comme 1h. Le convertisseur affiche la durée correspondante et indique s’il s’agit d’une valeur de bascule, équilibrée ou stable.
- Lisez le calendrier du changement. Il donne le TTL bas à utiliser pendant l’opération, combien de temps à l’avance le publier, combien de temps les caches mettent à suivre après la bascule, et la valeur à remettre ensuite.
- Ajoutez les nombres du SOA si le domaine renvoie NXDOMAIN. Lancez dig SOA exemple.fr, relevez le champ minimum et le TTL de l’enregistrement SOA lui-même : le calculateur renvoie la fenêtre de cache négatif de la RFC 2308, c’est-à-dire combien de temps le refus survit à la réparation.
Changer de DNS : quand baisser le TTL, quand basculer
On ne consulte presque jamais un TTL par curiosité pour les secondes. On le consulte parce qu’un déménagement est prévu et qu’on veut qu’il soit court. La règle comporte une moitié qui n’a rien d’évident :
Baisser le TTL ne sert que si vous le publiez avant le changement, et au moins un ancien TTL complet avant. Passer un TTL de 24 heures à 300 secondes dix minutes avant la bascule ne produit rigoureusement rien : les résolveurs qui détiennent la copie d’hier ne reviendront pas voir la nouvelle valeur, plus courte, avant demain. L’ancien TTL doit d’abord expirer de lui-même. D’où le calendrier complet :
- Baissez le TTL à 300 secondes, un ancien TTL à l’avance — deux si vous voulez de la marge, car certains résolveurs rafraîchissent en avance et d’autres non.
- Basculez : changez les serveurs de noms, ou repointez les enregistrements.
- Attendez un TTL bas — cinq minutes — et tout cache qui respecte les règles détient la nouvelle réponse.
- Remettez l’ancien TTL une fois que c’est stable, pour ne pas payer une résolution à chaque visite.
La seule chose que vous ne pouvez pas baisser, c’est le TTL de la délégation elle-même. Les enregistrements NS qui pointent vers vos serveurs de noms vivent dans la zone parente et sont publiés par le registre. Bonne nouvelle pour le .fr : l’AFNIC les sert avec un TTL d’une heure seulement, là où com. les sert avec 48 heures — c’est le sujet de la section suivante. Dans tous les cas, lire la délégation depuis deux résolveurs (en anglais) vous en dit plus que de regarder l’horloge.
Le .fr n’a pas les mêmes chiffres : une heure côté AFNIC, et les valeurs par défaut des hébergeurs
« Comptez 24 à 48 heures de propagation » : la phrase est partout, y compris dans des documentations françaises. Elle est fausse pour le .fr, et pas d’un peu. Tout ce qui suit a été mesuré le 4 septembre 2026 en interrogeant directement les serveurs faisant autorité, et se reproduit en une minute.
La zone fr. sert la délégation de votre domaine avec un TTL de 3600 secondes — une heure.
dig +norecurse NS votre-domaine.fr @a.nic.fr
votre-domaine.fr. 3600 IN NS dns1.votre-hebergeur.fr.À comparer aux 172800 secondes de com., soit 48 heures, et aux 86400 secondes du .de et du .es. Autrement dit, la moitié du délai que tout le monde redoute — celle sur laquelle vous n’avez aucune prise — est quarante-huit fois plus courte en .fr qu’en .com. Le corollaire est plus intéressant que le chiffre : sur un domaine en .fr, si un changement de serveurs DNS met encore une journée à être visible, ce n’est presque jamais le registre. C’est le TTL de vos propres enregistrements, ou celui que votre hébergeur applique par défaut. La partie que vous pouvez réduire est donc, chez nous, l’essentiel du délai.
Le cache négatif du .fr est lui aussi court : 600 secondes, dix minutes. La zone fr. joint à ses réponses NXDOMAIN un SOA dont le TTL vaut 600 et dont le champ minimum vaut 600 également ; la RFC 2308 retenant le plus petit des deux, le résultat est 600. Un domaine .fr qui vient d’être créé ou dont la délégation vient d’être rétablie redevient donc joignable en une dizaine de minutes, là où un .de demande deux heures.
Restent les hébergeurs, et c’est là que le délai se joue vraiment. Voici les valeurs que chacun sert sur sa propre zone — ce n’est pas nécessairement la valeur par défaut de votre panneau d’administration, mais c’est l’éventail que vous croiserez sur ce marché :
| Hébergeur | TTL de l’enregistrement A | Minimum du SOA | Cache négatif réel |
|---|---|---|---|
| OVHcloud | 3600 s | 600 s | 600 s — 10 minutes |
| Gandi | 600 s | 1200 s | 1200 s — 20 minutes |
| IONOS France | 300 s | 600 s | 600 s — 10 minutes |
| LWS (via Cloudflare) | 300 s | 1800 s | 1800 s — 30 minutes |
| o2switch | 320 s | 86400 s | 86400 s — 24 heures |
La dernière colonne est celle que personne ne publie : le cache négatif réel n’est pas le champ minimum, c’est min(minimum, TTL du SOA). Chez OVHcloud, Gandi et IONOS les deux nombres divergent et c’est le plus petit qui gagne, d’où des fenêtres de dix à vingt minutes. Chez o2switch, les deux valent 86400 : un sous-domaine mal orthographié que quelqu’un a essayé avant que vous ne le créiez peut continuer à échouer pendant vingt-quatre heures, sans que rien ne soit cassé et sans qu’aucun vidage de cache navigateur n’y change quoi que ce soit. Avant de refaire la manipulation, calculez la fenêtre — c’est précisément ce que font les deux derniers champs de l’outil ci-dessus.
Cache négatif : pourquoi une panne survit à sa réparation
Les résolveurs mettent en cache « ce nom n’existe pas » exactement comme ils mettent en cache une adresse, et ce souvenir a son propre TTL. La RFC 2308 le fixe au plus petit de deux nombres : le champ minimum de l’enregistrement SOA et le TTL de l’enregistrement SOA lui-même — les deux valeurs que réclame le calculateur. Toutes deux arrivent dans la section authority de la réponse NXDOMAIN, donc dig SOA exemple.fr vous les livre.
C’est ce nombre qui décide combien de temps une réparation reste invisible. Lors de notre propre panne de délégation de juin 2026 (en anglais), l’enregistrement chez le registre a été corrigé le 30 juin à 17 h 30 UTC, et les domaines ne sont revenus pour une grande partie d’internet que les 1er et 2 juillet : les résolveurs utilisés étaient encore dans la fenêtre négative. Deux conséquences pratiques. Ne jugez pas une délégation réparée avant que cette fenêtre soit passée. Et ne la réparez pas deux fois à l’intérieur de la fenêtre : c’est ainsi qu’une bonne configuration se fait remplacer par une moins bonne.
Valeurs de TTL courantes, et à quoi sert chacune
| Secondes | Se lit | À quoi ça sert |
|---|---|---|
60 | 1 minute | Migration en cours ou enregistrement de bascule. Chaque visiteur coûte une résolution ; ne laissez pas cette valeur en place. |
300 | 5 minutes | Le TTL de bascule. À publier avant un changement de DNS ou d’hébergeur, et à remettre après. |
600 | 10 minutes | Le cache négatif de la zone fr., et le minimum du SOA chez OVHcloud comme chez IONOS. |
1200 | 20 minutes | Le minimum du SOA sur les zones Gandi. |
3600 | 1 heure | La réponse la plus fréquente à « quel TTL mettre » — assez court pour changer dans la journée, assez long pour rester peu coûteux. C’est aussi le TTL de la délégation en .fr. |
14400 | 4 heures | La valeur par défaut de l’époque cPanel. Toujours très répandue, et l’explication de bien des changements qui prennent une demi-journée. |
43200 | 12 heures | Enregistrements stables uniquement. Un changement d’urgence aura une demi-journée de retard sur vous. |
86400 | 1 jour | MX, TXT et tout ce que vous n’avez pas touché depuis un an. C’est aussi le cache négatif d’une zone o2switch non modifiée. |
172800 | 2 jours | Le TTL de la délégation dans com. et net. — fixé par le registre, pas par vous. |
604800 | 1 semaine | Le plafond pratique. Au-delà, vous misez sur des caches que vous ne pouvez plus joindre. |
Pour lire le TTL qu’un résolveur détient réellement en ce moment, et non celui que vous avez configuré : dig exemple.fr +noall +answer l’affiche en deuxième colonne, et il décompte à mesure que la copie vieillit. Sous Windows, nslookup -debug exemple.fr montre le même champ. Un TTL très inférieur à celui que vous avez réglé signifie que quelqu’un d’autre que prévu sert l’enregistrement ; un TTL qui ne bouge jamais signifie que vous lisez un serveur faisant autorité et non un cache.
// Questions fréquentes
Quel TTL faut-il mettre avant de changer de serveurs DNS ?
300 secondes, publiés au moins un ancien TTL complet avant le changement. L’ordre est la partie que tout le monde rate : baisser un TTL de 24 heures une heure avant la bascule ne change rien, car les résolveurs qui détiennent l’ancienne copie ne la reliront que le lendemain. Baissez-le un jour à l’avance, faites le changement, attendez cinq minutes que les caches suivent, puis remettez la valeur d’origine pour ne pas payer une résolution à chaque visite. En .fr, la délégation elle-même n’ajoute qu’une heure, ce qui rend cette étape encore plus déterminante.
Un TTL de 3600, ça fait combien ?
Une heure. C’est le TTL le plus courant sur les enregistrements web : assez long pour que la plupart des visiteurs soient servis depuis un cache, assez court pour qu’un changement atteigne tout le monde dans l’heure ouvrée. Deux autres valeurs reviennent souvent : 14400, soit quatre heures, valeur par défaut de toute une génération de panneaux d’hébergement, et 86400, soit un jour, réservée aux enregistrements que vous ne comptez pas déplacer.
Combien de temps prend vraiment un changement de DNS sur un .fr ?
Beaucoup moins que les 24 à 48 heures habituellement annoncées, parce que ce chiffre vient du .com. La zone fr. sert la délégation avec un TTL de 3600 secondes, une heure — vérifiable avec dig +norecurse NS votre-domaine.fr @a.nic.fr — contre 172800 secondes pour com. Sur un .fr, le délai restant vient donc presque entièrement du TTL de vos propres enregistrements et de celui appliqué par votre hébergeur, c’est-à-dire de la partie que vous pouvez réduire à l’avance.
Qu’est-ce que le TTL de cache négatif et comment se calcule-t-il ?
C’est la durée pendant laquelle les résolveurs se souviennent qu’un nom n’existe pas. La RFC 2308 la définit comme le plus petit du champ minimum de l’enregistrement SOA et du TTL de l’enregistrement SOA lui-même ; les deux arrivent dans la section authority d’une réponse NXDOMAIN, donc dig SOA exemple.fr suffit à les lire. Pour la zone fr. les deux valent 600, soit dix minutes. Sur une zone o2switch non modifiée, les deux valent 86400 : un sous-domaine essayé avant sa création peut échouer pendant vingt-quatre heures.
Baisser le TTL accélère-t-il la propagation DNS ?
Uniquement si vous le baissez à l’avance. Il n’y a pas de propagation au sens de données qui circuleraient de serveur en serveur : le registre et vos serveurs de noms ont la nouvelle réponse immédiatement, et ce que vous attendez, ce sont des résolveurs dont la copie en cache n’a pas encore expiré. Un TTL baissé avant le changement raccourcit ces copies. Un TTL baissé en même temps que le changement ne raccourcit rien, puisque les caches qui vous intéressent détiennent encore la valeur précédente avec sa durée précédente.
Un TTL très bas, est-ce un problème ?
En régime permanent, oui : à 30 secondes, presque chaque visite coûte une résolution DNS, ce qui ajoute de la latence pour vos utilisateurs et de la charge sur vos serveurs de noms, et vous prive du coussin qui garde le site joignable si votre hébergeur DNS traverse dix mauvaises minutes. Autour d’un changement, en revanche, c’est exactement le bon réglage. Le motif est baisser, changer, vérifier, remettre — et non s’installer durablement à 60 secondes parce qu’une migration l’a exigé une fois.
Le TTL qui compte est celui qui arrive dans la réponse.
Une commande lit votre domaine depuis deux résolveurs publics avec le TTL restant sur chaque enregistrement, puis vérifie la zone, la liaison du nom d’hôte et le contenu réellement servi.
$ npm i -g @clize/clize && clize install $ clize domain check votre-domaine.fr[ Agent Domains → ]