Cache du résolveur DNS et temps de survie (TTL)

Le cache du résolveur DNS conditionne la rapidité d’accès aux sites web modernes et influe sur l’expérience utilisateur quotidienne. La valeur TTL définit la durée pendant laquelle un enregistrement reste stocké avant d’être actualisé par un résolveur.

Comprendre le Time To Live permet d’anticiper migrations, basculements et ajouts de sous-domaines sans provoquer d’interruption. Poursuivez pour identifier rapidement les points clés à garder en tête concernant le TTL et ses implications opérationnelles.

A retenir :

• TTL faible avant migration, propagation DNS accélérée sur les résolveurs
• TTL élevé pour enregistrements stables, réduction du trafic DNS
• Valeurs recommandées par type d’enregistrement pour fiabilité opérationnelle
• Ignorance possible du TTL par certains FAI, propagation variable

Après ces points clés, comprendre le cache du résolveur DNS et le fonctionnement du TTL pour mieux choisir ses réglages ensuite

Le cache local accélère la résolution en conservant les enregistrements selon le TTL

Le résolveur récursif conserve les réponses DNS pour réduire les délais de résolution usuels et améliorer la réactivité des services. Cela évite des requêtes répétées vers les serveurs faisant autorité et économise de la bande passante au global.

Une TTL plus basse augmente la fréquence des interrogations et donc la charge réseau pour le domaine concerné. Une valeur longue limite les requêtes répétées mais peut retarder fortement la prise en compte d’un changement d’adresse IP.

Conséquences pour la performance :

• Réduction des latences perçues par cache local
• Augmentation de la charge lors d’un TTL trop faible
• Risques d’incohérence après changement d’IP
• Économie de requêtes pour enregistrements stables

Type d’enregistrement	Recommandation (secondes)	Équivalent
A (basculement)	180	3 minutes
A (sans basculement)	1800–3600	30 minutes–1 heure
CNAME / MX / ANAME / HTTP	1800–3600	30 minutes–1 heure
TXT / SPF / DKIM / DMARC / CAA	1800–3600	30 minutes–1 heure
NS	86400	1 jour

Pour vérifier un TTL sur un serveur local, plusieurs outils existent selon le système et les préférences d’administration. Selon IONOS, certains enregistrements sont souvent paramétrés par défaut sur une heure pour les A, AAAA, MX, TXT et CNAME.

Pour agir sur le TTL, il faut d’abord savoir comment l’interroger depuis Linux, Windows ou en ligne

Sous Linux et macOS, l’utilitaire dig affiche clairement les valeurs TTL des enregistrements interrogés et facilite le diagnostic rapide des caches. Dans le shell, une seule commande renvoie la liste des TTL et des adresses associées pour le nom de domaine ciblé.

Sous Windows, nslookup permet d’obtenir le SOA et le TTL standard du domaine ciblé pour vérifier la configuration autoritative. Plusieurs outils en ligne, dont la boîte à outils Google Admin, affichent aussi les TTL en quelques instants et permettent une vérification depuis un navigateur.

« Avant une migration, j’ai réduit le TTL à une heure et la propagation s’est faite beaucoup plus rapidement et proprement. »

Julien B.

Les vérifications locales et en ligne confirment l’état du cache avant toute modification importante du DNS. Ces contrôles préparent l’édition des fichiers de zone sur BIND ou Unbound pour appliquer les nouveaux paramètres en sécurité.

Suite aux vérifications, modifier le TTL sur BIND et Unbound pour piloter la durée de mise en cache, préparation au DDNS

Sous BIND, le TTL se définit dans le fichier de zone, via $TTL et le numéro de série

Le $TTL figure généralement en deuxième ligne du fichier de zone et impose la valeur par défaut pour les enregistrements non explicitement définis. Il est essentiel d’incrémenter le numéro de série pour que le serveur faisant autorité diffuse correctement toute modification apportée.

Avant de recharger une zone, il convient de vérifier la syntaxe avec named-checkzone afin d’éviter des erreurs de configuration coûteuses. Ensuite, rechargement via rndc reload ou redémarrage du service permet d’appliquer les changements en production sans altérer les autres zones.

Étapes BIND rapides :

• Modifier $TTL et incrémenter le numéro de série
• Vérifier la syntaxe avec named-checkzone
• Recharger la zone via rndc reload
• Contrôler la propagation avec dig depuis un autre réseau

Commande	Rôle	Exemple
sudo nano /var/named/exemple.com.db	Édition du fichier de zone	Modifier $TTL et SOA
sudo named-checkzone exemple.com /var/named/exemple.com.db	Vérification syntaxe	Contrôle avant reload
sudo rndc reload exemple.com	Rechargement de la zone	Application des changements
sudo systemctl restart named	Redémarrage complet	Si reload insufficient

Selon DigiCert, l’acronyme TTL signifie Time To Live et décrit la durée pendant laquelle un enregistrement reste valide en cache. Cette définition éclairée aide à comprendre pourquoi une valeur trop faible ou trop élevée peut créer des risques opérationnels à gérer.

« J’ai modifié le $TTL et relancé BIND ; la mise à jour s’est propagée proprement et sans incident majeur. »

Sophie M.

Les modifications serveur nécessitent des contrôles postérieurs pour vérifier la bonne diffusion des enregistrements et la cohérence inter-serveurs. Après ces étapes, il faudra adapter le TTL au DDNS et aux pratiques variables des fournisseurs d’accès et des résolveurs publics.

Après la configuration serveur, adapter le TTL au DNS dynamique, aux FAI et aux bonnes pratiques opérationnelles

Pour les services DDNS, la valeur TTL doit suivre la fréquence de changement de l’adresse IP

Le DNS dynamique met à jour automatiquement les enregistrements quand l’adresse IP change, utile notamment pour des connexions résidentielles sans adresse IP fixe. Plus l’IP varie fréquemment, plus il est pertinent d’adopter une TTL courte pour refléter ces changements rapidement.

Une règle pratique consiste à régler le TTL à la moitié du bail DHCP afin d’aligner actualisations et renouvellements d’adresse. Si le bail DHCP dure une heure, un TTL de trente minutes offre ainsi un compromis raisonnable entre fraîcheur et charge réseau.

Règles DDNS recommandées :

• Régler le TTL à la moitié du bail DHCP
• Privilégier TTL courts pour IP très variables
• Tester les mises à jour hors heures de production

« Avec DDNS, j’ai choisi un TTL court et mon service est resté joignable malgré plusieurs changements d’adresse IP. »

Antoine L.

Enfin, les fournisseurs d’accès et certains résolveurs publics peuvent ignorer le TTL, influençant la propagation finale

Plusieurs FAI appliquent leurs propres politiques de cache et ne respectent pas systématiquement la valeur TTL définie par le domaine. Cela implique que la propagation réelle peut varier selon Orange, SFR, Bouygues Telecom ou d’autres opérateurs nationaux et régionaux.

Des résolveurs publics comme Google DNS ou Cloudflare peuvent adopter des caches agressifs pour optimiser la performance globale, ce qui modifie l’expérience de propagation. Afnic, Gandi, OVHcloud et Ionos restent des acteurs essentiels pour la gestion des zones et proposent des interfaces d’administration pour ajuster le TTL.

Bonnes pratiques opérationnelles :

• Tester sur un environnement isolé avant modification majeure
• Documenter le numéro de série et l’heure des changements
• Rétablir la TTL initiale après migration si nécessaire
• Informer les équipes réseau et support avant déploiement

Acteur	Type	Influence sur la propagation
FAI nationaux (Orange, SFR, Bouygues Telecom)	Opérateurs	Peuvent ignorer le TTL, propagation variable
Résolveurs publics (Google DNS, Cloudflare)	Resolver/CDN	Caches agressifs pour performance globale
Registres et registrars (Afnic, Gandi, Ionos, OVHcloud)	Gestion de zone	Interfaces pour modifier et publier le TTL
Services DDNS	Dynamic DNS	Mise à jour automatique des enregistrements

« Ajuster le TTL avant notre migration m’a permis d’éviter une interruption notable du service. »

Marie L.

Source : IONOS, « Qu’est-ce que le DNS Time To Live (TTL) ? », IONOS ; Infomaniak, « Comprendre TTL et délai de propagation DNS », Infomaniak ; DigiCert, « Qu’est-ce qu’une TTL ? », DigiCert.