Qu’est-ce qu’un cache DNS et combien de temps dure-t-il ?

Où une réponse DNS est-elle réellement mise en cache ?

Une seule résolution traverse plusieurs caches avant que vous ne remarquiez quoi que ce soit, et chacun garde sa propre copie pendant sa propre durée :

• Le navigateur. Chrome, Edge et Firefox gardent chacun un petit cache DNS qui leur est propre, distinct de celui du système d’exploitation. Celui de Chrome est visible sur chrome://net-internals/#dns, et le vider n’affecte que ce navigateur, pas le reste de la machine.
• Le résolveur stub de l’OS. Windows fait tourner le service Client DNS et met en cache les réponses que vous pouvez lister avec ipconfig /displaydns ; macOS met en cache via mDNSResponder ; la plupart des bureaux Linux font tourner systemd-resolved, un résolveur stub local avec mise en cache que vous interrogez avec resolvectl. C’est un vrai cache avec son propre compte à rebours de TTL, pas juste une copie de ce que le navigateur a.
• Le routeur. La plupart des routeurs domestiques font tourner un petit relais DNS qui répond depuis son propre cache avant de transmettre une requête en amont, ce qui explique pourquoi redémarrer le routeur corrige parfois un problème DNS qui se trouvait ailleurs en réalité.
• Le résolveur récursif. Le résolveur de votre FAI, ou un résolveur public, traite la plupart des résolutions sur internet et détient le cache le plus grand et le plus partagé. Une fois qu’il a une réponse, chaque appareil qui l’interroge reçoit la copie en cache jusqu’à ce qu’elle expire.

Chaque couche est indépendante. Vider le cache sur votre portable ne fait rien au cache que votre routeur ou votre FAI détient encore, et ça ne fait rien non plus pour la machine de quelqu’un d’autre.

Qu’est-ce qu’un TTL, et qui le respecte réellement ?

Chaque enregistrement DNS porte une durée de vie : un nombre en secondes, fixé par qui gère la zone, qui indique à un résolveur combien de temps il peut réutiliser la réponse avant de redemander. La RFC 1035 la définit comme l’intervalle pendant lequel un enregistrement « peut être mis en cache avant que la source de l’information ne doive être consultée à nouveau », et un TTL de zéro signifie que la réponse ne doit jamais être mise en cache du tout.

Chaque cache de la chaîne, navigateur, résolveur stub, routeur, résolveur récursif, est censé respecter ce nombre, en décomptant depuis le moment où il a récupéré l’enregistrement pour la première fois. En pratique, certains résolveurs de FAI appliquent leur propre plancher par-dessus, souvent une heure ou plus, quoi que dise la zone sur le TTL. C’est pourquoi abaisser un TTL pour accélérer un futur changement aide la plupart des résolveurs mais n’est pas une garantie pour chacun d’entre eux.

Qu’est-ce que la mise en cache négative, et pourquoi un tout nouvel enregistrement peut-il rester introuvable ?

Un résolveur ne met pas en cache que les enregistrements qui existent. Si une requête revient avec « aucun nom de ce genre » (NXDOMAIN) ou sans enregistrement du type demandé, cet échec est aussi mis en cache, un comportement appelé mise en cache négative. La RFC 2308 fixe la durée de vie du cache négatif à partir du champ minimum de l’enregistrement SOA, et la RFC 9520 rend désormais la mise en cache de cet échec obligatoire plutôt qu’optionnelle pour un résolveur conforme.

C’est le mécanisme derrière un problème familier : vous créez un nouveau sous-domaine, vous l’interrogez une seconde trop tôt, vous obtenez NXDOMAIN, et le résolveur retient « n’existe pas » pendant la durée du TTL négatif de la zone, même si l’enregistrement existe désormais. Windows rend les deux types d’entrée visibles séparément : ipconfig /displaydns liste à la fois les réponses positives et les négatives, et ipconfig /flushdns rejette explicitement les entrées de cache négatives dans le cadre du vidage du cache.

Pourquoi un site se résout-il pour vous et pas pour quelqu’un d’autre ?

Parce qu’il n’existe pas de cache unique et partagé. Deux personnes qui interrogent deux résolveurs différents, ou qui interrogent le même résolveur à deux moments différents, peuvent obtenir deux réponses différentes pour le même nom. La copie d’un résolveur peut être encore fraîche depuis une résolution faite il y a une heure ; un autre n’a peut-être jamais vu ce nom et va chercher la valeur actuelle. Aucun des deux n’a tort, ils sont juste sur des horloges différentes. Si cela arrive juste après que vous avez changé un enregistrement, comment vérifier la propagation DNS explique comment comparer plusieurs résolveurs côte à côte et lire combien de temps il reste à chacun.

Comment lire le TTL d’un enregistrement encore en cache ?

Interrogez le nom directement et gardez la sortie complète au lieu de la forme courte :

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Le nombre avant le type d’enregistrement, 847 dans cet exemple, est le nombre de secondes restant avant que la copie de ce résolveur précis n’expire ; ce n’est pas le TTL d’origine de l’enregistrement, que seul le serveur faisant autorité peut vous indiquer avec certitude. Relancez la même requête quelques secondes plus tard et le nombre aura baissé d’à peu près ce nombre de secondes, confirmant que vous lisez un compte à rebours en direct plutôt qu’un réglage statique. Si un nom ne se résout pas du tout plutôt que de se résoudre avec un petit nombre, c’est un échec différent : comment vider le DNS couvre le vidage de votre propre cache en premier, et ce que fait réellement un résolveur DNS couvre ce qui se passe ensuite dans la chaîne quand votre propre cache n’est pas le problème.

Un cache explique pourquoi un visiteur voit un changement immédiatement et un autre non ; il n’explique pas un enregistrement qui ne se met jamais à jour nulle part. Lancez une résolution en direct avec l’outil de requête DNS pour voir la réponse actuelle depuis l’extérieur de votre propre réseau, et si le site doit rester joignable selon un horaire plutôt que vérifié une seule fois, c’est à cela que sert la surveillance distribuée depuis de nombreux points de contrôle. HostTracker surveille des sites web depuis 2004, observe aujourd’hui plus de 500 000 sites depuis plus de 300 points de contrôle répartis dans 158 villes, et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus quand une vérification échoue, y compris une vérification qui attend une adresse IP précise et le signale dès que la réponse change.

Questions fréquentes

Un cache DNS plein ralentit-il mon ordinateur ?

Non. Un cache DNS est une petite table de noms et d’adresses, typiquement quelques centaines d’entrées au plus, et en chercher une ne coûte rien de mesurable. Si les résolutions semblent lentes, le cache lui-même n’en est pas la cause ; un résolveur distant ou surchargé en est la cause habituelle.

Vider mon cache corrige-t-il les choses pour les autres ?

Non. ipconfig /flushdns, dscacheutil -flushcache et resolvectl flush-caches ne vident que le cache de la machine sur laquelle vous les exécutez. Tout le monde continue de lire depuis son propre navigateur, son propre routeur et son propre résolveur, chacun sur sa propre minuterie.

Un cache DNS est-il la même chose qu’un cache CDN ?

Non, même si les deux sont confondus. Un cache DNS stocke la réponse à « quelle est l’adresse IP de ce nom ». Un cache CDN stocke le contenu réel de la page ou du fichier sur un serveur proche du visiteur. Vider l’un n’a aucun effet sur l’autre.

Puis-je fixer mon propre TTL si je ne gère pas le domaine ?

Non. Le TTL est une propriété de l’enregistrement, fixée dans la zone faisant autorité par qui gère le DNS du domaine. En tant que visiteur, le seul levier dont vous disposez est de choisir d’interroger un résolveur qui respecte un TTL court plutôt qu’un résolveur qui impose son propre plancher.

Pourquoi le TTL que je vois change-t-il à chaque requête ?

Parce que vous interrogez un résolveur différent, ou le même résolveur à un moment différent de son compte à rebours. Interrogez directement le serveur faisant autorité avec dig example.com @ns1.yourdns.example pour voir le TTL tel qu’il a été fixé à l’origine, sans rien déjà décompté.