Test DNS › Guides DNS

TTL et propagation des changements de zone

Après un changement d'adresse, il est courant d'entendre qu'il faut attendre la propagation. Le DNS ne propage rien : il laisse expirer des copies. Comprendre cette nuance change la manière de préparer une migration et la lecture des délais observés.

Sablier en verre posé sur une table en bois clair — Le TTL se compte en secondes chez chaque cache : le délai ressenti dépend de la copie la plus ancienne.

Une durée de vie, pas une diffusion

Chaque réponse DNS comporte un TTL, en secondes, que le serveur autoritatif attache aux enregistrements qu'il renvoie. Le résolveur qui reçoit la réponse la conserve pendant ce temps et la sert à tous les postes qui la demandent. Il n'existe aucune diffusion depuis l'autorité vers les résolveurs du monde : le changement devient visible au fur et à mesure que les copies expirent, chacune à son propre rythme.

Cette distinction n'est pas une subtilité de vocabulaire. Parler de propagation suggère un mécanisme centralisé et un délai connu ; parler d'expiration suppose des caches indépendants, avec des durées différentes et parfois des comportements spécifiques. C'est cette seconde lecture qui permet de prévoir l'effet réel d'un changement.

Le TTL appartient à l'ensemble d'enregistrements, pas au nom : deux enregistrements de même nom mais de types différents peuvent porter des durées de vie différentes. Modifier un TTL pour un type ne change rien pour les autres, ce qui explique certains écarts de comportement observés après une migration partielle.

Qui conserve une copie

Le premier cache est celui du résolveur qui a effectué la requête, souvent celui du fournisseur d'accès ou un résolveur public. Il applique les TTL fournis par l'autorité, avec parfois des bornes internes. Le poste de travail possède aussi son cache local, alimenté par ce résolveur : après un changement, vider ce cache local ne sert à rien tant que le résolveur en amont détient encore l'ancienne réponse.

Les applications conservent enfin leurs propres entrées, parfois bien au-delà du TTL : un client de messagerie peut garder l'adresse du serveur de courrier, un navigateur peut réutiliser une connexion établie. Ces couches expliquent pourquoi un service paraît encore joindre l'ancienne adresse alors que la zone est déjà correcte partout.

Préparer un changement sans coupure

La méthode classique consiste à abaisser le TTL de l'enregistrement concerné avant l'opération, puis à attendre au moins la durée de l'ancien TTL. Toutes les copies de l'ancienne valeur ont alors expiré, et le changement devient visible presque immédiatement pour tout le monde. Une fois le changement stabilisé, le TTL peut être remonté.

L'erreur fréquente est d'abaisser le TTL et de changer dans la minute, sans attendre : les copies de l'ancienne valeur, créées avant l'abaissement, conservent leur durée d'origine. Le délai alors observé est celui de l'ancien TTL, pas du nouveau, et il peut se compter en heures. Un TTL très bas permanent n'est pas une solution : il multiplie les requêtes vers l'autorité et fragilise la résolution en cas d'incident.

Le cache négatif et le rôle du SOA

Un nom qui n'existe pas est aussi mis en cache. La RFC 2308 encadre cette pratique : la durée du cache négatif se déduit du champ minimum du SOA de la zone, avec des plafonds destinés à éviter qu'une erreur ne se fige trop longtemps chez les résolveurs. Sans ces bornes, un nom créé après un essai infructueux resterait introuvable pendant des jours.

Ce comportement a une conséquence directe pour les mises en service : créer d'abord les enregistrements, puis communiquer le nom, évite de générer un cache négatif. À l'inverse, tester un nom avant sa création laisse une trace chez les résolveurs, parfois plus longue que prévu.

Quand un résolveur sert des données expirées

L'expiration n'est pas une garantie absolue. La RFC 8767 décrit le service de données périmées : lorsqu'un résolveur ne parvient pas à joindre les serveurs autoritatifs, il peut répondre avec une copie expirée plutôt que d'échouer, afin de maintenir la résolution pendant un incident. Ce comportement est un choix d'exploitation, encadré par des durées maximales.

Pour l'administrateur, cela signifie qu'un changement peut rester invisible plus longtemps si l'autorité est momentanément injoignable. Un écart persistant entre la zone publiée et ce que renvoie un résolveur n'est donc pas toujours un défaut de cache : il faut vérifier l'accès aux serveurs autoritatifs avant de conclure.

Vérifier au lieu d'attendre

Le contrôle utile consiste à interroger directement les serveurs autoritatifs, sans récursion : la réponse qu'ils donnent est la vérité publiée. Interroger ensuite plusieurs résolveurs distincts, en relevant le TTL restant, montre l'état des caches. Un TTL élevé sur une réponse ancienne indique une copie encore valide, pas une panne.

Le relevé doit porter sur plusieurs resolvers, car chacun a son propre cache. Conclure à partir d'un seul essai revient à tirer une généralité d'une observation locale, et c'est la source la plus fréquente des fausses alertes après un changement de zone.

Le TTL est une durée de vie appliquée par chaque cache, jamais un délai de diffusion centralisé.
Abaisser un TTL n'a d'effet qu'après expiration des copies créées avec l'ancienne valeur.
Le cache négatif dépend du SOA : il se règle avant la mise en service, pas après.
Un résolveur peut servir des données périmées si l'autorité est injoignable.
La seule vérité publiée est celle des serveurs autoritatifs, interrogés sans récursion.

Sources

Pour vérifier un nom de domaine en direct — racine, TLD, serveurs de noms — utilisez l'outil de test DNS. Demarcq.net assure l'exploitation de serveurs DNS : les prestations d'exploitation.

← DNSSEC : principes de signature et de validation Journaliser et superviser un serveur DNS →