Résolveurs DNS : pourquoi la mise en cache aggrave les pannes (et comment la maîtriser)

Qui met réellement en cache le DNS (spoiler : tout le monde)

« La mise en cache DNS » n’est pas un seul cache. C’est une pile de caches, chacun avec ses propres règles, bugs et opinions. Quand votre service change d’adresse ou
que vos serveurs faisant autorité dérapent, ces couches ne tombent pas ensemble. Elles échouent de façon échelonnée, spécifique à l’utilisateur et à la géographie,
rendant les timelines d’incident digne d’une œuvre d’art moderne.

Les couches qui mettent en cache les réponses DNS

• Caches au niveau applicatif : navigateurs, résolveurs JVM, runtimes de langage et bibliothèques qui « mémorisent » les réponses.
• Résolveur stub de l’OS : ce que votre appli appelle. Il peut mettre en cache (selon la plateforme et la configuration).
• Démon de cache local : systemd-resolved, dnsmasq, nscd, Unbound en mode « local », etc.
• Caches node-local / sidecar : courants dans Kubernetes et les meshes pour réduire la latence et la charge.
• Résolveurs récursifs : résolveurs d’ISP, d’entreprises, résolveurs publics. Ce sont de gros caches partagés.
• Transferts/forwarders : les réseaux d’entreprise chaînent souvent des résolveurs (bureau distant → siège → upstream).
• Serveurs faisant autorité : pas des « caches », mais ils influencent le cache via le TTL, les valeurs SOA et le comportement des réponses.
• Middleboxes : oui, certains dispositifs de « sécurité » manipulent et cachent le DNS. Les paquets ne témoigneront jamais.

Quand quelqu’un dit « le TTL est 60 secondes », vous devriez répondre : « À quelle couche, dans quel mode de panne, et avec quel logiciel résolveur ? »
La bonne réponse est généralement un long soupir.

Pourquoi la mise en cache amplifie les pannes

La mise en cache DNS est un multiplicateur de force. Elle multiplie la fiabilité quand les réponses sont correctes et stables. Elle multiplie la douleur quand une réponse est fausse,
absente ou temporairement inaccessible. L’essentiel est que les caches rendent votre système étatful à travers Internet. Vous pouvez rollback du code en minutes ;
vous ne pouvez pas revenir en arrière sur un NXDOMAIN mis en cache chez des résolveurs récursifs que vous ne contrôlez pas.

Mode de panne n°1 : des mauvaises réponses persistent

Publiez un A record erroné (IP mal tapée, endpoint obsolète, mauvaise région), et vous avez créé un jeton de panne distribué. Chaque résolveur récursif
qui le voit peut le conserver jusqu’à l’expiration du TTL. Votre correction peut être instantanée au niveau autoritaire, mais le monde tourne maintenant avec un état mis en cache.

Mode de panne n°2 : timeouts et SERVFAIL deviennent « collants »

Certains résolveurs mettent en cache les échecs, ou du moins se comportent comme tels en limitant les nouvelles tentatives, en marquant des serveurs comme défaillants, ou en préférant un NS en raison
de latences passées. Lors d’un incident autoritaire, les recursors peuvent décider qu’un de vos serveurs de noms est « mauvais » et l’éviter longtemps après son retour en santé.

Mode de panne n°3 : le cache négatif rend la récupération plus lente que la panne

Supprimez un enregistrement (ou s’il disparaît suite à un mauvais déploiement), et les résolveurs peuvent mettre en cache « n’existe pas » (NXDOMAIN) basé sur le SOA de la zone.
Ce TTL négatif peut durer des minutes à des heures. Donc même après la restauration de l’enregistrement, les clients continuent de croire au vide.

Blague n°1 : le DNS, c’est comme une rumeur : une fois mise en cache, la correction ne voyage jamais aussi vite que le scandale.

Mode de panne n°4 : pics de charge dus aux « cache stampedes »

Quand le TTL d’un enregistrement populaire expire à peu près en même temps chez beaucoup de résolveurs, vous obtenez une rafale de cache misses. Si vos serveurs faisant autorité
sont déjà sous pression, cette rafale peut les pousser de « lents » à « hors service », générant plus de misses et d’autres rafales. C’est une boucle de rétroaction.
Certains logiciels de résolveur proposent du préfetch et du serve-stale pour réduire cela, mais ce sont des réglages délicats.

Le TTL n’est pas une promesse : réalités gênantes

Le TTL est le champ « mettre en cache pendant ce nombre de secondes » dans un enregistrement DNS. Les opérateurs le traitent comme un contrat. Ce n’en est pas un. C’est une suggestion, et différentes couches
l’interprètent selon leur politique.

Moyens courants par lesquels le TTL est « ajusté » en pratique

• Application d’un TTL minimum : certains résolveurs d’entreprise et publics imposent un plancher (pour la performance et la résistance aux abus).
• Application d’un TTL maximum : certains imposent un plafond (pour éviter des caches qui durent des jours).
• Caches locaux ignorant les TTL bas : certains stub resolvers et apps conservent les réponses plus longtemps que le TTL.
• Réutilisation de connexion et pool d’applications : les applications peuvent ne résoudre qu’au démarrage, créant de fait un TTL infini jusqu’au redémarrage.
• Happy Eyeballs et logique de basculement : les clients peuvent choisir une famille d’adresses (A vs AAAA) et s’y tenir même après un changement DNS.
• Mémoire de sélection de serveur résolveur : les résolveurs récursifs suivent quels serveurs faisant autorité étaient réactifs et les préfèrent.

Si vous voulez un basculement basé sur DNS, traitez-le comme un problème de systèmes distribués, pas comme un interrupteur magique. Le DNS peut contourner les dégâts,
mais il ne fournit pas une convergence synchronisée. Concevez pour « un pourcentage de clients sera erroné pendant un certain temps ».

Une ligne directrice à garder sur un post‑it est une idée paraphrasée attribuée à Werner Vogels : Tout échoue, tout le temps ; concevez en conséquence.
Ce n’est pas une citation DNS, mais c’est dans le DNS que cette philosophie est mise à l’épreuve par la réalité.

Cache négatif : quand « introuvable » persiste

Le cache NXDOMAIN est le prolongeur d’incident le moins apprécié. Vous pensez « nous avons réparé l’enregistrement ». Vos clients continuent d’obtenir « hôte introuvable ».
Pourquoi ? Parce que « introuvable » est mis en cache.

Comment fonctionne le cache négatif

Lorsqu’un résolveur reçoit NXDOMAIN (nom inexistant) ou NODATA (le nom existe mais pas ce type), il peut mettre en cache la réponse négative.
Le TTL pour ce cache est dérivé de l’enregistrement SOA de la zone, spécifiquement du champ SOA MINIMUM (historiquement) et/ou du comportement du TTL SOA tel qu’interprété par les normes modernes et les implémentations.
En termes opérationnels : vos paramètres SOA comptent même quand vous ne touchez pas au SOA.

Deux conséquences pratiques

• Un bref enregistrement manquant peut durer. Si votre déploiement supprime accidentellement un A record pendant 30 secondes, les résolveurs peuvent se souvenir de cette
  absence pendant des minutes ou plus.
• Les nouveaux enregistrements « se propagent » lentement si des clients ont demandé trop tôt. Lancer un nouveau sous‑domaine et l’annoncer avant qu’il n’existe est un classique piège : les premières requêtes sèment des caches négatifs.

La solution n’est pas « mettre tout à TTL 0 ». La solution est de contrôler les TTL négatifs, planifier les basculements et utiliser des techniques anti-cache quand c’est nécessaire.

Empilements de résolveurs dans le monde réel (Linux, macOS, Windows, conteneurs)

L’expression « vérifiez /etc/resolv.conf » est l’équivalent SRE de « avez-vous essayé de l’éteindre et de le rallumer ». Ce n’est pas faux ; c’est juste incomplet.
Les systèmes modernes peuvent router le DNS via un stub local (127.0.0.53), un plugin VPN, un agent d’entreprise ou un runtime de conteneur.

Linux : systemd-resolved et compagnie

Beaucoup de distributions utilisent systemd-resolved, qui peut mettre en cache et implémenter du split DNS pour les VPN. /etc/resolv.conf peut pointer vers 127.0.0.53, qui n’est pas
votre résolveur réel ; c’est un stub local qui relaie en amont. Lors du débogage, il faut inspecter à la fois le stub et la configuration upstream.

macOS : mDNSResponder et DNS par interface

macOS garde des réglages DNS par interface. Vous pouvez être « sur le même Wi‑Fi » et avoir pourtant des comportements de résolution différents parce qu’une machine a aussi un profil VPN installé.
Vider les caches aide, mais l’étape la plus importante est de confirmer quels résolveurs sont interrogés.

Windows : service DNS Client et NRPT

Windows met en cache le DNS dans le service DNS Client. Les entreprises utilisent aussi Name Resolution Policy Table (NRPT), surtout avec DirectAccess/VPN,
qui peut orienter certains domaines vers des résolveurs spécifiques. Le débogage nécessite d’examiner la politique, pas seulement le cache.

Conteneurs et Kubernetes : CoreDNS plus une autre couche

Kubernetes ajoute au moins une couche : CoreDNS (ou kube-dns), plus le résolveur du nœud, plus ce que fait l’image du conteneur. Certains clusters ajoutent NodeLocal
DNSCache pour réduire la charge et la latence de CoreDNS. Cela améliore la performance en régime permanent et rend certaines pannes pires en étendant les réponses obsolètes plus près des charges de travail.
Vous échangez la charge contre la staleness. Ce compromis peut valoir le coup, mais il faut le mesurer.

Faits intéressants et contexte historique (ce qui mordra plus tard)

1. Le DNS a remplacé HOSTS.TXT parce qu’un fichier centralisé ne montait pas ; la mise en cache était une fonctionnalité dès le départ, pas une idée secondaire.
2. Le TTL a été conçu pour contrôler la charge de requêtes sur les serveurs faisant autorité ; il n’a pas été conçu pour supporter un basculement rapide.
3. Le cache négatif n’a pas toujours été cohérent ; la standardisation a évolué parce que les résolveurs initiaux se comportaient de façon très différente pour NXDOMAIN.
4. Les résolveurs suivent les serveurs de noms « lames » et les évitent ; c’est bien… jusqu’à ce qu’une perte de paquets transitoire marque votre meilleur NS comme « mauvais ».
5. Certains résolveurs plafonnent les TTL (plancher et plafond) pour des raisons de politique, ce qui rend les calculs de « propagation » peu fiables.
6. Les enregistrements glue peuvent vous bloquer : une délégation mise en cache avec glue peut maintenir les clients sur d’anciennes IP de NS même après correction de la zone.
7. DNSSEC augmente les modes de panne : une chaîne de confiance cassée peut transformer un « ça marche chez moi » en SERVFAIL global, avec mise en cache par dessus.
8. EDNS0 et paquets UDP plus grands ont amélioré les fonctionnalités, mais ont aussi accru la sensibilité aux middleboxes qui laissent tomber des fragments ou bloquent EDNS.
9. Le fallback TCP pour le DNS existe pour une raison ; si votre chemin bloque DNS sur TCP, les grosses réponses peuvent échouer de manière intermittente.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit n°1 : la panne causée par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a planifié une migration « simple » d’une API d’un load balancer à un autre. Le plan : baisser le TTL à 60 secondes, changer l’A record,
surveiller, puis remonter le TTL. Ils ont fait la première partie soigneusement. Ils ont attendu un jour. Ils ont switché pendant une fenêtre calme. Et puis les tickets de support sont arrivés.

Certains clients continuaient de se connecter à l’ancienne IP pendant des heures. L’équipe d’astreinte accusait « la propagation DNS des FAI ». L’équipe réseau accusait le client.
L’équipe applicative accusait l’équipe réseau, parce que c’est ce que font les applications quand elles ont peur.

Le vrai problème était douloureusement banal : une intégration cliente populaire avait été écrite en Java, et le comportement de cache DNS du runtime sur cette flotte était effectivement
« mise en cache pour toujours » sauf configuration contraire. Ces clients résolvaient une seule fois au démarrage puis gardaient l’adresse IP. Changer le TTL n’a rien fait parce que l’app ne
résolvait plus.

La correction n’était pas un changement DNS. La correction fut de communiquer avec les clients : redémarrer le service d’intégration, ou configurer les paramètres TTL du JVM.
En interne, l’entreprise modifia le playbook de cutover pour inclure « les clients peuvent pinner le DNS ; fournir un endpoint alternatif pendant la transition ». Le DNS a fait exactement ce qu’il disait. L’hypothèse ne l’a pas fait.

Mini-récit n°2 : l’optimisation qui s’est retournée contre eux

Une autre société avait CoreDNS sous charge. Pics de latence, timeouts occasionnels, et un flux régulier de plaintes de développeurs qui pensaient que le DNS devrait être invisible.
L’équipe plateforme a ajouté un cache DNS node-local pour réduire le QPS de CoreDNS. Ça a marché. Les graphiques s’amélioraient. L’équipe a célébré en silence, comme font les ingénieurs quand ils ne veulent pas que le destin remarque.

Des semaines plus tard, un fournisseur autoritaire upstream eut une panne partielle. Le comportement attendu aurait été « quelques résolutions échouent vite, les retries récupèrent, et une fois l’upstream guéri tout revient à la normale ».
Ce qui est arrivé fut un incident au ralenti : les caches node-local conservaient des échecs et des réponses intermittentes suffisamment longtemps pour que des pods à travers le cluster voient des résolutions incohérentes bien au‑delà de la durée de la panne upstream.

Le cache node-local a aussi changé la surface de panne du cluster. Avant, les problèmes CoreDNS étaient centralisés et évidents. Après, les pannes devinrent spécifiques aux nœuds. Certains nœuds étaient « OK », d’autres « maudits », et le scheduler y plaçait joyeusement des charges parce que le CPU était disponible.

Le postmortem n’a pas conclu « ne jamais mettre en cache ». Il a conclu « mettre en cache avec une politique explicite de serve-stale, un préfetch explicite, et un moyen de vider ou bypasser rapidement ».
Ils ont ajouté des vérifications de santé, des métriques par instance node-local, et un DaemonSet d’urgence pour redémarrer les caches à l’échelle du cluster. L’optimisation est géniale… jusqu’à ce qu’elle devienne ce que vous ne pouvez plus annuler pendant un incident.

Mini-récit n°3 : la pratique ennuyeuse et correcte qui a sauvé la mise

Une entreprise de paiements opérait des DNS faisant autorité chez deux fournisseurs. Ça sonne sophistiqué, mais la partie intéressante fut leur discipline ennuyeuse : ils lançaient des tests continus depuis
plusieurs réseaux qui interrogeaient les deux fournisseurs directement, validaient les réponses DNSSEC, et comparaient les réponses avec un jeu attendu.

Un après‑midi, la surveillance alerta : les requêtes vers un fournisseur commencèrent à renvoyer SERVFAIL de façon intermittente pour une zone signée. Depuis la plupart des réseaux clients, tout semblait encore correct parce que les caches masquaient le problème. L’entreprise n’a pas reçu de rapports clients parce que la défaillance était jeune et masquée.

L’astreinte DNS n’a pas commencé par vider les caches ou changer les TTL. Ils ont isolé quel ensemble autoritaire se comportait mal, ajusté temporairement la délégation pour favoriser le fournisseur sain, et gardé les TTL stables.
Ils ont aussi mis en pause un déploiement prévu qui aurait introduit de nouveaux enregistrements, car le cache négatif pendant une oscillation DNSSEC est une misère particulière.

L’incident n’est jamais devenu une panne totale. Les clients n’ont rien remarqué. La « pratique ennuyeuse » n’était pas de l’héroïsme ; c’était avoir des tests qui contournent les caches et valident continuellement la source de vérité. Le meilleur incident DNS est celui que vous résolvez pendant que tout le monde pense que tout va bien.

Checklist de diagnostic rapide

Quand on accuse le DNS, votre travail est de déterminer où le mensonge est entré dans le système : données faisant autorité, cache récursif, cache local, ou application.
Vous n’avez pas le temps pour la philosophie. Voici l’ordre qui vous mène rapidement à la cause racine.

Première étape : déterminer si le nom est faux partout ou seulement pour certains clients

• Interrogez directement l’autorité (requêtez les serveurs faisant autorité par nom/IP, en contournant les recursors).
• Interrogez un ou deux recursors publics connus pour voir si la vue en cache diffère.
• Vérifiez le chemin de résolution du client affecté (quel serveur il interroge réellement ?).

Deuxième étape : classer le type de panne

• Mauvaise IP : enregistrement obsolète mis en cache ou publication erronée.
• NXDOMAIN : enregistrement manquant et cache négatif.
• SERVFAIL : DNSSEC, délégation cassée, autoritaire inaccessible, ou politique de résolveur.
• Timeout : chemin réseau, MTU/fragmentation, firewall, ou composant DNS surchargé.
• Intermittent : comportement autoritaire mixte, problèmes anycast, perte de paquets, ou un NS marqué « lame ».

Troisième étape : trouver la couche de cache « collante »

• Cache stub local (systemd-resolved, nscd, dnsmasq).
• Node-local / CoreDNS (Kubernetes).
• Forwarders d’entreprise (les chaînes ajoutent de l’état).
• Résolveurs récursifs (FAI/publics).
• Runtime applicatif (JVM, Go, cache personnalisé).

Quatrième étape : décider d’attendre, vider ou contourner

• Attendre si la valeur mise en cache est correcte mais que vous avez besoin de convergence ; communiquez le temps de rétablissement attendu basé sur le TTL et le comportement des caches.
• Vider si vous contrôlez le résolveur et pouvez le faire en sécurité (et si vous n’allez pas provoquer un stampede).
• Contourner en ajoutant temporairement des enregistrements alternatifs, en ajustant la délégation, ou en utilisant un autre nom d’hôte pendant l’incident.

Tâches pratiques : commandes, sorties et décisions

Ce ne sont pas des commandes « jouets ». Ce sont celles que vous lancez pendant que quelqu’un demande un ETA. Chaque tâche inclut ce que la sortie vous dit et la décision suivante.
Supposons Linux sauf indication contraire.

Task 1: Identify which resolver the host is actually using

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
search corp.example
options edns0 trust-ad

Ce que cela signifie : Cet hôte pointe vers un stub local (127.0.0.53), probablement systemd-resolved.
Décision : Ne supposez pas encore les résolveurs upstream ; inspectez la configuration de systemd-resolved et le comportement du cache ensuite.

Task 2: Inspect systemd-resolved upstream servers and per-link DNS

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Ce que cela signifie : systemd-resolved relaie vers 10.10.0.53/54.
Décision : Si seuls certains hôtes échouent, comparez cette sortie entre machines « bonnes » et « mauvaises ». Les différences expliquent souvent tout.

Task 3: Query a name via the default resolver and observe TTL

cr0x@server:~$ dig api.example.com A +noall +answer +ttlid
api.example.com.  42  IN  A  203.0.113.20

Ce que cela signifie : Vous avez obtenu une réponse avec 42 secondes restantes en cache.
Décision : Si l’IP est erronée, vous regardez un état mis en cache. Ensuite : comparez avec l’autorité et d’autres recursors.

Task 4: Bypass local and query a specific recursive resolver

cr0x@server:~$ dig @1.1.1.1 api.example.com A +noall +answer +ttlid
api.example.com.  60  IN  A  198.51.100.77

Ce que cela signifie : Un résolveur différent renvoie une IP différente (et un TTL frais). C’est un classique « contenu de cache différent ».
Décision : Déterminez quelle réponse est correcte en interrogeant l’autorité. Si l’autorité correspond à l’une, l’autre résolveur est obsolète ou empoisonné.

Task 5: Query authoritative name servers directly (bypassing recursion)

cr0x@server:~$ dig api.example.com A +noall +answer +authority +additional +trace
api.example.com. 300 IN A 198.51.100.77

Ce que cela signifie : L’autorité indique 198.51.100.77 avec TTL 300.
Décision : Le résolveur qui renvoie 203.0.113.20 est obsolète ou suit une vue différente (split-horizon, ancienne zone, ou mauvais forwarding).

Task 6: Check for NXDOMAIN and whether it’s being cached negatively

cr0x@server:~$ dig new.api.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

example.com.  900  IN  SOA  ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 900

Ce que cela signifie : NXDOMAIN, et le SOA montre une fenêtre de cache négatif de 900 secondes (souvent dérivée du MINIMUM du SOA).
Décision : Si vous venez de créer cet enregistrement, vous devrez attendre la fin des caches négatifs ou changer de stratégie (nom temporaire alternatif, ou pré-création avant l’annonce).

Task 7: Confirm whether DNSSEC is turning things into SERVFAIL

cr0x@server:~$ dig api.example.com A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39012
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : Le résolveur a abandonné avec SERVFAIL. Les échecs de validation DNSSEC se présentent souvent ainsi, mais les timeouts upstream aussi.
Décision : Comparez les résultats en utilisant un résolveur avec validation DNSSEC désactivée (en environnement contrôlé) et interrogez l’autorité directement pour la cohérence DS/DNSKEY.

Task 8: Measure authoritative reachability and latency from your network

cr0x@server:~$ dig @ns1.example.com api.example.com A +tries=1 +time=1 +stats
api.example.com. 300 IN A 198.51.100.77
;; Query time: 18 msec
;; SERVER: 192.0.2.53#53(ns1.example.com) (UDP)
;; WHEN: Tue Feb 04 12:02:51 UTC 2026
;; MSG SIZE  rcvd: 56

Ce que cela signifie : L’autorité répond rapidement depuis ici.
Décision : Si des clients ailleurs timeout, vous pouvez avoir des problèmes de routage géographique/anycast, firewall ou sélection de résolveur upstream.

Task 9: Detect MTU/fragmentation issues impacting DNS (EDNS0 size)

cr0x@server:~$ dig dnskey example.com +dnssec +bufsize=4096 +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58807
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : Les grosses réponses UDP fonctionnent depuis cet hôte. Si cela échoue ailleurs mais fonctionne avec un bufsize plus petit ou TCP, vous avez un problème de chemin ou de middlebox.
Décision : Testez avec TCP et/ou un bufsize plus petit ; si TCP marche mais UDP gros échoue, impliquez les équipes réseau avec des captures et des vérifications MTU.

Task 10: Force DNS over TCP to confirm UDP is the problem

cr0x@server:~$ dig dnskey example.com +dnssec +tcp +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4926
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : Le TCP réussit. Si l’UDP échoue de façon intermittente, vous avez probablement des pertes de fragments UDP, des limites de taux, ou des règles stateful bizarres.
Décision : Ajustez les tailles EDNS, validez les règles firewall, et consultez le fournisseur autoritaire ; ne « corrigez » pas ça en augmentant les TTL.

Task 11: Inspect Unbound cache statistics (local resolver)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'total.num.queries|total.num.cachehits|total.num.cachemiss|unwanted'
total.num.queries=184392
total.num.cachehits=151004
total.num.cachemiss=33388
unwanted.queries=219

Ce que cela signifie : Le ratio de hit est élevé ; Unbound fait son travail. « unwanted » peut indiquer des requêtes abandonnées (politique, limites de débit, ou problèmes).
Décision : Si les cache misses grimpent pendant l’incident, vous pouvez voir un stampede ; envisagez préfetch/serve-stale et augmentez la capacité autoritaire.

Task 12: Flush a single name from Unbound (when you control the resolver)

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

Ce que cela signifie : Ce nom est supprimé du cache sur ce résolveur.
Décision : Requêtez de nouveau pour confirmer que les données autoritaires sont maintenant utilisées. Attention : vider à grande échelle peut provoquer une rafale de cache-miss.

Task 13: Verify BIND recursion and cache behavior on a resolver

cr0x@server:~$ sudo rndc status
version: BIND 9.18.18 (Stable Release)
running on server: Linux x86_64
boot time: Tue Feb 04 09:11:03 UTC 2026
last configured: Tue Feb 04 09:12:01 UTC 2026
current serial: 2026020401
number of zones: 104 (104 automatic)
recursive clients: 12/1000/1000
tcp clients: 3/100
server is up and running

Ce que cela signifie : Le résolveur est vivant, pas saturé de clients.
Décision : Si des clients échouent encore, vérifiez les logs de requêtes pour SERVFAIL/timeouts et confirmez la reachabilité upstream et l’état de validation DNSSEC.

Task 14: Check if Kubernetes CoreDNS is erroring or slow

cr0x@server:~$ kubectl -n kube-system logs -l k8s-app=kube-dns --tail=20
[INFO] 10.244.1.18:39976 - 56512 "A IN api.example.com. udp 44 false 512" SERVFAIL qr,rd,ra 44 0.002153s
[INFO] 10.244.2.21:34771 - 22341 "A IN api.example.com. udp 44 false 512" NOERROR qr,rd,ra 60 0.001122s

Ce que cela signifie : SERVFAIL/NOERROR mixte suggère des problèmes upstream ou une validation/reachabilité intermittente, pas un simple « enregistrement manquant ».
Décision : Identifiez vers quel upstream CoreDNS relaie, et testez ce résolveur directement depuis le namespace réseau du nœud.

Task 15: Confirm whether an application is re-resolving or pinning DNS

cr0x@server:~$ sudo strace -f -e trace=network -p 24817 2>&1 | head
connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("203.0.113.20")}, 16) = 0

Ce que cela signifie : Le processus se connecte directement à une IP ; aucun signe d’appels DNS dans cet extrait. Il a peut‑être résolu plus tôt et réutilise.
Décision : Si l’IP est obsolète, redémarrer le process peut « régler » le problème, ce qui est aussi la preuve d’un cache/pinning côté application. La solution long terme est la configuration ou le code.

Task 16: Inspect live socket destinations to spot stale IP usage

cr0x@server:~$ ss -ntp | egrep ':443' | head
ESTAB 0 0 10.0.5.12:53014 203.0.113.20:443 users:(("myclient",pid=24817,fd=12))

Ce que cela signifie : Des connexions actives vont vers 203.0.113.20.
Décision : Si l’autorité pointe maintenant ailleurs, vous avez des connexions pinées ou un DNS obsolète dans une couche. Décidez de drainer, redémarrer ou ajouter un routage temporaire.

Blague n°2 : Vider les caches DNS pendant un incident, c’est comme réarranger les chaises sur un ferry — parfois ça aide, mais mieux vaut savoir où fuit l’eau d’abord.

Erreurs courantes : symptômes → cause racine → correctif

1) « L’autorité est correcte, mais les utilisateurs touchent encore l’ancienne IP »

Symptôme : Certains clients continuent de se connecter aux anciens endpoints longtemps après un changement DNS.

Cause racine : Les résolveurs récursifs ont mis en cache d’anciennes réponses ; des caches locaux existent ; les apps pinnen le DNS au démarrage ou gardent des connexions long‑temps.

Correctif : Planifiez les cutovers avec recouvrement (gardez l’ancien endpoint vivant), raccourcissez le TTL bien en avance, et vérifiez le comportement DNS des runtimes clients. Fournissez des hostnames alternatifs pour la transition.

2) « NXDOMAIN persiste après l’ajout de l’enregistrement »

Symptôme : Nouveau sous‑domaine échoue pendant des minutes/heures ; certains réseaux résolvent, d’autres non.

Cause racine : Cache négatif basé sur le SOA ; des requêtes précoces ont semé des NXDOMAIN dans les caches.

Correctif : Pré-créez les enregistrements avant l’annonce. Ajustez le TTL négatif SOA à une valeur raisonnable. Pour une correction urgente, utilisez un nouveau nom d’hôte (anti-cache) plutôt que d’attendre l’expiration de NXDOMAIN.

3) « SERVFAIL intermittent sur un résolveur, ok sur un autre »

Symptôme : Certains résolveurs renvoient SERVFAIL ; d’autres renvoient NOERROR.

Cause racine : Échec de validation DNSSEC, chaîne DS/DNSKEY cassée, ou reachabilité intermittente des serveurs faisant autorité (un NS inaccessible).

Correctif : Validez la chaîne DNSSEC de bout en bout et confirmez que tous les serveurs faisant autorité répondent de façon cohérente. Si un NS est mauvais, retirez‑le ou réparez‑le ; une autorité partielle est pire que moins de serveurs correctement configurés.

4) « Timeouts seulement pour les grosses réponses »

Symptôme : Les requêtes A/AAAA vont bien, mais DNSKEY/TXT ou certaines réponses timeoutent.

Cause racine : Problèmes EDNS0/fragmentation, MTU inadaptée, middleboxes laissant tomber des fragments UDP ou bloquant le fallback TCP.

Correctif : Testez avec +tcp et ajustez les tailles EDNS. Réparez le chemin réseau. Ne bâclez pas le problème en réduisant la taille des réponses sans comprendre le compromis.

5) « Surprises de split-horizon après ajout d’un VPN »

Symptôme : Les noms internes résolvent mal depuis l’extérieur ou inversement ; seuls les utilisateurs VPN échouent.

Cause racine : Forwarding par domaine / politique de split DNS ; les résolveurs diffèrent selon l’interface ; des agents d’entreprise écrasent les résolveurs.

Correctif : Documentez les domaines en split-horizon, appliquez des réglages de résolveur cohérents, et testez depuis VPN et hors VPN. Assurez‑vous que les zones internes ne fuient pas et que les zones externes sont accessibles.

6) « Baisser le TTL n’a pas aidé notre basculement »

Symptôme : Vous avez réduit le TTL à 30–60 secondes, mais le basculement a quand même pris des heures.

Cause racine : Certains résolveurs imposent un TTL minimum ; certains clients pinnen le DNS ; des caches avaient déjà des réponses plus anciennes avant le changement de TTL.

Correctif : Baissez le TTL plusieurs jours avant les changements planifiés. Testez avec de vrais clients. Utilisez des retries applicatifs et une logique multi-endpoint ; ne comptez pas uniquement sur le DNS pour le basculement.

7) « Nous avons vidé le cache et empiré les choses »

Symptôme : Après avoir vidé des résolveurs, le QPS autoritaire explose et davantage de requêtes timeoutent.

Cause racine : Cache stampede : vous avez transformé votre flotte de résolveurs en générateur synchronisé de misses.

Correctif : Videz de façon chirurgicale (un nom, un niveau de résolveur), étalez les redémarrages, et assurez la capacité autoritaire. Préférez serve-stale/prefetch quand c’est pertinent.

Listes de contrôle / plan pas à pas

Checklist A : Avant une coupure DNS planifiée

1. Baissez le TTL à l’avance (au moins une fenêtre complète du TTL précédent ; souvent 24–48 heures) pour que les caches existants s’épurent.
2. Confirmez les valeurs SOA de cache négatif pour qu’une brève erreur ne dure pas une heure.
3. Gardez les anciens endpoints en vie assez longtemps pour supporter les clients qui pinnen le DNS ou gardent des connexions longues.
4. Testez depuis plusieurs résolveurs (entreprise, publics, mobile) et depuis plusieurs régions.
5. Vérifiez la santé autoritaire et la cohérence entre tous les NS (y compris DNSSEC si activé).
6. Ayez un plan de rollback qui ne repose pas sur le TTL : hostname alternatif, override de routage, ou endpoints dual-stack.

Checklist B : Pendant un incident attribué au DNS

1. Établissez la vérité terrain : interrogez l’autorité directement ; notez les réponses attendues.
2. Comparez les caches : interrogez au moins deux recursors différents ; notez les différences.
3. Identifiez la couche en échec : stub local, cache node-local, forwarder d’entreprise, résolveur public, ou appli.
4. Classez la panne : mauvaise réponse, NXDOMAIN, SERVFAIL, timeout, ou intermittent.
5. Choisissez une mitigation : attendre, vider (chirurgical), bypasser (nom alternatif), ou contourner (préférence de délégation).
6. Communiquez des délais réalistes : incluez les fenêtres de cache négatif et « certains clients pinnen le DNS » dans votre ETA.

Checklist C : Après l’incident (la partie que l’on saute puis répète)

1. Ajoutez une surveillance qui contourne les caches : interrogez l’autorité directement depuis plusieurs réseaux.
2. Suivez les taux d’erreur des résolveurs : SERVFAIL, timeouts, pics de NXDOMAIN, et distributions de latence.
3. Documentez la topologie des résolveurs : quels réseaux utilisent quels résolveurs ; incluez VPN et forwarders de succursales.
4. Standardisez les contrôles de cache : politique serve-stale, préfetch, procédures de vidage, et patterns de redémarrage sûrs.
5. Auditez le comportement DNS des applications : en particulier paramètres JVM, pooling de connexions, et bibliothèques qui cachent.

FAQ

1) Pourquoi mon changement DNS « n’a pas propagé » alors que le TTL était bas ?

Parce que le TTL que vous avez défini ne contrôle que les résolveurs qui le respectent et les clients qui re‑requêtent le DNS. Certains résolveurs appliquent un TTL minimum,
et certaines apps résolvent une fois au démarrage et jamais après. De plus, abaisser le TTL n’aide qu’après que les caches existants se soient vidés ; cela ne réécrit pas le passé.

2) Quelle est la différence entre DNS faisant autorité et résolveurs récursifs ?

Les serveurs faisant autorité hébergent les données de zone (la source de vérité). Les résolveurs récursifs récupèrent ces données pour le compte des clients et les mettent en cache.
Pendant un incident, il faut interroger l’autorité directement pour savoir ce qui « devrait » être vrai, et interroger des résolveurs récursifs pour savoir ce que les clients « pensent » être vrai.

3) Puis‑je mettre le TTL à 0 pour éviter la mise en cache ?

Vous pouvez définir des TTL très bas, mais beaucoup de résolveurs n’honoreront pas 0, et vous augmenterez significativement la charge de requêtes. Les TTL bas ne résolvent pas non plus le pinning côté application
et peuvent provoquer des stampedes. Utilisez des TTL bas de façon tactique pour des cutovers planifiés, pas comme béquille permanente.

4) Qu’est‑ce que le cache négatif et pourquoi m’en soucier ?

Le cache négatif met en cache « ce nom n’existe pas » (NXDOMAIN) ou « pas de données » pour un type donné. C’est important car une brève erreur — comme un enregistrement manquant — peut
persister dans les caches bien après votre rétablissement, ralentissant la récupération plus que la fenêtre d’erreur initiale.

5) Quand dois‑je vider les caches DNS ?

Videz lorsque vous contrôlez le résolveur et que vous êtes sûr que les données faisant autorité sont correctes, et que vous avez besoin d’une convergence plus rapide que le TTL ne le permet.
Faites‑le chirurgicalement (un nom, un niveau) et soyez conscient des stampedes. Vider tout est souvent un incident de performance déguisé en correctif.

6) Comment savoir si SERVFAIL est lié à DNSSEC ?

Comparez le comportement entre des résolveurs au comportement DNSSEC connu, interrogez avec +dnssec, et inspectez la cohérence DS/DNSKEY.
SERVFAIL peut aussi venir de timeouts, donc mesurez la reachabilité et testez avec TCP pour éliminer les problèmes UDP.

7) Pourquoi certains clients fonctionnent et d’autres échouent en même temps ?

Parce qu’ils utilisent des résolveurs différents (FAI vs entreprise vs public), ont des contenus de cache différents, ou sont derrière des politiques réseau différentes (split DNS VPN).
De plus, certains clients gardent des connexions longues et n’ont pas besoin de résoudre à nouveau avant de se reconnecter.

8) Kubernetes aggrave‑t‑il les problèmes DNS ?

Cela peut. Kubernetes ajoute des couches DNS (CoreDNS, cache node-local optionnel), augmente le volume de requêtes, et crée de nouveaux modes de panne où le cache d’un seul nœud devient une panne localisée.
Bien fait, c’est acceptable. Fait à la légère, c’est une boîte mystère distribuée.

9) Dois‑je compter sur le DNS pour le basculement entre régions ?

Utilisez le DNS comme un outil parmi d’autres, pas le seul. Le basculement DNS est finalement consistant et dépendant du client. Associez‑le à des retries applicatifs, un support multi‑endpoints,
et du load balancing vérifié par health checks quand c’est possible. Supposez que certains clients seront erronés pendant un moment et concevez pour que « erroné » reste tolérable.

Conclusion : étapes suivantes pour éviter la récidive

La mise en cache DNS ne « cause » pas les pannes. Elle les préserve, les distribue, et les rend aléatoires. Si vous traitez le DNS comme un simple fichier de configuration,
vous continuerez d’avoir des incidents où la correction est correcte et l’impact client persiste obstinément.

Faites trois choses ce trimestre :

1. Cartographiez votre chemin de résolveur pour chaque environnement majeur (nœuds prod, bureau, VPN, CI, Kubernetes). Notez‑le. Tenez‑le à jour.
2. Construisez des moniteurs contournant le cache qui interrogent les serveurs faisant autorité directement et valident les réponses attendues (DNSSEC inclus si utilisé).
3. Opérationnalisez les changements DNS : baissez le TTL à l’avance, contrôlez les TTL négatifs, planifiez les chevauchements, et traitez le flush de cache comme un scalpel, pas une alarme incendie.

L’objectif n’est pas d’éliminer la mise en cache. L’objectif est de rendre la mise en cache prévisible, observable et ennuyeuse. Ennuyeuse est un compliment en production.