Résolveurs DNS : mise en cache négative — le paramètre qui prolonge les pannes

février 17, 2026 • février 17, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Voici une chronologie d’incident classique : vous saisissez mal un enregistrement DNS, vous vous en rendez compte immédiatement, vous le corrigez en une minute… et les utilisateurs continuent d’échouer pendant encore 30–60 minutes. Le ticket indique « DNS est encore en panne », vos tableaux de bord montrent « autoritatif correct », et l’entreprise demande « vous êtes sûrs ? »

Bienvenue dans la mise en cache négative : la fonctionnalité du résolveur qui met en cache les échecs (comme NXDOMAIN) et transforme une erreur courte en semblant d’incompétence prolongée. Ce n’est pas malveillant. Ça fait juste son travail — souvent avec des valeurs par défaut choisies pour l’internet d’hier et le budget de latence d’aujourd’hui.

Mise en cache négative en langage simple

Le DNS est une base de données distribuée qui renvoie le plus souvent « voici l’IP » (ou « voici le CNAME »). La mise en cache négative, c’est ce qui se passe quand elle renvoie « nom inconnu » (NXDOMAIN) ou « pas de données » (NODATA : le nom existe, mais pas ce type d’enregistrement), et que le résolveur décide de se souvenir de cet échec pendant un certain temps.

Ce « pendant un certain temps » est toute l’histoire. La mise en cache négative convertit des résolutions transitoires en moins de requêtes en amont, réduit la charge sur les serveurs autoritatifs et accélère les utilisateurs quand un nom n’existe vraiment pas. Mais quand un nom commence à exister — parce que vous venez de le créer, de le corriger ou de changer la délégation — la mise en cache négative peut maintenir les clients dans le passé.

Deux vérités différentes peuvent coexister :

Votre serveur autoritatif répond correctement maintenant.
Les résolveurs de vos clients sont toujours convaincus que le nom n’existe pas.

Si vous avez déjà vu une équipe SRE « attendre que le DNS passe » les dents serrées, voilà pourquoi.

Blague sèche #1 : La propagation DNS n’existe pas — l’expiration des caches DNS oui. Malheureusement, le marketing préfère le premier terme.

Comment fonctionne réellement la mise en cache négative (et pourquoi le SOA compte)

NXDOMAIN vs NODATA : même douleur, sémantique différente

NXDOMAIN signifie que le nom interrogé n’existe pas dans cette zone. Exemple : vous demandez api.example.com, et le serveur autoritatif répond « jamais entendu parler ».

NODATA (souvent vu comme NOERROR avec une section answer vide) signifie que le nom existe, mais pas le type demandé. Exemple : www.example.com existe avec un enregistrement A, mais vous demandez AAAA et la zone n’en a pas. Beaucoup de résolveurs mettent aussi ce cas en cache négatif.

Opérationnellement : les deux peuvent gêner des déploiements, notamment les déploiements dual-stack (AAAA) et les patterns de discovery qui comptent sur « l’absence = désactivé ».

Le TTL de la mise en cache négative est généralement tiré du SOA

La mise en cache négative est un comportement standardisé (RFC 2308), et le TTL utilisé pour mettre en cache les réponses négatives est dérivé de l’enregistrement SOA de la zone.

Voici la version pratique :

Les réponses autoritatives incluent souvent le SOA de la zone dans la section authority pour les réponses négatives.
Le résolveur utilise le TTL du SOA et/ou le champ « minimum » (selon le serveur et le résolveur) pour décider combien de temps mettre en cache la réponse négative.
Les résolveurs peuvent aussi limiter localement les TTL négatifs par politique (pour bon sens et sécurité).

Si votre SOA de zone est réglé avec un TTL négatif d’une heure, vous venez d’autoriser chaque résolveur à se souvenir de votre erreur pendant une heure. Cela peut être acceptable pour la protection contre le typosquatting et la charge de requêtes. Ce n’est pas acceptable pour des déploiements rapides de services qui créent des noms à la demande.

Qui est « le résolveur », au juste ?

La résolution DNS traverse souvent plusieurs caches :

Stub resolver sur l’hôte (ou systemd-resolved)
Cache local au nœud (commun en Kubernetes, par ex. NodeLocal DNSCache)
Résolveur récursif (Unbound, BIND, PowerDNS Recursor, résolveurs d’entreprise, résolveurs ISP)
Caches applicatifs (cache DNS JVM, comportement du résolveur Go, caches en processus)
CDN / appliances de sécurité qui proxyfient le DNS

La mise en cache négative peut se produire à plusieurs couches. C’est pourquoi « j’ai vidé le DNS de mon laptop » ne change parfois rien : le cache rancunier n’est pas sur votre laptop.

Une citation à afficher sur votre écran

L’espoir n’est pas une stratégie. — Gene Kranz

Les incidents DNS adorent « l’espoir ». Espérer que les caches expirent bientôt. Espérer que les clients retentent. Espérer que l’autre équipe n’a pas réglé des TTLs géologiques. N’espérez pas. Mesurez, bornez et vérifiez.

Faits et contexte historique à connaître

La mise en cache négative a été formalisée pour protéger le DNS contre des requêtes répétées inutiles quand les noms n’existent pas (RFC 2308). C’est une fonctionnalité d’échelle, pas un bug.
« SOA minimum » signifiait auparavant TTL par défaut dans les pratiques DNS plus anciennes ; les zones modernes utilisent des TTL explicites, mais ce nommage hérité crée encore de la confusion pendant la réponse aux incidents.
Les résolveurs mettent presque toujours en cache NXDOMAIN sauf configuration contraire, car échouer rapidement et répéter peut faire un DoS des infrastructures autoritatives tout autant que le trafic réussi.
La mise en cache négative s’applique à plus que NXDOMAIN : « pas d’AAAA » est souvent mis en cache comme réponse négative. Cela compte pour les déploiements IPv6.
Certaines implémentations limitent les TTL négatifs (par exemple à quelques minutes) pour réduire le rayon d’action des erreurs, mais les entreprises les remplacent souvent « pour la performance ».
DNSSEC a changé la donne pour les réponses négatives : le déni d’existence authentifié (NSEC/NSEC3) rend les réponses négatives prouvables cryptographiquement, ce qui les rend aussi plus sûres à mettre en cache.
Les navigateurs et runtimes ont renforcé leur cache au fil du temps pour réduire la latence. Ça aide le chargement des pages ; ça prolonge aussi les moments « on a réparé mais ça marche toujours pas ».
Kubernetes a rendu le DNS plus central pour la santé applicative que beaucoup d’entreprises n’y étaient prêtes ; la mise en cache négative est particulièrement pénible quand les services et endpoints sont éphémères.

Où vivent les caches négatifs : stub, récursif, application et “helpful” middleboxes

1) Résolveurs stub au niveau de l’hôte

Sur Linux, vous pouvez avoir affaire à systemd-resolved, nscd, dnsmasq, ou rien du tout (glibc envoyant les requêtes directement aux recursors configurés). Chacun a son propre comportement de cache.

La mise en cache négative à ce niveau peut faire paraître une seule machine « possédée » tandis que d’autres fonctionnent. C’est une excellente manière de perdre 45 minutes à blâmer le routage.

2) Résolveurs récursifs (le vrai cache)

C’est là que la mise en cache négative fait le plus mal, car un résolveur récursif sert des populations entières : réseaux de bureau, VPCs, clusters et utilisateurs VPN.

Les résolveurs récursifs typiquement :

Mettront en cache les réponses négatives avec un TTL
Peuvent « servir expiré » dans certaines conditions (généralement pour les réponses positives, mais le comportement varie)
Ont des boutons de politique pour TTL maximum/minimum, y compris des plafonds pour les TTL négatifs

3) Caches applicatifs et comportement des runtimes

Même si le DNS est « corrigé », l’application peut continuer d’échouer parce qu’elle a mis en cache le résultat négatif.

Coupables fréquents :

Java peut mettre en cache des recherches négatives ; les valeurs par défaut dépendent des paramètres de sécurité et de la version de la JVM.
Go peut utiliser le résolveur cgo ou le résolveur Go pur selon la compilation/exécution ; le cache dans le runtime est généralement minimal, mais votre appli ou des sidecars peuvent mettre en cache.
Envoy / maillages de services peuvent mettre en cache les résultats DNS pour la découverte de clusters.

4) Middleboxes et DNS « sécuritaires »

Certaines appliances de filtrage DNS d’entreprise renvoient NXDOMAIN (ou des IP de sinkhole) pour des domaines bloqués et mettent ces réponses en cache agressivement. Cela peut se heurter à des modèles de noms internes et causer… des incidents créatifs.

Blague sèche #2 : L’avantage de la mise en cache négative, c’est que c’est la seule partie du DNS qui ne ment jamais — si elle dit « non », ça veut dire « non, pendant les 3600 prochaines secondes ».

Trois mini-récits du monde corporate (que vous reconnaîtrez)

Mini-récit #1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait un playbook DNS propre : définir des TTL faibles pour les services, automatiser la création d’enregistrements et utiliser des health checks pour basculer le trafic. Une nouvelle équipe a livré une API gateway interne et a décidé de créer des noms DNS par locataire à la demande : tenant-id.api.internal.

L’hypothèse erronée était simple : « Si l’enregistrement n’existe pas, les clients réessaieront plus tard et ça fonctionnera une fois qu’on l’aura créé. » Dans leur tête, le DNS se comportait comme une base de données finalement consistante avec une convergence rapide.

En réalité, la première requête a eu lieu avant que l’automatisation ne soit terminée. Le résolveur récursif a renvoyé NXDOMAIN. Cette réponse portait un SOA avec un TTL négatif élevé. Maintenant le résolveur pouvait continuer à dire à tout le monde « n’existe pas » pendant longtemps, même après que l’enregistrement ait été créé correctement.

Les symptômes de l’incident étaient étranges : seuls les nouveaux locataires échouaient, et seulement pour une tranche d’utilisateurs. Les locataires existants allaient bien. La gateway allait bien. La zone autoritative semblait correcte. L’équipe a fait tourner les pods et redémarré les services, parce que c’est ce que l’on fait quand on est en train de perdre et qu’il est tard.

La correction n’a pas été héroïque : réduire le TTL de mise en cache négative de la zone, ajouter une étape de « préchauffage » qui crée l’enregistrement avant qu’un client puisse tenter la résolution, et à court terme vider les caches sur les recursors de l’entreprise. La leçon est restée : une défaillance DNS est un état mis en cache, pas une erreur transitoire.

Mini-récit #2 : L’optimisation qui s’est retournée contre eux

Une autre organisation faisait tourner des résolveurs récursifs très sollicités et voyait un taux élevé de requêtes pour des noms aléatoires inexistants — fautes de frappe, télémetrie, clients cassés, le bruit de fond habituel. Un ingénieur a décidé « d’optimiser » en augmentant significativement les plafonds de TTL négatif et en mettant en cache NXDOMAIN plus longtemps. Ça a marché : le volume de requêtes en amont a chuté, le CPU était excellent, et tout le monde a discrètement applaudi parce que les ingénieurs DNS applaudissent peu.

Puis ils ont fait un rebranding. Nouveaux hostnames, nouveaux sous-domaines, beaucoup de changements DNS pilotés par le marketing. La zone autoritative était prête. Les recursors étaient prêts. Mais une grande partie de l’entreprise avait déjà essayé de résoudre certains de ces nouveaux noms pendant les tests pré-launch, quand les enregistrements n’étaient pas encore en place.

Ces NXDOMAINs étaient maintenant mis en cache pour longtemps à cause de « l’optimisation ». Le jour du lancement est arrivé. Certains utilisateurs étaient corrects, d’autres obtenaient des erreurs dures. Le support a vu un déploiement instable. Les SREs voyaient « DNS est correct ». Les deux avaient techniquement raison. L’incident a duré aussi longtemps que les caches négatifs.

Ils ont annulé le plafond de TTL négatif, mais cela n’a pas annulé les échecs déjà mis en cache. Ils ont dû vider les caches et attendre. Le retour de bâton n’était pas seulement le réglage — c’était l’absence de politique : la mise en cache négative est une décision de fiabilité, pas un réglage de performance.

Mini-récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une fintech avait une règle qui agaçait les équipes produit : « Aucun nom DNS ne peut être référencé par du code en production tant qu’il ne se résout pas correctement depuis au moins deux résolveurs récursifs indépendants. » Ça semblait bureaucratique. Ça l’était. Ça a aussi évité une classe d’incident très spécifique.

Ils migraient un endpoint de callback de paiement vers une nouvelle région. Le plan de migration incluait de créer callback.payments.example en CNAME vers un nom régional, puis de basculer pendant la maintenance. Ils ont pré-créé l’enregistrement des jours à l’avance et l’ont vérifié depuis (1) leurs propres recursors et (2) une pile de résolveurs séparée utilisée pour le monitoring.

Pendant la fenêtre de changement, un ingénieur a accidentellement appliqué une mise à jour de fichier de zone manquante cet enregistrement. L’autoritatif a commencé à renvoyer NXDOMAIN. Le monitoring l’a détecté en quelques minutes parce qu’il vérifiait depuis plusieurs résolveurs et comparait avec les réponses attendues. Ils ont rapidement reverté la zone.

Voici ce qui a compté : parce que l’enregistrement avait existé et été stable pendant des jours, les caches contenaient des entrées positives, pas négatives. La fenêtre pendant laquelle les clients ont observé NXDOMAIN a été courte, et beaucoup de clients ne l’ont même pas vue. La pratique ennuyeuse — pré-créer, vérifier, monitorer depuis plusieurs points — a transformé un incident potentiel d’une heure en un court clignotement.

Tactique de diagnostic rapide

Quand vous suspectez la mise en cache négative, vous courez contre deux horloges : celle du cache, et celle de la patience du métier. Ne vidangez pas au hasard. Prouvez d’où vient la mauvaise réponse.

Première étape : identifiez la nature exacte de l’échec

Est-ce NXDOMAIN ? Le nom n’existe pas (mis en cache durement).
Est-ce NODATA ? Le nom existe, mais le type manque (fréquent pour AAAA).
Est-ce SERVFAIL/timeouts ? Pas une mise en cache négative ; généralement DNSSEC, atteignabilité ou problèmes en amont.

Deuxième étape : comparez les réponses depuis trois endroits

Serveur de noms autoritatif directement (contournez les caches).
Votre résolveur récursif normal (celui que les clients utilisent réellement).
Un résolveur « propre » connu (une autre pile récursive sous votre contrôle, ou un résolveur de test dans un segment réseau différent).

Troisième étape : extrayez le TTL négatif et décidez

Si le TTL négatif est petit (secondes à quelques minutes) : attendez, mais continuez à prouver l’amélioration.
Si le TTL négatif est grand (dizaines de minutes à heures) : corrigez les paramètres SOA de TTL négatif à long terme, et videz les caches récursifs à court terme si vous les contrôlez.
Si seuls certains clients échouent : suspectez une couche de cache locale (node-local DNS, systemd-resolved, JVM), pas la zone autoritative.

Quatrième étape : vérifiez le split-horizon et le forwarding conditionnel

« Marche sur VPN, échoue hors VPN » ou « marche dans un VPC, échoue dans un autre » signifie souvent que des résolveurs différents obtiennent des vérités différentes. La mise en cache négative fige ensuite ces vérités différentes plus longtemps que prévu.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches supposent des outils Linux. Si vous exécutez des résolveurs dans des conteneurs ou appliances, la logique est la même : interroger, comparer, extraire le TTL, agir.

Task 1: Confirm the symptom with `dig` against the default resolver

cr0x@server:~$ dig api.example.internal A

; <<>> DiG 9.18.24 <<>> api.example.internal A
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34219
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1800  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

;; Query time: 12 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:01:22 UTC 2026
;; MSG SIZE  rcvd: 132

Ce que cela signifie : Le statut est NXDOMAIN. Le SOA est affiché avec un TTL de 1800 secondes. C’est un indice fort que la mise en cache négative est de 30 minutes.

Décision : Ne redéployez pas l’application tout de suite. Vérifiez d’abord la vérité autoritative et confirmez que la politique de TTL négatif est la cause.

Task 2: Query the authoritative server directly (bypass recursion)

cr0x@server:~$ dig @192.0.2.53 api.example.internal A +norecurse

; <<>> DiG 9.18.24 <<>> @192.0.2.53 api.example.internal A +norecurse
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 1201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.internal. 60 IN A 198.51.100.20

;; Query time: 3 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Tue Feb  4 10:01:31 UTC 2026
;; MSG SIZE  rcvd: 62

Ce que cela signifie : L’autoritatif dit que l’enregistrement existe et est correct (NOERROR, drapeau aa, réponse présente).

Décision : C’est presque certainement du NXDOMAIN mis en cache dans des couches récursives. Votre zone est correcte ; ce sont vos caches qui posent problème.

Task 3: Ask the recursive resolver and inspect authority SOA TTL

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +noall +answer +authority +comments

;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54530
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1742  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Ce que cela signifie : Le TTL est maintenant 1742 secondes, en décrémentation. C’est un état négatif mis en cache qui décroît en temps réel.

Décision : Si vous ne pouvez pas vider, vous pouvez au moins prévoir quand cela s’auto-réparera (dans ~29 minutes depuis le remplissage du cache initial).

Task 4: Confirm whether the issue is type-specific (NODATA for AAAA)

cr0x@server:~$ dig @10.10.0.53 www.example.internal AAAA

; <<>> DiG 9.18.24 <<>> @10.10.0.53 www.example.internal AAAA
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 7711
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  900  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Ce que cela signifie : NOERROR avec une réponse vide peut être mis en cache comme « pas d’AAAA ». Cela peut casser des clients qui préfèrent IPv6 d’abord (Happy Eyeballs aide, mais pas toujours).

Décision : Décidez si vous devez publier des enregistrements AAAA ou ajuster le comportement des clients. Ne considérez pas ça comme « DNS OK ». C’est une vraie négative mise en cache.

Task 5: Use `dig +trace` to see where denial happens

cr0x@server:~$ dig +trace api.example.internal A

; <<>> DiG 9.18.24 <<>> +trace api.example.internal A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

example.internal. 172800 IN NS ns1.example.internal.
example.internal. 172800 IN NS ns2.example.internal.
;; Received 151 bytes from 198.41.0.4#53(a.root-servers.net) in 17 ms

api.example.internal. 60 IN A 198.51.100.20
;; Received 62 bytes from 192.0.2.53#53(ns1.example.internal) in 4 ms

Ce que cela signifie : Le chemin autoritatif renvoie l’enregistrement correct. Si des clients voient NXDOMAIN, c’est du cache ou du split-horizon, pas une délégation manquante.

Décision : Concentrez-vous sur les recursors et intermédiaires. Arrêtez d’éditer les fichiers de zone « au cas où ».

Task 6: Check what resolver your host is using

cr0x@server:~$ resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: example.internal

Ce que cela signifie : L’hôte utilise le mode stub de systemd-resolved. Il y a un cache local plus des recursors en amont.

Décision : Si seul cet hôte échoue, videz le cache local. Si beaucoup d’hôtes échouent, vider un seul hôte n’aidera pas.

Task 7: Flush `systemd-resolved` cache (host-level)

cr0x@server:~$ sudo resolvectl flush-caches

Ce que cela signifie : L’absence de sortie est normale. Cela ne garantit pas que les caches en amont sont effacés.

Décision : Testez à nouveau avec dig. Si NXDOMAIN persiste, c’est le cache récursif en amont, pas le cache de l’hôte.

Task 8: Check if `nscd` is caching hosts lookups

cr0x@server:~$ systemctl is-active nscd
inactive

Ce que cela signifie : nscd n’est pas le coupable sur cet hôte.

Décision : Ne perdez pas de temps à le redémarrer. Passez à autre chose.

Task 9: Inspect Unbound’s negative caching related settings

cr0x@server:~$ sudo unbound-control get_option neg-cache-size
neg-cache-size: 4m

Ce que cela signifie : Unbound alloue de l’espace pour le cache négatif. La taille n’est pas un TTL, mais cela confirme que la mise en cache négative est en jeu.

Décision : Si vous manquez de mémoire et que des évictions ont lieu, vous pouvez voir un comportement incohérent. Sinon, procédez à la vidange ou à l’ajustement des plafonds.

Task 10: Flush a single name from Unbound (surgical, not napalm)

cr0x@server:~$ sudo unbound-control flush api.example.internal
ok

Ce que cela signifie : L’entrée mise en cache pour ce nom est supprimée d’Unbound.

Décision : Requêtez de nouveau. Si la réponse est NOERROR maintenant, vous avez prouvé qu’un NXDOMAIN mis en cache bloquait la résolution. Envisagez de vider l’ensemble du sous-arbre pertinent si plusieurs noms sont affectés.

Task 11: Flush a name from BIND (if you run named)

cr0x@server:~$ sudo rndc flushname api.example.internal

Ce que cela signifie : L’absence de sortie signifie généralement succès. Certaines builds l’enregistrent plutôt que de l’afficher.

Décision : Vérifiez immédiatement avec dig via ce résolveur. Si c’est encore NXDOMAIN, le cache est peut-être ailleurs (forwarder, node-local, runtime client).

Task 12: Find negative TTL policy in a BIND zone SOA

cr0x@server:~$ dig @192.0.2.53 example.internal SOA +noall +answer

example.internal. 300 IN SOA ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Ce que cela signifie : Le dernier champ (1800) est couramment utilisé comme TTL de mise en cache négative (selon les sémantiques de RFC 2308, dépend de l’implémentation). Le TTL propre du SOA est 300 ici, mais le champ « minimum » est 1800.

Décision : Si vous avez besoin d’une récupération plus rapide des erreurs et d’une création de noms rapide, baissez ce minimum/TTL négatif. Ne le mettez pas à 0 à moins d’aimer les tempêtes de requêtes contre vos serveurs autoritatifs.

Task 13: Validate what your client actually sees via `getent`

cr0x@server:~$ getent ahostsv4 api.example.internal
198.51.100.20   STREAM api.example.internal
198.51.100.20   DGRAM
198.51.100.20   RAW

Ce que cela signifie : Le chemin libc résout correctement. Si dig échoue mais getent fonctionne (ou vice-versa), vous avez peut-être un comportement DNS split ou des chemins de résolveur différents (stub vs direct).

Décision : Déboguez le chemin que votre application utilise, pas celui que vous préférez. Beaucoup d’incidents sont « marche avec dig » alors que l’appli utilise autre chose.

Task 14: Check whether Kubernetes CoreDNS is caching negatives too long

cr0x@server:~$ kubectl -n kube-system get configmap coredns -o yaml | sed -n '1,120p'
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 10.10.0.53 10.10.0.54
        cache 30
        loop
        reload
        loadbalance
    }

Ce que cela signifie : Le plugin cache 30 met en cache les réponses pendant 30 secondes par comportement par défaut. Selon la configuration, les négatives peuvent aussi être mises en cache. Votre recursor upstream peut quand même conserver NXDOMAIN beaucoup plus longtemps.

Décision : Si le cluster est la population affectée, ajustez délibérément la mise en cache de CoreDNS et assurez-vous que les plafonds de TTL négatif en amont s’alignent sur les besoins de discovery des services.

Task 15: Observe whether a forwarder is returning cached NXDOMAIN

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +stats

; <<>> DiG 9.18.24 <<>> @10.10.0.53 api.example.internal A +stats
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32602
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; Query time: 1 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:02:01 UTC 2026
;; MSG SIZE  rcvd: 132

Ce que cela signifie : Un temps de réponse de 1 ms suggère fortement que c’était servi depuis le cache, pas récupéré depuis les serveurs autoritatifs.

Décision : Vous avez besoin de gestion de cache (vider / plafonner le TTL) plus que d’un simple « réessayer ».

Erreurs courantes : symptômes → cause racine → correction

1) « Nous avons créé l’enregistrement mais les utilisateurs obtiennent encore NXDOMAIN »

Symptômes : L’autoritatif montre l’enregistrement ; les clients échouent encore avec NXDOMAIN ; les échecs disparaissent lentement sur des dizaines de minutes.

Cause racine : Les résolveurs récursifs ont mis en cache NXDOMAIN auparavant ; le TTL négatif dérivé du SOA est long.

Correction : Baissez le TTL négatif dans la zone (champ minimum/TTL négatif du SOA), videz les caches que vous contrôlez et pré-créez les enregistrements avant que des clients puissent les interroger.

2) « Seuls les clients IPv6 échouent » (ou seulement certaines bibliothèques)

Symptômes : Les recherches A fonctionnent ; les recherches AAAA renvoient vide ; certains clients expirent ou se comportent bizarrement.

Cause racine : NODATA pour AAAA est mis en cache ; le client préfère IPv6 ; l’application ne retombe pas proprement.

Correction : Publiez des AAAA si approprié, ou ajustez le comportement client ; envisagez de réduire la mise en cache négative pour les NODATA liés à AAAA dans la politique des résolveurs si cela gêne les déploiements.

3) « Ça marche sur mon laptop, ça échoue au datacenter »

Symptômes : La même requête donne des réponses différentes selon le réseau.

Cause racine : DNS split-horizon, forwarding conditionnel, ou piles de résolveurs récursifs différentes avec des états négatifs mis en cache différents.

Correction : Identifiez quel résolveur chaque environnement utilise ; comparez directement ; unifiez la politique ; videz le résolveur population spécifique qui est erroné.

4) « Redémarrer les pods l’a réparé… brièvement »

Symptômes : L’appli fonctionne après redémarrage, puis échoue de nouveau ; ou différents pods ont des comportements différents.

Cause racine : Les caches node-local diffèrent ; certains nœuds frappent un NXDOMAIN mis en cache ; d’autres non. Les redémarrages changent le nœud d’accueil.

Correction : Corrigez au niveau du résolveur (cache DNS node-local / CoreDNS / recursor upstream). N’utilisez pas les redémarrages pour invalider un cache.

5) « On a mis des TTL bas, pourquoi c’est encore cassé ? »

Symptômes : Les TTL positifs sont bas (comme 60s), mais NXDOMAIN persiste bien plus longtemps.

Cause racine : Le TTL négatif n’est pas le TTL de vos enregistrements. Il est dérivé du SOA et des plafonds de politique des résolveurs.

Correction : Auditez les champs SOA et les plafonds de TTL négatif des résolveurs. Traitez le TTL négatif comme un contrôle SLO de première classe.

6) « DNSSEC a empiré les choses »

Symptômes : Après activation de DNSSEC, les réponses négatives persistent ou SERVFAIL apparaît, et la vidange semble inefficace.

Cause racine : Les résolveurs validant DNSSEC mettent en cache le déni d’existence authentifié de manière très confiante ; en plus une mauvaise configuration peut mener à SERVFAIL (pas NXDOMAIN).

Correction : Séparez NXDOMAIN de SERVFAIL. Pour SERVFAIL, validez la chaîne DNSSEC et les signatures. Pour NXDOMAIN, ajustez la politique de TTL négatif et la stratégie de vidange de cache.

Listes de contrôle / plan pas à pas

Checklist : avant de créer de nouveaux hostnames en production

Fixez un TTL de mise en cache négative raisonnable pour la zone (souvent 30–300 secondes pour les zones internes à évolution rapide ; plus long pour les zones publiques stables).
Pré-créez les noms (ou utilisez des wildcards avec précaution) avant qu’un client puisse tenter la résolution.
Vérifiez depuis au moins deux résolveurs récursifs (stacks différents ou segments réseau différents).
Vérifiez explicitement le comportement pour A et AAAA (même si vous « n’utilisez pas IPv6 »).
Documentez comment vider les caches dans votre flotte de résolveurs, et testez que cela fonctionne.

Checklist : pendant un incident où « DNS est corrigé mais toujours cassé »

Confirmez le type d’échec : NXDOMAIN vs NODATA vs SERVFAIL.
Interrogez l’autoritatif directement avec +norecurse.
Interrogez le résolveur récursif que vos clients utilisent ; extrayez le TTL restant depuis la ligne SOA.
Vérifiez si le temps de réponse suggère du cache (1–2ms) vs une requête en amont (10ms+).
Videz le nom spécifique sur le résolveur récursif si vous le contrôlez ; retestez.
Si vous ne le contrôlez pas, basculez temporairement les clients vers un autre résolveur (dernier recours, mais parfois le seul levier).
Après restauration, réduisez le TTL négatif si cela a prolongé la panne.

Plan pas à pas : dimensionner la mise en cache négative sans surcharger vos autoritatifs

Inventoriez les zones et catégorisez-les : publiques stables, internes stables, internes dynamiques (service discovery, noms éphémères).
Mesurez les taux de NXDOMAIN sur les recursors et serveurs autoritatifs. Un volume élevé de NXDOMAIN suggère fautes de frappe, scans ou clients cassés.
Définissez des cibles de TTL négatif par catégorie :
- Zones publiques stables : des TTL plus longs peuvent convenir.
- Zones internes dynamiques : des TTL négatifs courts valent généralement le coût.
Appliquez des plafonds côté résolveur pour qu’un mauvais SOA n’impose pas une panne d’une heure à tout le monde.
Testez la capacité autoritative si vous réduisez drastiquement les TTL négatifs. Moins de NXDOMAIN mis en cache signifie plus de requêtes en amont.
Déployez progressivement sur la flotte de résolveurs ; surveillez le volume de requêtes, la latence et les SERVFAIL.

FAQ

1) La mise en cache négative, c’est la même chose que la « propagation DNS » ?

Non. « Propagation » est un terme populaire. Ce qui se passe réellement, c’est que les caches respectent les TTL — positifs et négatifs — à travers plusieurs couches de résolveurs.

2) Qu’est-ce qui contrôle la durée de mise en cache de NXDOMAIN ?

Typiquement le SOA de la zone (sémantiques du TTL négatif) plus les plafonds ou overrides sur les résolveurs récursifs. Certains résolveurs appliquent aussi des politiques minimum/maximum.

3) Si je mets le TTL de mon enregistrement à 60 secondes, NXDOMAIN se mettra-t-il en cache 60 secondes aussi ?

Non. Le TTL d’enregistrement affecte les réponses positives. La mise en cache de NXDOMAIN est régie par le TTL négatif, généralement dérivé du SOA.

4) Puis-je simplement fixer le TTL négatif à 0 partout ?

Vous le pouvez, mais vous en paierez le coût en charge de requêtes accrues et potentiellement en DoS auto-infligé de vos serveurs autoritatifs. Pour les zones internes dynamiques, une petite valeur (pas zéro) est en général le compromis.

5) Comment savoir si je vois un NXDOMAIN mis en cache vs un NXDOMAIN autoritatif ?

Interrogez directement l’autoritatif avec dig @auth +norecurse. Si l’autoritatif dit NOERROR mais le récursif dit NXDOMAIN, c’est du cache ou du split-horizon. Surveillez aussi le compte à rebours du TTL dans la ligne SOA lors de requêtes répétées.

6) Pourquoi seuls certains utilisateurs voient l’échec ?

Parce que différents utilisateurs interrogent différents résolveurs, ou différents caches à différents niveaux. Certains ont mis en cache l’ancien échec ; d’autres n’ont pas interrogé pendant la fenêtre mauvaise.

7) La vidange des caches résout-elle toujours immédiatement le problème ?

Seulement si vous videz le cache qui contient la mauvaise entrée et si les clients utilisent effectivement ce résolveur. Vider le cache d’un laptop ne réparera pas un cache récursif d’entreprise en amont.

8) Qu’en est-il du cache DNS des navigateurs ?

Les navigateurs peuvent mettre en cache des résultats DNS indirectement via la réutilisation de connexions et des caches internes, mais le problème opérationnel majeur reste généralement la mise en cache côté résolveur récursif et le cache du runtime applicatif.

9) Comment DNSSEC affecte-t-il la mise en cache négative ?

DNSSEC peut rendre les réponses négatives vérifiables (déni d’existence authentifié), ce qui augmente la confiance dans la mise en cache. Il introduit aussi des modes défaillants (SERVFAIL) quand la validation échoue — différent de NXDOMAIN.

10) Quelle est la façon la plus sûre de déployer un nouveau hostname critique ?

Pré-créez l’enregistrement longtemps à l’avance, vérifiez depuis plusieurs résolveurs récursifs, gardez le TTL négatif court dans cette zone, et surveillez la résolution en continu.

Prochaines étapes à faire cette semaine

La mise en cache négative n’est pas un méchant. C’est un levier. Si vous ne le définissez pas intentionnellement, il sera défini pour vous — par des valeurs par défaut, par l’héritage et par la dernière personne qui a « optimisé le DNS ».

Faites ces trois choses

Auditez vos TTL négatifs SOA pour les zones utilisées par des services dynamiques. Si le chiffre se compte en heures, vous choisissez des pannes longues.
Ajoutez un panneau au dashboard : taux de NXDOMAIN et principaux noms NXDOMAIN sur vos recursors. Vous ne pouvez pas gérer ce que vous ne voyez pas, et les pics de NXDOMAIN sont souvent la première fumée.
Rédigez un runbook de vidange de cache pour chaque couche de résolveur que vous opérez (systemd-resolved, node-local, CoreDNS, Unbound/BIND). Incluez les commandes de vérification et les résultats attendus.

Si vous voulez une règle opérationnelle simple : gardez la mise en cache négative courte là où les noms naissent et meurent rapidement, et plus longue là où l’espace de noms est stable. Ce n’est pas de l’idéologie. C’est adapter le comportement du cache à la façon dont votre entreprise publie des changements.