Serveur DNS cache : comment il fonctionne et comment le maîtriser

Un serveur DNS cache est un résolveur récursif qui conserve en mémoire les réponses obtenues auprès des serveurs autoritaires, chacune pendant la durée de son TTL. Il ne détient aucune zone : il accélère les résolutions et absorbe la charge, mais il ne fait autorité sur rien.

Ce qu’un serveur DNS cache fait à votre place

Lancez `dig www.example.com` deux fois de suite contre votre résolveur local et regardez la ligne `;; Query time:` en bas de la sortie. Le premier appel affiche plusieurs dizaines de millisecondes, le second tombe à 0 ou 1 msec. Rien n'a changé sur Internet entre les deux : la réponse est simplement restée en mémoire. Un serveur DNS cache, c'est cette mémoire, plus la machinerie qui la remplit.

Cette machinerie s'appelle la résolution récursive, décrite dans les RFC 1034 et 1035. Sans réponse en cache, le serveur part d'une liste de treize noms de serveurs racine livrée avec le logiciel (le fichier `root.hints` ou `named.root`), demande qui gère `.com`, obtient une délégation, redemande qui gère `example.com`, obtient une seconde délégation, et interroge enfin le serveur autoritaire de la zone. Le client, lui, n'a envoyé qu'un seul paquet UDP sur le port 53 et n'a rien vu de cette cascade.

Aucune de ces zones ne lui appartient.

C'est exactement ce qui le sépare d'un serveur autoritaire, lequel détient un fichier de zone et répond avec le bit AA positionné. Un cache répond sans AA et avec le bit RA, pour recursion available. La ligne `;; flags:` de `dig` vous montre lequel des deux vous avez au bout du fil. Reste un troisième cas qui traîne dans beaucoup de schémas réseau : le forwarder, qui ne fait pas la récursion lui-même et relaie tout vers un résolveur amont comme 9.9.9.9. Il garde quand même un cache local, ce qui explique une bonne part de la confusion de vocabulaire.

Le TTL décide de tout

Chaque enregistrement DNS transporte une durée de vie en secondes, fixée par l'administrateur de la zone, pas par vous. Un A publié avec un TTL de 300 disparaît du cache cinq minutes après son arrivée. Le résolveur décrémente ce compteur au fil du temps : interrogez-le deux fois à trente secondes d'intervalle, `dig` renverra 300 puis 270. Ce détail suffit à savoir si une réponse sort du cache ou d'un serveur autoritaire, sans aucun outil supplémentaire.

Les réponses négatives se mettent en cache elles aussi. C'est de là que viennent la plupart des mauvaises surprises.

La RFC 2308 impose de conserver un NXDOMAIN pendant la valeur du champ MINIMUM de l'enregistrement SOA de la zone, bornée par le TTL du SOA lui-même. Vous testez un sous-domaine avant de le créer, il n'existe pas encore, le résolveur enregistre son absence. Il continuera de répondre « il n'existe pas » jusqu'à expiration de ce TTL négatif, même une fois l'enregistrement publié. Sur une zone dont le SOA porte un MINIMUM de 86400, l'attente pourrait théoriquement durer une journée : en pratique, les implémentations appliquent leur propre plafond.

Relever `cache-min-ttl` sous Unbound est tentant quand un fournisseur publie des TTL de 30 secondes : moins de trafic sortant, des réponses plus rapides. Le prix est réel. Vous cassez les bascules rapides et la répartition de charge géographique des CDN, qui reposent justement sur ces TTL courts.

Paramètre	Logiciel	Valeur par défaut	Effet
max-cache-ttl	BIND 9	604800 s (7 jours)	Plafonne le TTL positif retenu, quelle que soit la valeur publiée
max-ncache-ttl	BIND 9	10800 s (3 heures)	Plafonne la durée de cache des NXDOMAIN et des NODATA
cache-max-ttl	Unbound	86400 s (24 heures)	Plafond du TTL positif pour les RRsets et les messages
cache-max-negative-ttl	Unbound	3600 s (1 heure)	Plafond du cache négatif
cache-min-ttl	Unbound	0 s	Plancher forcé, désactivé par défaut
cache-size	dnsmasq	150 entrées	Taille du cache exprimée en nombre d'enregistrements, pas en octets

Monter un résolveur cache et vérifier qu’il cache vraiment

Unbound tient en une poignée de directives pour un usage LAN. Les points qui posent problème en production sont toujours les mêmes :

• `interface: 0.0.0.0` et `interface: ::0` pour écouter au-delà de la boucle locale, sinon le serveur reste invisible depuis le réseau
• `access-control: 192.168.1.0/24 allow` : le défaut refuse tout sauf 127.0.0.0/8, ce qui est le bon défaut et la première cause de « ça ne répond pas »
• `prefetch: yes` rafraîchit un enregistrement quand il ne lui reste plus que 10 % de son TTL, avant qu'un client ne le réclame ; la documentation annonce environ 10 % de trafic en plus
• `msg-cache-size` et `rrset-cache-size`, à 4 Mo chacun par défaut, à augmenter ensemble en visant un `rrset-cache-size` double du `msg-cache-size`
• `unbound-checkconf` avant chaque redémarrage : une accolade oubliée coupe la résolution de tout le réseau

Trois caches empilés, une seule commande ne suffit jamais

Un utilisateur signale que le nouveau site ne répond pas, alors que la zone est à jour depuis vingt minutes. Vous purgez le résolveur, rien ne bouge. C'est attendu : il reste au moins deux autres caches entre ce poste et votre serveur.

Purgez du plus lointain vers le plus proche. D'abord le résolveur, ensuite le système, le navigateur en dernier. Dans l'autre sens, le poste va simplement recopier la vieille réponse encore présente en amont, et vous recommencerez.

Firefox et Chrome ajoutent une difficulté supplémentaire : ils peuvent court-circuiter entièrement votre résolveur en parlant DoH (RFC 8484, port 443) à un service tiers. Sous Firefox, vérifiez `network.trr.mode` dans `about:config` avant de conclure à une panne de votre infrastructure. La valeur 0 ou 5 laisse le DNS système travailler, la valeur 2 ou 3 non.

Niveau	Inspecter	Purger
Navigateur Chrome ou Edge	chrome://net-internals/#dns	Bouton Clear host cache
Client Windows	Get-DnsClientCache	ipconfig /flushdns ou Clear-DnsClientCache
Client macOS	Pas de listing officiel	sudo dscacheutil -flushcache puis sudo killall -HUP mDNSResponder
systemd-resolved (Linux)	resolvectl statistics	resolvectl flush-caches
Résolveur Unbound	unbound-control dump_cache	unbound-control flush_zone example.com
Résolveur BIND	rndc dumpdb -cache puis lire named_dump.db	rndc flushname www.example.com ou rndc flush

Ce qui casse, et ce qui se fait attaquer

Un cache récursif laissé ouvert sur Internet finit toujours par servir de levier. L'attaquant émet des requêtes portant l'adresse source de sa victime, votre serveur répond docilement, et une petite question produit une réponse bien plus volumineuse. Fermez avec `access-control` sous Unbound ou `allow-recursion` sous BIND. Si le service doit rester public, activez le Response Rate Limiting.

L'empoisonnement de cache est l'autre classique. En 2008, Dan Kaminsky a montré (CVE-2008-1447) que l'identifiant de transaction sur 16 bits se devinait assez vite pour injecter une fausse délégation dans un résolveur. La RFC 5452 y répond en ajoutant l'aléa du port source, ce qui porte l'entropie autour de trente bits selon la plage de ports éphémères. Certains résolveurs y ajoutent le 0x20 encoding, qui fait varier la casse du nom demandé et la compare au retour : `use-caps-for-id` sous Unbound, désactivé par défaut. Ces mesures rendent la falsification coûteuse sans la rendre impossible.

DNSSEC valide la donnée elle-même. C'est autre chose.

Quand tous les serveurs autoritaires d'une zone deviennent injoignables, un résolveur strict renvoie SERVFAIL et la zone disparaît pour l'ensemble de ses clients. La RFC 8767 autorise à servir des données périmées dans ce cas précis. BIND l'expose via `stale-answer-enable yes`, avec un `stale-answer-ttl` de 30 secondes par défaut et un `max-stale-ttl` qui borne l'âge acceptable des données ; cette dernière valeur par défaut a changé entre les branches de BIND 9, vérifiez-la dans l'ARM de votre version plutôt que de la supposer. Unbound propose l'équivalent avec `serve-expired: yes`.

Le cas de panne le plus courant reste pourtant le plus bête. Un A avec un TTL de 3600 que vous modifiez la veille d'une migration, et des caches qui servent l'ancienne adresse pendant une heure après la bascule. Descendez le TTL à 60 au moins la durée de l'ancien TTL avant l'opération, puis remontez-le une fois la migration stabilisée.

Questions fréquentes

Quelle différence entre un serveur DNS cache et un serveur DNS autoritaire ?

L'autoritaire détient le fichier de zone : il est la source de vérité pour `example.com` et répond avec le bit AA positionné. Le cache ne détient rien, il interroge les autoritaires et conserve leurs réponses pendant la durée du TTL. Un `dig` suffit à les distinguer : regardez la présence de `aa` dans la ligne `;; flags:`.

Combien de temps une entrée reste-t-elle en cache ?

La durée du TTL publié par la zone, sauf si le résolveur applique un plafond plus bas. BIND retient au maximum 604800 secondes par défaut, Unbound 86400. Pour les réponses négatives, la RFC 2308 s'appuie sur le champ MINIMUM du SOA, plafonné à 10800 secondes chez BIND et 3600 chez Unbound par défaut.

Faut-il monter son propre résolveur ou utiliser 1.1.1.1 et 9.9.9.9 ?

Un résolveur local a un intérêt réel dès qu'il y a plusieurs dizaines de postes ou des zones internes à résoudre : le cache est mutualisé et vos requêtes ne partent pas chez un tiers. Un résolveur public a un cache incomparablement plus chaud et une infrastructure anycast. Beaucoup d'installations combinent les deux, avec un Unbound local en forwarder chiffré (DoT, port 853, RFC 7858) vers un résolveur public.

Pourquoi mon changement DNS n’est-il pas visible après un ipconfig /flushdns ?

Parce que `ipconfig /flushdns` ne vide que le cache du client Windows. Le résolveur du réseau conserve l'ancienne réponse jusqu'à expiration de son TTL, et le poste la récupère aussitôt. Purgez d'abord côté serveur (`rndc flushname` ou `unbound-control flush`), puis côté poste. Si le navigateur fait du DoH, il faut aussi vider son propre cache.

Un serveur DNS cache accélère-t-il réellement la navigation ?

Sur la première résolution d'un domaine, oui, en supprimant les allers-retours vers la racine et le TLD. Sur les suivantes, l'effet est marginal parce que le poste et le navigateur ont déjà leur propre cache. Le gain le plus mesurable concerne les pages qui chargent des ressources sur beaucoup de domaines tiers : chacun demande une résolution, et le cache absorbe les répétitions.

Testez vos connaissances

À lire aussi

cache · commande dig · cloudflare dns 1 1 1 1 · anycast