Vider le cache DNS ne règle pas tout : Cloudflare montre pourquoi

Vous voyez un site inaccessible, une ancienne IP qui semble “coller”, ou un comportement incohérent après une migration ? Dans ces cas-là, beaucoup de guides proposent immédiatement de vider le cache DNS.

Le geste peut être utile. Mais il y a un piège fréquent : parler du cache DNS comme d’un bloc unique, alors qu’il existe en réalité plusieurs niveaux de mise en cache, avec des rôles, des limites et des symptômes différents.

Autrement dit : vider un cache local peut corriger un problème ponctuel ; optimiser un cache DNS à l’échelle d’un service mondial est un autre métier. Et chez BL Digital, on assume ce point de vue : le réflexe n’est pas une stratégie : on diagnostique avant d’agir.

Le cache DNS, concrètement, à quoi sert-il ?

Le DNS associe un nom de domaine à une adresse IP. La mise en cache DNS consiste à conserver temporairement une réponse DNS pour éviter de refaire la même résolution à chaque demande.

Cette mise en cache peut exister dans plusieurs endroits : système d’exploitation, navigateur, terminal ou serveur DNS récursif. Le bénéfice est simple : si la réponse est déjà connue et encore valide, on gagne du temps et on évite des requêtes inutiles vers l’amont.

C’est le premier point à bien distinguer : quand on dit “le cache DNS”, on parle souvent en réalité de plusieurs caches successifs.

Les principaux niveaux de cache à ne pas confondre

• Le cache local du système d’exploitation : votre machine garde des résolutions déjà vues.
• Le cache du navigateur : certains navigateurs maintiennent aussi leurs propres informations liées à la résolution.
• Le cache d’un résolveur récursif : par exemple chez un fournisseur d’accès, une entreprise ou un fournisseur DNS public.
• Le cache d’une grande plateforme DNS : là, on n’est plus dans le dépannage utilisateur mais dans l’ingénierie à grande échelle.

Cette distinction change tout. Un flush DNS sur un poste peut agir sur un problème local, mais ne modifiera pas, à lui seul, un cache récursif distant ou une logique d’infrastructure.

Pourquoi vider un cache DNS peut parfois aider

Sur ce point, les sources généralistes convergent. CommentÇaMarche explique qu’un système d’exploitation stocke temporairement des informations DNS et qu’un vidage du cache peut aider lorsqu’une information est périmée ou qu’un accès devient incohérent. Akamai décrit aussi le flush comme l’action de supprimer les données mises en cache pour forcer une nouvelle résolution.

En pratique, cela peut aider quand :

• un domaine a changé d’adresse IP ;
• une migration DNS est en cours ;
• un utilisateur continue à voir une ancienne destination ;
• un navigateur ou un poste semble avoir une information locale obsolète.

Le point important : cela traite surtout un symptôme de résolution locale.

Ce que le flush DNS ne règle pas forcément

• un TTL encore actif ailleurs dans la chaîne ;
• un problème sur le résolveur récursif utilisé ;
• une mauvaise configuration autoritative ;
• une architecture DNS/CDN mal pensée ;
• une propagation incomplète observée à plusieurs niveaux.

C’est là qu’il faut éviter le raccourci “ça ne marche pas, donc on flush”. Oui, parfois c’est la bonne action. Mais non, ce n’est pas une méthode de diagnostic suffisante.

Le bon diagnostic commence par une question simple : à quel niveau est le cache concerné ?

Avant d’agir, posez quatre questions très concrètes :

1. Le problème est-il local ou partagé ?

Si un seul poste est touché, la piste du cache local est plausible. Si tout un segment d’utilisateurs observe le même souci, regardez plus haut dans la chaîne.

2. Le symptôme est-il récent après un changement DNS ?

Une migration, une bascule ou un changement de cible rendent le cache suspect, mais pas coupable par défaut.

3. Le problème apparaît-il dans un seul navigateur ou partout ?

Cela aide à distinguer cache navigateur, cache OS et cause plus large.

4. Qu’est-ce qui est vérifié, et qu’est-ce qui est seulement supposé ?

C’est souvent la meilleure manière d’éviter les faux diagnostics.

Ce que montre vraiment l’exemple Cloudflare : l’optimisation d’un cache DNS à une autre échelle

L’article publié par Cloudflare ne parle pas d’un utilisateur qui vide son cache. Il décrit un travail d’optimisation sur Big Pineapple, la plateforme derrière 1.1.1.1 et plusieurs autres services DNS de l’entreprise.

Selon Cloudflare, cette plateforme stocke plus de 250 milliards d’entrées de cache DNS à un instant donné. À cette échelle, un seul octet gaspillé par entrée représente déjà plus de 250 gigaoctets de mémoire à l’échelle de la flotte.

C’est ce changement d’échelle qui mérite l’attention. Ici, le sujet n’est plus “comment retrouver l’accès à un site”, mais “comment représenter efficacement des milliards d’objets DNS en mémoire sans pénaliser les performances”.

Les chiffres publiés par Cloudflare, à replacer dans leur contexte

Cloudflare indique avoir réalisé cinq optimisations successives sur le stockage mémoire de son cache DNS. Dans ses benchmarks internes, l’entreprise rapporte :

• une baisse de l’empreinte mémoire par entrée de 953 octets à 420 octets ;
• une baisse des allocations par entrée de 1,1 KB à 461 octets ;
• une hausse du débit d’insertion de 625 000 à 893 000 entrées par seconde ;
• une baisse de la latence de recherche de 828 ns à 670 ns.

Cloudflare présente cela comme une réduction de 56 % de l’empreinte mémoire par entrée, de 58 % des allocations, avec +43 % sur l’insertion et -19 % sur la latence de lookup.

Et en production, Cloudflare indique une baisse de la mémoire résidente par instance, par exemple de 9,3 GB à 5,3 GB au p99 et de 6,5 GB à 3,8 GB au p90, soit environ 42 à 43 % de réduction selon le percentile observé.

Le fournisseur estime enfin avoir libéré environ 100 téraoctets de mémoire sur l’ensemble de sa flotte.

Le point à retenir : ces chiffres sont ceux de Cloudflare, dans son environnement, avec sa distribution de trafic, son implémentation, ses allocateurs et ses contraintes. Ce n’est pas une règle universelle sur “le DNS”.

Quelles optimisations Cloudflare décrit-elle exactement ?

L’article de Cloudflare est très technique, mais on peut en extraire une idée simple : quand des données sont immuables et massives, la manière de les stocker devient stratégique.

1. Réduire le surcoût des structures dynamiques

Cloudflare explique avoir remplacé certains usages de Vec et String par des structures immuables comme Box<[T]> et Box<str>, pour éviter de conserver une capacité inutilisée en mémoire.

L’idée, en version non développeur : si une réponse DNS ne changera plus une fois stockée, garder de la place “au cas où” devient du gaspillage.

2. Fusionner des listes pour diminuer les métadonnées

L’entreprise décrit aussi le passage de plusieurs listes séparées à une liste unique avec des offsets pour repérer les sections d’une réponse DNS.

Là encore, l’objectif n’est pas d’“ajouter du cache”, mais de réduire le coût structurel du cache existant.

3. Ne pas stocker deux fois une information souvent identique

Cloudflare indique qu’un grand nombre d’enregistrements ont un propriétaire/owner identique au nom de domaine demandé. Dans ces cas, l’entreprise a choisi de ne plus stocker explicitement cette information dans chaque enregistrement, et de la reconstituer lors de la lecture lorsque c’est possible.

Autrement dit : si une information est déjà disponible ailleurs dans la clé de cache, la dupliquer partout peut coûter cher.

4. Réduire le coût des types les plus rares sur les plus fréquents

Le blog explique aussi un problème classique en bas niveau : lorsque des structures doivent être assez grandes pour contenir leur cas le plus volumineux, les cas courants peuvent payer un fort coût de “padding”.

Cloudflare montre que ce sujet était particulièrement important pour des enregistrements A et AAAA, qu’elle présente comme représentant plus de 80 % du trafic de son benchmark.

5. Stocker des données d’enregistrement sous une forme plus compacte

Dernier point majeur : Cloudflare dit avoir choisi de stocker les record data comme octets bruts dans un tampon contigu, plutôt que de conserver certaines représentations plus coûteuses en mémoire.

Selon l’entreprise, cela réduit à la fois le nombre d’allocations et améliore la localité mémoire, ce qui explique une partie des gains de performance rapportés.

Source : https://blog.cloudflare.com/dns-cache-memory-optimization-1111/ — textes de l’illustration traduits en français par BL Digital.

Pourquoi cet exemple Cloudflare est utile… même si vous ne gérez pas 250 milliards d’entrées

Soyons clairs : peu d’équipes ont un problème de cache DNS comparable à celui de Cloudflare. En revanche, le retour d’expérience est utile pour une raison très pratique : il rappelle que “optimiser le cache” ne veut rien dire tant qu’on n’a pas défini le niveau concerné.

Entre :

• vider un cache local pour forcer une nouvelle résolution,
• ajuster un TTL,
• analyser un résolveur récursif,
• mesurer un hit ratio,
• ou repenser une structure mémoire interne,

on parle de métiers, d’outils et de temporalités différentes.

C’est aussi là qu’il faut croiser les sources avec nuance. Akamai insiste sur les bénéfices généraux de la mise en cache DNS pour la vitesse et la réduction du trafic. Cloudflare montre qu’à grande échelle, ces bénéfices dépendent aussi de décisions d’implémentation très concrètes. Les deux sont compatibles, mais ils ne parlent pas du même étage du problème.

Flush DNS, cache navigateur, cache résolveur : la bonne lecture d’un incident

Si vous devez décider quoi faire, voici une grille simple.

Cas 1 : un seul utilisateur voit encore l’ancienne version d’un site

La piste prioritaire est le cache local ou éventuellement le cache navigateur. Un flush peut être une action réversible et pertinente.

Cas 2 : plusieurs utilisateurs, sur plusieurs réseaux, voient des résultats incohérents

Le sujet dépasse probablement le poste local. Regardez du côté :

• des enregistrements DNS publiés ;
• du TTL ;
• des résolveurs utilisés ;
• d’une éventuelle coexistence de réponses selon les chemins réseau.

Cas 3 : vous cherchez à “améliorer les performances DNS”

La bonne question n’est pas “faut-il vider le cache ?”, mais :

• quel cache ?
• quelle métrique ?
• quel symptôme ?
• quelle contrainte ?
• quelle action est réversible ?

Ce qu’il faut retenir avant d’agir

Voici la version courte :

• Oui, la mise en cache DNS accélère la résolution et réduit les requêtes répétées, comme l’explique Akamai.
• Oui, un flush DNS peut aider quand une machine ou un navigateur garde une information locale obsolète, comme le rappellent les guides pratiques.
• Non, cela ne doit pas être confondu avec une stratégie d’optimisation DNS globale.
• Oui, l’exemple Cloudflare est instructif, mais ses chiffres restent propres à Cloudflare et à son environnement.
• Non, un retour d’expérience fournisseur n’est pas une recette universelle.

FAQ courte

Le flush DNS améliore-t-il toujours les performances ?

Non. Il peut résoudre un problème de cache local ou forcer une résolution fraîche, mais il ne constitue pas en soi une optimisation durable des performances.

Le cache DNS existe-t-il seulement sur mon ordinateur ?

Non. D’après Akamai, il peut exister au niveau du système d’exploitation, du navigateur, du terminal ou des serveurs DNS récursifs.

Les chiffres de Cloudflare sur 1.1.1.1 s’appliquent-ils à tous les environnements ?

Non. Cloudflare publie des résultats observés dans son infrastructure et ses benchmarks. Ils sont intéressants, mais ne doivent pas être généralisés sans contexte.

Quand faut-il commencer par diagnostiquer plutôt que vider le cache ?

Dès que le problème touche plus d’un poste, survient après une modification DNS importante, ou mélange des symptômes qui peuvent venir de plusieurs niveaux de cache.

Conclusion

Si vous ne retenez qu’une chose, retenez celle-ci : un cache DNS n’est pas un objet unique.

La bonne méthode reste simple :

• quel niveau de cache est concerné ?
• quel symptôme est observé ?
• quels faits sont vérifiés ?
• quelle action est réversible ?