Modifications DNS non visibles : quels caches vider (et lesquels ne pas toucher)
Vous avez mis à jour un enregistrement DNS. Vous avez attendu « quelques minutes ». Votre tableau de bord affiche toujours l’ancienne IP. Quelqu’un sur Slack dit :
« le DNS est en panne encore », et une autre personne suggère de redémarrer des éléments au hasard jusqu’à ce que le graphique redevienne vert.
Voici la réalité : le DNS n’est généralement pas en panne. Votre modification est simplement bloquée derrière un cache spécifique, quelque part
entre votre serveur faisant autorité et les yeux de l’utilisateur. L’astuce consiste à trouver quel cache vous ment,
ne vider que ce qui aide, et laisser le reste tranquille — parce qu’une mauvaise purge peut transformer un léger retard en incident majeur.
Le modèle mental : d’où proviennent réellement les réponses DNS
Quand on parle de « propagation DNS », on imagine souvent un système global unique qui se synchronise lentement. Ce n’est pas ce qui se passe.
Le DNS est une chaîne de délégations et de caches, et chaque maillon peut décider indépendamment de ce qu’il renvoie et pendant combien de temps.
Vous publiez des enregistrements sur un serveur faisant autorité (ou chez un fournisseur). Mais la plupart des clients ne lui parlent jamais.
Ils interrogent un résolveur récursif (souvent votre FAI, le réseau d’entreprise ou un résolveur public), et ce résolveur
met en cache les réponses. Ensuite votre OS peut mettre en cache. Votre navigateur peut mettre en cache. Votre application peut mettre en cache. Votre maillage de services peut faire un cache « utile ».
Votre load balancer peut conserver un mapping en amont obsolète. Et Kubernetes CoreDNS peut avoir sa propre opinion.
Un « changement DNS non visible » est presque toujours l’un de ces cas :
- Vous n’avez pas modifié ce que vous pensez avoir modifié (mauvaise zone, mauvais enregistrement, mauvais nom, mauvaise vue).
- Vous l’avez modifié, mais les TTL disent « pas encore » (y compris la mise en cache négative, qui est plus sournoise).
- Vous l’avez modifié, mais vous testez via un cache (résolveur local, forwarder d’entreprise, navigateur, etc.).
- Vous l’avez modifié, mais différents utilisateurs obtiennent des réponses différentes (DNS géo, EDNS Client Subnet, split‑horizon).
L’objectif n’est pas de « tout vider ». L’objectif est : identifier le cache limitant, puis choisir l’action la plus sûre et la plus petite.
Les systèmes de production récompensent la précision.
Playbook de diagnostic rapide (vérifier 1/2/3)
Si vous êtes en astreinte, vous voulez une voie de 60–180 secondes vers la clarté. Voici l’ordre qui tend à minimiser les dégâts auto‑infligés.
1) Vérifier la vérité autoritaire (bypass des caches)
Interrogez directement les serveurs faisant autorité pour l’enregistrement que vous avez modifié. Si l’autoritatif ne l’affiche pas, arrêtez.
Votre problème n’est pas la « propagation ». Votre problème est la publication.
- Trouvez les enregistrements NS de la zone.
- Interrogez chaque NS directement avec
dig @nsX. - Vérifiez l’enregistrement, le TTL et toute chaîne CNAME.
2) Vérifier le résolveur que vous utilisez réellement sur le chemin défaillant
Si l’autoritatif est correct, testez le résolveur récursif que le client impacté utilise. Cela peut être :
forwarder d’entreprise, résolveur VPC, cache node‑local, ou un résolveur public.
Comparez :
- Section Answer (A/AAAA/CNAME)
- TTL restant (s’il est élevé, vous attendez, ce n’est pas cassé)
- NXDOMAIN vs NOERROR (la mise en cache négative signifie aussi « vous attendez »)
3) Vérifier les caches côté client en dernier (OS, navigateur, app)
Ce n’est qu’après que l’autoritatif et le récursif sont sains que vous attaquez la machine locale. Parce que vider localement coûte peu,
mais c’est aussi une distraction : vous pouvez « le réparer sur votre laptop » pendant que les utilisateurs en production voient toujours des données obsolètes.
Idée paraphrasée de Richard Cook (ingénierie de résilience) : « Le succès et l’échec proviennent des mêmes processus quotidiens. »
La mise en cache DNS est l’un de ces processus. Il fait son travail — jusqu’à ce que vous ayez besoin qu’il arrête de le faire.
Quels caches existent (et de quoi ils sont coupables)
1) Comportement des serveurs faisant autorité (pas un cache, mais souvent accusé)
Vos serveurs faisant autorité servent ce qui est dans le fichier de zone/base de données à l’instant T. S’ils sont erronés :
mauvais enregistrement, mauvaise zone, pas synchronisé, secondaire obsolète, mauvaise vue, ou vous avez édité une UI qui écrit ailleurs que vous croyez.
Un mode de défaillance classique : vous mettez à jour www.example.com mais le trafic utilise en réalité api.example.com
via une chaîne CNAME que vous aviez oubliée.
2) Caches des résolveurs récursifs (le gros morceau)
Les résolveurs récursifs mettent en cache par TTL. C’est le principe. Si vous avez mis un TTL à 3600 hier et modifiez l’enregistrement maintenant,
certains résolveurs conserveront l’ancienne réponse pendant jusqu’à une heure depuis leur dernière interrogation.
Pire : les résolveurs mettent aussi en cache les réponses négatives (NXDOMAIN, NODATA). Si un résolveur a récemment demandé
un enregistrement qui n’existait pas, il peut mettre en cache cette réponse « n’existe pas » basée sur le SOA minimum/TTL négatif de la zone.
Les gens l’oublient, puis jurent que l’internet les fait passer pour des fous.
3) Forwarders et couches DNS d’entreprise (où la vérité est « optimisée »)
Beaucoup de réseaux utilisent une chaîne : client → stub local → forwarder d’entreprise → récursif en amont. Chaque saut peut mettre en cache.
Chaque saut peut aussi réécrire le comportement : filtrage DNS, split‑horizon, forwarding conditionnel, ou appliances « sécurité »
qui font du MITM DNS.
4) Caches du stub resolver OS (systemd-resolved, mDNSResponder, Windows DNS Client)
Les OS modernes mettent souvent en cache les réponses DNS localement pour la performance. C’est généralement un petit cache, mais suffisant
pour faire diverger votre laptop de votre serveur, ce qui suffit à vous faire perdre une après‑midi.
5) Caches au niveau applicatif (Java, Go, comportements glibc, etc.)
Certains runtimes mettent en cache les résultats DNS de façon agressive ou imprévisible. Java a historiquement mis en cache indéfiniment sauf configuration.
Certains clients HTTP poolent les connexions et continuent d’utiliser une vieille IP sans re‑résolution. Ce n’est pas de la mise en cache DNS. C’est la réutilisation de connexion.
Différente erreur, même symptôme : « j’ai changé le DNS et rien n’a changé ».
6) Caches des navigateurs
Les navigateurs gardent leurs propres caches et pré‑résolvent des noms. Ils peuvent aussi maintenir des connexions établies et continuer à parler à l’ancien endpoint même après un changement DNS.
7) CDN / résolveurs en périphérie et fonctionnalités géo
Si vous utilisez DNS géo, routage basé sur la latence, ou EDNS Client Subnet, différents résolveurs récursifs obtiennent des réponses différentes.
Vous pouvez être « correct » à un endroit et « incorrect » à un autre sans aucun bug — juste une politique.
8) DNS Kubernetes (CoreDNS) et caches node‑local
Dans les clusters, le DNS est une dépendance comme une autre. CoreDNS met en cache. Des caches node‑local existent.
Et ensuite votre application peut encore mettre en cache. Si vous déboguez un service qui ne voit pas un nouvel endpoint, vous devez décider
de la couche que vous testez : pod, nœud, ou hors du cluster.
Tâches pratiques : commandes, sorties, décisions (12+)
Voici des tâches réelles que vous pouvez exécuter. Chacune inclut : la commande, ce que signifie une sortie typique, et la décision à prendre.
Utilisez dig quand vous pouvez. nslookup marche, mais il masque des détails dont vous avez souvent besoin (TTL, flags, authority).
Task 1: Find the authoritative nameservers for a zone
cr0x@server:~$ dig +noall +answer example.com NS
example.com. 3600 IN NS ns1.dns-provider.net.
example.com. 3600 IN NS ns2.dns-provider.net.
Ce que ça signifie : Ce sont les enregistrements NS faisant autorité que le monde devrait utiliser.
Décision : Interrogez-les directement ensuite. Si vous ne voyez pas le fournisseur attendu, vous éditez la mauvaise zone ou la délégation est incorrecte.
Task 2: Query authoritative directly (bypass recursive caches)
cr0x@server:~$ dig @ns1.dns-provider.net www.example.com A +noall +answer +authority
www.example.com. 300 IN A 203.0.113.42
example.com. 3600 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Ce que ça signifie : L’autoritatif indique que l’A est 203.0.113.42 avec un TTL de 300 secondes.
Décision : Si c’est erroné, corrigez la publication (valeur/enregistrement/zone). Si c’est correct, votre problème est en aval dans les caches ou dans le comportement client.
Task 3: Compare all authoritative servers (catch stale secondaries)
cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do echo "== $ns =="; dig @$ns www.example.com A +noall +answer; done
== ns1.dns-provider.net ==
www.example.com. 300 IN A 203.0.113.42
== ns2.dns-provider.net ==
www.example.com. 300 IN A 198.51.100.77
Ce que ça signifie : Split‑brain au niveau autoritatif. Différents NS servent des réponses différentes.
Décision : Arrêtez le débogage des caches. Corrigez la distribution de la zone/AXFR/IXFR/primary caché, ou la synchronisation du fournisseur. Tant que les autoritatifs ne sont pas d’accord, tout le reste est du bruit.
Task 4: Check what a public recursive resolver sees
cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer
www.example.com. 245 IN A 203.0.113.42
Ce que ça signifie : Le résolveur public a la nouvelle valeur ; TTL restant 245 secondes.
Décision : Si les utilisateurs voient encore l’ancien, ils utilisent peut‑être un autre résolveur (corporate/VPC), ou le problème est un cache local/app.
Task 5: Check a corporate/VPC resolver explicitly
cr0x@server:~$ dig @10.20.30.40 www.example.com A +noall +answer
www.example.com. 3240 IN A 198.51.100.77
Ce que ça signifie : Ce résolveur a encore l’ancienne réponse en cache, avec presque une heure restante.
Décision : Attendre (meilleur choix), ou vider le cache de ce résolveur si vous le possédez et que la purge est sûre. Ne redémarrez pas la moitié du parc.
Task 6: Detect negative caching (NXDOMAIN) at the resolver
cr0x@server:~$ dig @10.20.30.40 newhost.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41433
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
example.com. 300 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Ce que ça signifie : NXDOMAIN est renvoyé et le SOA dans authority indique le comportement de TTL négatif.
Décision : Si vous venez de créer newhost, ce résolveur peut mettre en cache « n’existe pas » jusqu’à la TTL négative du SOA. Vous pouvez vider le cache du résolveur ou attendre ; n’insistez pas en « ré‑essayant » en vous attendant à un résultat différent.
Task 7: Follow CNAME chains to the real target
cr0x@server:~$ dig www.example.com A +noall +answer
www.example.com. 300 IN CNAME www.example.com.cdn.vendor.net.
www.example.com.cdn.vendor.net. 60 IN A 203.0.113.42
Ce que ça signifie : Votre « changement d’enregistrement » peut se situer chez le nom CDN, pas sur le nom vanity.
Décision : Déboguez la bonne zone. Si vous ne contrôlez que www.example.com mais que le fournisseur contrôle la cible, vider vos caches ne changera pas les TTL du fournisseur.
Task 8: Verify what resolver your Linux host is actually using (systemd-resolved)
cr0x@server:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.40
DNS Servers: 10.20.30.40 10.20.30.41
Ce que ça signifie : Votre machine utilise 10.20.30.40 comme résolveur, pas celui que vous avez testé plus tôt.
Décision : Interrogez ce résolveur directement. Si c’est obsolète, vider votre navigateur ne servira à rien.
Task 9: Flush systemd-resolved cache (client-side)
cr0x@server:~$ sudo resolvectl flush-caches
Ce que ça signifie : Le cache stub local est vidé.
Décision : Re‑testez avec dig depuis le même hôte. Si les résultats ne changent pas, le problème est en amont ou n’est pas du DNS du tout.
Task 10: Inspect glibc NSS path (are you even using DNS?)
cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
Ce que ça signifie : Les recherches consultent /etc/hosts en premier, puis le comportement mDNS, puis DNS.
Décision : Si quelqu’un a fixé une ancienne IP dans /etc/hosts, aucun vidage DNS ne le réparera. Vérifiez /etc/hosts ensuite.
Task 11: Check whether /etc/hosts is overriding your change
cr0x@server:~$ grep -n 'www.example.com' /etc/hosts
12:198.51.100.77 www.example.com
Ce que ça signifie : L’hôte est codé en dur vers l’ancienne IP.
Décision : Supprimez ou mettez à jour l’entrée. Ce n’est pas un problème DNS ; c’est une sur‑définition locale.
Task 12: Observe actual resolution via getent (what your apps often use)
cr0x@server:~$ getent ahostsv4 www.example.com
203.0.113.42 STREAM www.example.com
203.0.113.42 DGRAM
203.0.113.42 RAW
Ce que ça signifie : La pile de résolution système (NSS + stub) renvoie la nouvelle IP.
Décision : Si votre application se connecte toujours à l’ancien endpoint, suspectez le pool de connexions, des upstreams épinglés, ou une couche interne de découverte de service.
Task 13: Check DNS TTLs and caching at BIND (resolver you own)
cr0x@server:~$ sudo rndc status
version: BIND 9.18.24
running on dns-cache-01: Linux x86_64 6.8.0
number of zones: 102
recursive clients: 17/1000/1000
Ce que ça signifie : Vous exécutez un résolveur récursif (ou au moins BIND est présent).
Décision : Si cette couche de cache renvoie des réponses obsolètes, planifiez une purge de cache contrôlée (tâche suivante) plutôt que de redémarrer le démon à l’aveugle.
Task 14: Flush BIND resolver cache safely (targeted approach)
cr0x@server:~$ sudo rndc flushname www.example.com
Ce que ça signifie : BIND supprime les entrées de cache pour ce nom (et les données liées).
Décision : Préférez flushname à un flush global pendant les heures ouvrées. Un flush global peut provoquer un afflux vers l’amont et faire ressembler la latence à une panne.
Task 15: Check CoreDNS behavior inside Kubernetes
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
ttl 30
}
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Ce que ça signifie : CoreDNS met explicitement en cache pendant 30 secondes, et le plugin Kubernetes a TTL 30.
Décision : Si le problème « changements DNS non visibles » dure des minutes, le cache CoreDNS n’est probablement pas le coupable. Cherchez en amont ou du côté du cache applicatif.
Task 16: Test from inside a pod (remove your laptop from the story)
cr0x@server:~$ kubectl run -it --rm dns-debug --image=alpine:3.20 -- sh -lc "apk add --no-cache bind-tools >/dev/null && dig www.example.com A +noall +answer"
www.example.com. 300 IN A 203.0.113.42
Ce que ça signifie : Le cluster voit la nouvelle réponse.
Décision : Si une charge en cluster atteint encore l’ancienne IP, suspectez l’application (réutilisation de connexion) ou un sidecar/maillage de services.
Task 17: Prove it’s not DNS—check where connections go
cr0x@server:~$ curl -sS -o /dev/null -w "remote_ip=%{remote_ip}\n" https://www.example.com/
remote_ip=198.51.100.77
Ce que ça signifie : Vous vous connectez toujours à l’ancienne IP même si le DNS indique le contraire (ou TLS/SNI vous y route).
Décision : Vérifiez les proxies, load balancers, la config CDN, et si votre client réutilise une connexion existante. Le DNS peut déjà être correct.
Task 18: Check whether a local caching daemon is in play (nscd)
cr0x@server:~$ systemctl is-active nscd
inactive
Ce que ça signifie : nscd n’est pas en cours d’exécution, donc ce n’est pas votre couche de cache.
Décision : Ne perdez pas de temps à vider ce qui n’existe pas. Trouvez le composant de cache réel.
Caches à ne pas vider (sauf si vous aimez les pannes)
Vider des caches, c’est comme couper et rallumer un routeur : ça donne l’impression d’être productif, c’est parfois nécessaire, et c’est dangereusement addictif.
Certains caches sont sûrs à effacer localement. D’autres sont une infrastructure partagée et les vider peut provoquer un effet d’onde massif.
Ne vidangez pas globalement de grands résolveurs récursifs pendant les heures de pointe
Si vous gérez une flotte de résolveurs d’entreprise ou une couche de résolveurs VPC partagée, un flush global peut déclencher :
- pics de QPS vers l’amont
- augmentation de la latence et des timeouts
- dépendance amplifiée sur des résolveurs externes
- pannes en cascade dans des applis qui considèrent les timeouts DNS comme fatals
Préférez les purges ciblées (flushname / par zone / par view) ou, mieux, attendez l’expiration des TTL quand c’est sûr.
Ne redémarrez pas CoreDNS comme premier réflexe
Redémarrer CoreDNS peut casser la résolution de noms à l’échelle du cluster. C’est une grosse surface d’impact pour un problème qui est souvent juste une question de TTL.
Si vous suspectez le cache CoreDNS, confirmez avec un dig depuis un pod et inspectez d’abord le Corefile.
Ne « corrigez » pas en baissant les TTLs dans la panique
Baisser les TTL est un outil de planification, pas un levier d’urgence. Baisser un TTL maintenant n’aide pas les clients qui ont déjà mis en cache l’ancienne réponse.
Cela n’affecte que le prochain remplissage de cache.
Blague #1 : La mise en cache DNS, c’est comme les commérages au bureau : une fois que c’est sorti, corriger prend plus de temps que de le propager.
Faits intéressants et un peu d’histoire DNS
- Le DNS a remplacé la douleur d’échelle de HOSTS.TXT. Les premiers hôtes ARPANET utilisaient un fichier hosts partagé ; à mesure que le réseau grandissait, la distribution est devenue un goulet d’étranglement.
- Le TTL n’a pas été pensé pour votre cadence de déploiement. Il a été conçu pour rendre un système mondial de noms évolutif et résilient, pas pour rendre instantanés les redirections marketing.
- La mise en cache négative est standardisée. Mettre en cache le « n’existe pas » est volontaire ; sinon les résolveurs martèleraient les serveurs faisant autorité pour les fautes de frappe et les noms inexistants.
- Le champ SOA influence la mise en cache négative. Le champ « minimum »/TTL négatif du SOA est source de confusion ; différents outils l’étiquettent différemment.
- Les résolveurs mettent en cache plus que A/AAAA. Ils cachent aussi les délégations NS et le glue, ce qui peut rendre les changements de délégation persistants même quand une mise à jour d’enregistrement est rapide.
- Le DNS est généralement UDP. C’est rapide, mais cela signifie que la perte de paquets et les soucis MTU peuvent se faire passer pour du « DNS obsolète ». Le fallback TCP existe, mais pas toujours fiable.
- EDNS Client Subnet a changé la dynamique de cache. Certains résolveurs varient les réponses selon le sous‑réseau du client, ce qui réduit les hits de cache et augmente les moments « chez moi ça marche ».
- Les navigateurs sont devenus acteurs DNS. Les navigateurs modernes pré‑résolvent, mettent en cache indépendamment et parfois ouvrent plusieurs connexions en parallèle, donc le DNS n’est plus seulement une affaire d’OS.
Trois mini-histoires d’entreprise du terrain
Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne a migré une API client vers un nouveau load balancer. Le plan était simple : mettre à jour l’enregistrement A pour
api.example.com de l’ancien VIP vers le nouveau VIP. Ils avaient fixé le TTL à 300 une semaine avant. Parfait.
Le jour du basculement, la moitié du trafic a bougé. L’autre moitié continuait d’atteindre l’ancienne infrastructure et commençait à subir des timeouts parce que
le pool de l’ancien load balancer était drainé. Le canal incident s’est rempli de « le DNS n’a pas propagé ».
La mauvaise hypothèse : tout le monde interrogeait api.example.com. Ce n’était pas le cas. Un client mobile legacy avait codé en dur
api-v2.example.com, qui était un CNAME vers un nom fournisseur avec un TTL de 3600. L’équipe avait changé le nom vanity
que les humains connaissaient, pas la chaîne de dépendance utilisée par les appareils.
La correction n’a pas été de vider les caches. La correction a été de mettre à jour la cible CNAME réelle (via le workflow fournisseur) et de garder temporairement
l’ancien VIP vivant. Ils ont aussi documenté la chaîne CNAME complète dans leur runbook, parce que le savoir tribal n’est pas une stratégie de gestion de changement.
Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre organisation en avait assez des pics de latence DNS et a décidé « d’optimiser » en ajoutant un caching agressif partout :
cache node‑local sur les nœuds Kubernetes, plus une couche interne de forwarders, plus une bibliothèque de cache dans l’app.
L’argument semblait convaincant : moins de requêtes, réponses plus rapides, coût réduit.
Puis ils ont introduit des déploiements blue/green derrière le DNS. Pendant le rollout, certains pods résolvaient le nouvel endpoint et réussissaient.
D’autres continuaient d’utiliser l’ancien endpoint et échouaient. Leurs dashboards ressemblaient à un code‑barres : succès/échec alternant toutes les quelques secondes.
Le retour de bâton venait de la superposition des caches et de la sémantique TTL non alignée. Le cache applicatif gardait des entrées plus longtemps que le TTL de l’OS.
Le cache node‑local respectait le TTL mais avait un bug qui épinglait les réponses négatives plus longtemps sous charge. La couche forwarder avait
des délégations obsolètes après un changement de nameserver. Chaque couche « fonctionnait », mais la composition était chaotique.
La récupération fut ennuyeuse : supprimer le caching DNS au niveau applicatif, standardiser sur une seule couche de cache (node‑local ou central,
pas les deux), et alerter sur les hausses de SERVFAIL des résolveurs. Ils ont aussi cessé d’utiliser le DNS comme outil de répartition fine du trafic
et sont passés aux poids des load balancers pour des coupures rapides.
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société financière avait un processus de changement piloté par la conformité que tout le monde raillait jusqu’au jour où il a payé.
Ils devaient déplacer un endpoint d’intégration fournisseur externe. L’intégration utilisait un hostname, pas une IP fixe, ce qui était déjà un bon signe.
Deux semaines avant le déplacement, ils ont baissé le TTL de 3600 à 300. Pas en panique — selon le calendrier. Ils ont validé le nouveau TTL en
interrogeant les autoritatifs et plusieurs recursors. Ils ont aussi capturé des réponses de référence dans un ticket, y compris la chaîne CNAME et le SOA.
La nuit du basculement, ils ont changé l’enregistrement, vérifié l’autoritatif, puis vérifié via leurs résolveurs corporatifs.
Ils n’ont pas vidé les caches. Ils ont regardé les TTLs décroître. Pour le petit nombre de clients derrière un résolveur récalcitrant,
ils ont appliqué une purge ciblée sur la couche de résolveur qu’ils possédaient.
Le basculement s’est déroulé sans impact client. Personne n’a envoyé d’email triomphant parce que la correction ennuyeuse ne fait pas le buzz.
Mais l’ingénieur d’astreinte a dormi, et c’est le seul KPI qui compte à 2h du matin.
Erreurs courantes : symptômes → cause → correctif
1) Symptom: “Authoritative shows new IP, but some users still hit old IP for hours”
Cause racine : Les résolveurs récursifs ont mis en cache l’ancienne réponse avec un TTL élevé, ou vous avez baissé le TTL trop tard.
Correctif : Attendre la fin du TTL ; la prochaine fois, baissez le TTL au moins une fenêtre TTL complète avant le changement. Si vous contrôlez le résolveur, faites une purge ciblée pour le nom.
2) Symptom: “New hostname returns NXDOMAIN even though we created it”
Cause racine : Mise en cache négative aux résolveurs récursifs suite à des requêtes antérieures quand l’enregistrement n’existait pas.
Correctif : Vérifiez le TTL négatif du SOA ; videz le cache du résolveur si vous le contrôlez, ou attendez. Évitez de créer des enregistrements « au dernier moment » quand vous pouvez les pré‑stager.
3) Symptom: “Works on my laptop, fails in production”
Cause racine : Différents résolveurs. Votre laptop utilise un résolveur public ou un VPN ; la production utilise un résolveur VPC ou un forwarder interne avec un cache obsolète.
Correctif : Interrogez directement le résolveur de production. N’utilisez pas votre machine personnelle comme instrument de mesure pour la production.
4) Symptom: “dig shows new IP, but the service still connects to old IP”
Cause racine : Pool de connexions / keep‑alives / clients longue durée (pas DNS). Ou routage proxy basé sur SNI/Host.
Correctif : Vérifiez l’IP distante avec curl -w %{remote_ip} ; redémarrez ou rechargez le pool de clients, pas la couche DNS. Envisagez de réduire les keep‑alive ou d’implémenter un rafraîchissement DNS proactif dans le client.
5) Symptom: “Some regions see new answer, others don’t”
Cause racine : DNS géo / routage par latence / EDNS Client Subnet, ou vues split‑horizon.
Correctif : Testez avec des résolveurs dans ces régions ou points de sortie d’entreprise. Confirmez les politiques de routage du fournisseur. Assurez‑vous d’avoir modifié la bonne vue.
6) Symptom: “After we flushed the resolver, everything got slower”
Cause racine : Stampede de cache. Vous avez forcé un cache froid sur de nombreux noms, augmentant la QPS vers l’amont et la latence.
Correctif : Évitez les vidages globaux. Utilisez des vidages ciblés. Si vous devez vider globalement, faites‑le hors‑pointe et surveillez la saturation amont et les taux SERVFAIL.
7) Symptom: “Only one server sees the old record”
Cause racine : Override local dans /etc/hosts, démon de cache local, ou différents réglages resolv.conf/resolved.
Correctif : Vérifiez /etc/hosts, resolvectl status et getent. Videz le cache stub local seulement après avoir confirmé le chemin de résolution local.
8) Symptom: “We changed NS records and now some clients can’t resolve the domain”
Cause racine : Cache de délégation et glue / TTL des zones parentes ; certains résolveurs utilisent encore l’ancien ensemble NS.
Correctif : Planifiez les changements NS avec un délai suffisant. Gardez les anciens serveurs de noms en service pendant au moins la fenêtre TTL pertinente. Attendez‑vous à un comportement mixte pendant la transition ; ne l’interprétez pas comme « aléatoire ». C’est du cache de délégation.
Blague #2 : Vider des caches DNS est la seule fois où « avez‑vous essayé de l’éteindre et de le rallumer » peut DDoS votre propre infrastructure.
Listes de contrôle / plan étape par étape
Checklist A: You changed an A/AAAA record and users don’t see it
- Vérifier la vérité autoritaire : interrogez chaque NS autoritatif directement. Confirmez valeur et TTL.
- Vérifier la chaîne CNAME : assurez‑vous que vous n’avez pas modifié un nom que personne n’interroge réellement.
- Identifier le résolveur sur le chemin défaillant : résolveur du client, DNS d’entreprise, résolveur VPC.
- Mesurer le TTL restant sur ce résolveur : si le TTL est élevé, attendre est la bonne réponse.
- Choisir l’action :
- Si vous possédez le résolveur : purge ciblée pour ce nom.
- Si vous ne le possédez pas : attendre ; envisager des mitigations temporaires (garder l’ancien endpoint actif).
- Seulement ensuite : vider le cache stub OS sur les clients de test pour réduire la confusion.
- Valider la réalité : confirmez où vont réellement les connexions (IP distante), pas seulement ce que renvoie le DNS.
Checklist B: You created a new hostname and it returns NXDOMAIN
- Interrogez directement l’autoritatif : l’enregistrement existe‑t‑il là‑bas ?
- Si l’autoritatif est correct, interrogez le résolveur défaillant et vérifiez NXDOMAIN + SOA dans authority.
- Décidez : attendre l’expiration du TTL négatif, ou purger le résolveur si vous le contrôlez.
- Prévention : pré‑créez les enregistrements avant la mise en production pour éviter la mise en cache négative le jour du lancement.
Checklist C: You changed NS records (danger zone)
- Confirmez que la délégation de la zone parente est correcte (ce que sert le registre/parent).
- Confirmez que les nouveaux serveurs de noms servent la zone correctement et de façon cohérente.
- Gardez les anciens serveurs de noms actifs et servant la zone pendant au moins la fenêtre TTL maximale pertinente.
- Attendez‑vous à un comportement mixte pendant la transition ; n’interprétez pas cela comme « aléatoire ». C’est de la délégation mise en cache.
Checklist D: Decide what to flush (minimal blast radius)
- Videz le stub local si seul votre poste a un mauvais résultat :
resolvectl flush-caches. - Videz un seul nom sur un résolveur que vous possédez si l’impact métier est réel :
rndc flushname. - Ne pas vider les caches des résolveurs globaux à moins d’avoir un plan de capacité et un responsable d’incident qui aime la douleur.
- Ne pas redémarrer les services DNS comme substitut à la compréhension du problème.
FAQ
1) Pourquoi l’interface de mon fournisseur DNS affiche la nouvelle valeur mais les utilisateurs ont encore l’ancienne ?
L’interface du fournisseur montre les données autoritatives. Les utilisateurs interrogent généralement des résolveurs récursifs qui ont mis en cache l’ancienne valeur jusqu’à l’expiration du TTL.
Confirmez en interrogeant directement l’autoritatif, puis le résolveur de l’utilisateur.
2) Si je baisse le TTL maintenant, est‑ce que ça accélérera le changement en cours ?
Principalement non. Les résolveurs qui détiennent déjà l’ancienne réponse la garderont jusqu’à l’écoulement de leur TTL local.
Baisser le TTL aide le remplissage de cache suivant.
3) Que signifie réellement « propagation DNS » ?
Ce n’est pas une vague synchronisée unique. Ce sont des caches indépendants qui expirent à des moments différents à travers les résolveurs récursifs,
forwarders, stubs OS, navigateurs et applications.
4) Quel cache dois‑je vider en premier ?
Aucun. D’abord, confirmez que l’autoritatif est correct. Ensuite, identifiez le résolveur sur le chemin défaillant. Ne videz que la couche
qui est prouvée obsolète — et seulement si vous la possédez et que la portée d’impact est acceptable.
5) Pourquoi je vois NXDOMAIN pour un enregistrement qui existe maintenant ?
Mise en cache négative. Un résolveur peut avoir mis en cache « n’existe pas » lorsqu’on a demandé le nom avant sa création. Ce cache peut persister
selon le SOA/TTL négatif. Videz le résolveur si vous le pouvez ; sinon attendez.
6) Pourquoi dig montre la nouvelle IP mais mon appli utilise encore l’ancienne ?
Parce que votre appli peut ne pas re‑résoudre. Elle peut réutiliser une connexion poolée, mettre en cache DNS en‑processus,
ou router via un proxy qui a son propre mapping upstream.
7) Devons‑nous exécuter un cache DNS node‑local dans Kubernetes ?
Ça peut être excellent pour la performance et la résilience, mais ça ajoute une couche de plus à déboguer. Si vous le faites, standardisez et documentez :
où le caching se produit, les TTL attendus, et comment tester depuis pod/nœud. Évitez d’empiler plusieurs caches sans raison.
8) Vider le cache DNS du navigateur est‑il utile ?
Parfois, pour un cas d’utilisateur unique « mon laptop est bizarre ». Ça ne corrigera pas les utilisateurs en production. Utilisez‑le comme nettoyage de dernier kilomètre,
pas comme stratégie de propagation.
9) Quelle est la façon la plus sûre de gérer des basculements DNS planifiés ?
Pré‑stager, baisser les TTL à l’avance, valider les réponses autoritatives, garder les anciens endpoints vivants au moins pendant la fenêtre TTL,
et surveiller les destinations réelles des connexions. Utilisez la purge ciblée du résolveur seulement si nécessaire.
10) Pourquoi différents résolveurs publics montrent des réponses différentes ?
Ils ont pu mettre en cache à des moments différents, être dans des régions différentes, appliquer des politiques différentes, ou recevoir des réponses
différentes à cause d’EDNS Client Subnet ou du routage géo. Cette diversité est normale.
Prochaines étapes à faire aujourd’hui
- Ajoutez « autoritatif d’abord » à votre runbook : vérifiez toujours les réponses NS directes avant de toucher aux caches.
- Documentez votre vrai chemin de résolveur : quels résolveurs la production utilise, où existent les caches, et qui les possède.
- Standardisez vos outils : privilégiez
dig+getent+ « vérifier l’IP distante » plutôt que les conjectures. - Planifiez les changements de TTL : baissez les TTL avant les migrations planifiées ; n’attendez pas qu’un changement de dernière minute vous sauve.
- Adoptez la purge ciblée : si vous exploitez des résolveurs, supportez le flush par nom. Faites du flush global une action explicitement approuvée.
Les changements DNS « non visibles » ne sont généralement pas mystérieux. Ils sont la plupart du temps la mise en cache qui fait exactement ce pour quoi elle a été conçue,
au pire moment pour votre planning. Votre travail est de trouver le cache unique qui compte, et de laisser le reste de la planète tranquille.