Ubuntu 24.04 : les caches DNS mentent — videz le bon cache (et arrêtez de vider le mauvais) (cas n°26)

décembre 25, 2025 • février 3, 2026 • Lecture : 26 min • Views: 8

Cet article vous a aidé ?

Les défaillances DNS ne se présentent que rarement comme des « défaillances DNS ». Elles se manifestent par une erreur TLS, un délai d’attente dans un client d’API, un nœud Kubernetes qui « ne peut pas récupérer les images », ou un portable qui ne fonctionne que sur le Wi‑Fi du bureau. Puis quelqu’un prononce l’incantation ancestrale : « vider le DNS ». Dix minutes plus tard, ça échoue toujours. Vous avez perdu du temps et renforcé la confiance dans un rituel inefficace.

Ubuntu 24.04 est un endroit particulièrement propice pour apprendre cette leçon, parce que plusieurs couches de cache et plus d’un chemin de résolveur peuvent intervenir. Le résultat : vos caches DNS peuvent mentir — pas par malveillance, simplement par fonctionnement mécanique. Votre tâche est de vider le cache qui sert réellement la réponse, et de le prouver avec des outils qui ne vous mentent pas en retour.

Le modèle mental : le DNS est une pipeline, pas une simple recherche

Quand quelqu’un dit « cache DNS », il imagine habituellement un seul seau de réponses. En réalité, le DNS sur une machine Ubuntu moderne est une pipeline :

Le comportement du résolveur de l’application (glibc NSS, le résolveur pur de Go, Java, curl avec c-ares, le cache interne de Chromium).
Le résolveur stub local (souvent systemd-resolved écoutant sur 127.0.0.53).
Un forwarder cacheur local (parfois dnsmasq, parfois aucun).
Les résolveurs récursifs en amont (DNS d’entreprise, FAI, résolveur cloud, Unbound, BIND).
Le DNS autoritatif (Route 53, Cloud DNS, BIND sur site, etc.).
Anycast et bords CDN (parce que la « réponse DNS » peut varier selon votre localisation).

Chacune de ces couches peut mettre en cache. Chacune peut avoir des règles différentes sur le TTL, le cache négatif (cacher « NXDOMAIN »), le comportement DNSSEC, ou quel serveur DNS est « préféré ». Donc oui, votre machine peut continuer à affirmer que api.internal.example pointe vers une ancienne adresse IP même après que vous ayez « vidé le DNS ». Vous avez probablement vidé un cache qui n’était pas utilisé.

Règle pratique : commencez toujours par prouver quel composant répond. Vider avant de savoir quoi vider, c’est comme redémarrer avant d’avoir regardé les logs. Parfois ça marche. Ça n’en fait pas une stratégie.

Une idée paraphrasée de Gene Kim (opérations et fiabilité) : Améliorez les résultats en raccourcissant les boucles de rétroaction ; rendez les problèmes visibles rapidement, et corrigez le système plutôt que de compter sur des exploits au cas par cas.

Faits et contexte historique intéressants (pourquoi c’est si désordonné)

Fait 1 : Le DNS précède le web de plusieurs années ; il a été conçu pour un internet plus petit et plus lent à changer. Le cache était une fonctionnalité, pas un accident.
Fait 2 : Le concept de « stub resolver » existe parce que la plupart des applications ne devraient pas implémenter la résolution récursive complète. Elles interrogent un agent local qui interroge le réseau.
Fait 3 : Le fichier classique /etc/resolv.conf a été conçu pour des serveurs statiques. Les systèmes modernes le génèrent souvent dynamiquement, parfois sous forme de lien symbolique.
Fait 4 : Le cache négatif (memorisation de « n’existe pas ») est standardisé. C’est pour cela qu’un enregistrement brièvement absent peut vous hanter plus longtemps que prévu.
Fait 5 : Le « split‑horizon DNS » (réponses différentes selon d’où vous interrogez) est courant en entreprise. Cela rend aussi le débogage digne d’un gaslighting.
Fait 6 : systemd-resolved existe en partie pour unifier un monde chaotique de DNS par interface, DNS VPN, et décisions DNSSEC. Vous pouvez ne pas l’aimer, mais il essaie d’arrêter les saignements.
Fait 7 : Certains langages contournent glibc et gèrent leur propre DNS. Go est l’exemple célèbre, mais pas le seul. Votre application peut ne pas utiliser le même chemin que dig.
Fait 8 : Les navigateurs mettent aussi en cache le DNS. Même si le cache OS est parfait, un navigateur peut conserver une réponse obsolète et vous faire accuser le réseau.

Le débogage DNS est pénible parce qu’il s’agit d’état distribué. Quand l’état est distribué, la confiance est un luxe. Les preuves coûtent moins cher.

Stack de résolveur sur Ubuntu 24.04 : qui répond à votre question ?

Sur Ubuntu 24.04, le comportement par défaut le plus courant est :

systemd-resolved en tant que service.
Un stub resolver sur 127.0.0.53, exposé via un /etc/resolv.conf généré.
Des serveurs DNS en amont fournis par NetworkManager, netplan/systemd-networkd, DHCP, ou des clients VPN.

Mais les machines de production ne restent jamais « par défaut » très longtemps. Vous pouvez avoir :

dnsmasq installé pour le cache local ou le split DNS pour des conteneurs.
nscd (Name Service Cache Daemon) encore présent d’anciens guides d’optimisation.
Des composants Kubernetes, Docker, ou systemd-networkd qui manipulent le DNS par interface.
Un VPN qui pousse ses propres serveurs DNS et règles de routage.
Des applications utilisant DoH (DNS over HTTPS) ou leurs propres bibliothèques de résolveur.

Le point : « Vider le DNS » n’est pas une seule commande. C’est un arbre de décisions.

Blague #1 : Le DNS, c’est comme les commérages de bureau : ça se répand vite, c’est mis en cache partout, et la rétractation a un TTL beaucoup plus long.

Ce que « vider » signifie réellement

Vider n’aide que si :

La couche met effectivement en cache.
La couche est réellement utilisée pour la requête défaillante.
La défaillance est due à un état mis en cache obsolète (et non au routage, pare‑feu, discordance TLS SNI, configuration de proxy, ou problèmes de sélection IPv6).

Si un enregistrement est erroné dans le DNS autoritatif, vider les clients ne le corrigera pas. Si les résolveurs récursifs en amont servent des données obsolètes à cause de leur propre cache, vider un portable ne le réparera pas. Et si l’application n’interroge jamais l’OS pour le DNS, vider systemd-resolved est une performance artistique.

Mode opératoire de diagnostic rapide : trouver le goulot en minutes

C’est l’ordre que j’utilise en on‑call. Il est optimisé pour « qu’est‑ce qui a changé, qu’est‑ce qui casse, et quelle est la preuve la plus rapide ».

1) Confirmer que le symptôme est DNS, pas « impossible d’atteindre l’IP »

Si vous connaissez l’adresse IP attendue, essayez de vous connecter directement par IP (HTTP avec Host header, TLS en tenant compte du SNI).
Si l’IP directe fonctionne mais que le nom échoue, vous êtes probablement dans le domaine du DNS.

2) Identifier quel chemin de résolveur l’application utilise

Utilise‑t‑elle glibc NSS ? (La plupart des outils natifs Linux le font.)
Est‑ce Go avec le résolveur pur ? Java ? Un navigateur avec son propre cache/DoH ?
S’exécute‑t‑elle dans un conteneur avec un /etc/resolv.conf différent ?

3) Interroger le stub de l’OS pour connaître sa croyance

Utilisez resolvectl query et vérifiez l’état du cache, la sélection du serveur et les enregistrements.

4) Interroger directement les résolveurs en amont

Utilisez dig @server name contre le résolveur d’entreprise, puis contre un résolveur de référence du même réseau.
Comparez les réponses et les TTL.

5) Vider la couche spécifique qui est fautive

Videz le cache de systemd-resolved s’il est fautif.
Redémarrez dnsmasq s’il est dans le chemin et met en cache.
Effacez les caches du navigateur/de l’application si l’OS est correct mais l’application ne l’est pas.

6) Si les caches semblent cohérents : suspectez le split DNS, le routage VPN ou la sélection IPv6

Vérifiez le DNS par interface et les règles de routage.
Vérifiez si l’application préfère des enregistrements AAAA qui ne routent nulle part.

Tâches pratiques (avec commandes, sorties et décisions)

Voici des tâches réelles à exécuter sur Ubuntu 24.04. Chacune inclut : la commande, un exemple de sortie, ce que cela signifie, et la décision à prendre.

Task 1: See what `/etc/resolv.conf` really is

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jun 21 08:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : Vous utilisez le stub de systemd-resolved (probablement 127.0.0.53). Beaucoup de guides « vider le DNS » pour d’autres distributions ne s’appliqueront pas.

Décision : Utilisez resolvectl et systemctl pour inspecter et vider. N’éditez pas /etc/resolv.conf à la main sauf si vous remplacez volontairement le système.

Task 2: Confirm `systemd-resolved` is running

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:14 UTC; 2h 11min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."

Signification : Le cache local et le stub sont actifs.

Décision : Vider nscd ou redémarrer des services réseau au hasard est probablement la mauvaise action. Commencez par resolvectl.

Task 3: Inspect resolver configuration (servers, interfaces, DNSSEC)

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

Link 2 (ens3)
Current Scopes: DNS
     Protocols: +DefaultRoute
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Signification : Votre système utilise des résolveurs d’entreprise, et le serveur actif est 10.20.0.53. Cela vous indique qui interroger ensuite.

Décision : Si le serveur en amont est erroné ou incohérent, vider les caches locaux ne le corrigera pas. Il faudra interroger directement les résolveurs en amont et éventuellement monter l’incident vers leurs responsables.

Task 4: Ask the OS resolver for a name and see what it returns

cr0x@server:~$ resolvectl query api.internal.example
api.internal.example: 10.70.8.19                           -- link: ens3

-- Information acquired via protocol DNS in 11.2ms.
-- Data is authenticated: no

Signification : Voilà ce que croit le résolveur de l’OS à cet instant. Il vous indique aussi quelle interface (link) et donc quels réglages DNS par interface ont été utilisés.

Décision : Si la réponse de l’OS est erronée, videz le cache de systemd-resolved. Si elle est correcte mais que votre application est incorrecte, suspectez un cache au niveau de l’application ou un autre chemin de résolveur.

Task 5: Check if the result is coming from cache

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Transactions
        Current Transactions: 0
              Total Requests: 14382
            Cache Hits: 9112
          Cache Misses: 5270

Cache
          Current Cache Size: 216
                  Cache Hits: 9112
                Cache Misses: 5270

Signification : Cela confirme que la mise en cache est active et utilisée. Un grand nombre de hits durant un incident peut signifier que vous servez à répétition des réponses obsolètes.

Décision : Si vous suspectez un cache obsolète, videz‑le puis re‑interrogez ; vérifiez ensuite si les réponses en amont ont changé.

Task 6: Flush `systemd-resolved` cache (the right “flush” most of the time)

cr0x@server:~$ sudo resolvectl flush-caches

Signification : L’absence de sortie est normale. Ceci efface les caches de systemd-resolved (positifs et négatifs).

Décision : Relancez immédiatement resolvectl query. Si la réponse reste erronée, le résolveur en amont sert probablement la même donnée erronée.

Task 7: Prove what the upstream resolver says (bypass local cache)

cr0x@server:~$ dig @10.20.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  300 IN A 10.70.8.19

Signification : Le résolveur en amont retourne le même enregistrement A avec TTL 300 secondes. S’il est erroné, l’amont est fautif (ou l’autoritatif est incorrect).

Décision : Si vous contrôlez l’amont, videz‑y le cache ou corrigez l’autoritatif. Si ce n’est pas le cas, utilisez un résolveur alternatif seulement si la politique le permet et si le split DNS ne vous casse pas.

Task 8: Compare with another resolver to detect split DNS or resolver inconsistency

cr0x@server:~$ dig @10.20.0.54 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28490
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

Signification : Deux résolveurs d’entreprise ne sont pas d’accord. Ce n’est pas « le DNS qui fait son travail » ; c’est une réplication/forwarding/cache ou une mauvaise configuration split‑horizon.

Décision : Arrêtez de vider les caches clients. Choisissez le résolveur correct (temporairement) ou basculez selon l’ordre des résolveurs, et ouvrez un incident pour l’équipe DNS.

Task 9: See if you’re dealing with negative caching (NXDOMAIN)

cr0x@server:~$ resolvectl query new-service.internal.example
new-service.internal.example: resolve call failed: 'new-service.internal.example' not found

Signification : NXDOMAIN (ou équivalent) peut être mis en cache. Si l’enregistrement vient d’être créé, votre chemin de résolveur peut continuer à nier son existence pendant un certain temps.

Décision : Videz les caches à la couche qui produit NXDOMAIN. Puis interrogez directement l’autoritatif/en amont. Si l’autoritatif dit toujours NXDOMAIN, arrêtez de blâmer les caches et corrigez les données DNS.

Task 10: Inspect NSS order (is DNS even consulted?)

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Signification : Ce système consulte /etc/hosts en premier, puis mDNS, puis DNS. Une entrée obsolète dans /etc/hosts écrasera tout.

Décision : Si la résolution de nom est « mauvaise mais cohérente », vérifiez /etc/hosts. Vider les caches ne remplacera pas un fichier.

Task 11: Check for an override in `/etc/hosts`

cr0x@server:~$ grep -n 'api.internal.example' /etc/hosts
12:10.70.8.19 api.internal.example

Signification : Cet hôte est épinglé localement. Vos modifications DNS ne serviront à rien tant que vous n’enlèverez ou ne mettrez à jour cette ligne.

Décision : Corrigez l’entrée (ou supprimez‑la). Puis retestez. C’est le cas rare où éditer un fichier bat vider un cache.

Task 12: Confirm what glibc-based tools see (getent is your friend)

cr0x@server:~$ getent ahosts api.internal.example
10.70.8.19      STREAM api.internal.example
10.70.8.19      DGRAM
10.70.8.19      RAW

Signification : getent utilise la configuration NSS du système. Si getent correspond à resolvectl, le chemin OS est cohérent.

Décision : Si l’application se comporte encore différemment, elle peut utiliser son propre résolveur ou son propre cache. Montez le débogage plus haut dans la pile.

Task 13: Identify whether a local caching forwarder like dnsmasq is in play

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

Signification : dnsmasq ne fonctionne pas comme service système. Bien : une couche de cache en moins.

Décision : Ne redémarrez pas dnsmasq « au cas où ». S’il est inactif, ce n’est pas votre cache. Concentrez‑vous ailleurs.

Task 14: Check if `nscd` is caching host lookups

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

Signification : Pas de NSCD. Beaucoup d’articles « vider le cache DNS sur Linux » sont des fossiles de l’époque NSCD.

Décision : S’il est inactif, arrêtez d’essayer de le vider. S’il est actif dans votre environnement, vous devez le gérer délibérément (et envisager de le supprimer s’il entre en conflit avec votre stack de résolveur).

Task 15: Confirm which nameserver your tools actually query (127.0.0.53 vs direct)

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

Signification : La plupart des résolutions basées sur libc passent par le stub. Mais dig peut le contourner à moins que vous ne le pointiez vers 127.0.0.53 ou vers un résolveur en amont explicitement.

Décision : Lors de la comparaison d’outils, assurez‑vous qu’ils interrogent la même cible. Sinon vous déboguez deux systèmes différents et appelez cela « incohérent ».

Task 16: Query the stub resolver directly with dig

cr0x@server:~$ dig @127.0.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  287 IN A 10.70.8.19

Signification : Voilà la vue actuelle du cache du stub. La diminution du TTL suggère que vous regardez des données en cache (ce qui est normal).

Décision : Si vous videz et que le TTL se réinitialise (ou que la réponse change), vous avez prouvé que le cache du stub importait. Si rien ne change, le mensonge est en amont.

Task 17: Look for per-interface DNS that might be different under VPN

cr0x@server:~$ resolvectl dns
Global: 10.20.0.53 10.20.0.54
Link 2 (ens3): 10.20.0.53 10.20.0.54
Link 3 (tun0): 172.16.100.1

Signification : L’interface VPN tun0 a son propre serveur DNS. Selon les domaines routés, les requêtes peuvent y aller.

Décision : Si les noms internes ne se résolvent que via le VPN, c’est normal. Si les noms publics cassent sur VPN, vous pourriez écraser/leaker le DNS d’une manière inattendue pour l’application.

Task 18: Check if you have a routing/domain search rule that changes resolution

cr0x@server:~$ resolvectl domain
Global: corp.example
Link 2 (ens3): corp.example
Link 3 (tun0): ~internal.example

Signification : Le préfixe ~ indique un domaine « routing‑only » (split DNS). Les requêtes pour internal.example vont au résolveur VPN, les autres non.

Décision : Si le mauvais résolveur répond, corrigez la configuration split DNS plutôt que de vider des caches. Le vidage ne change pas les règles de routage.

Blague #2 : Vider le mauvais cache, c’est l’équivalent ops de débrancher l’écran pour résoudre un deadlock de base de données.

Trois mini‑histoires d’entreprise issues du champ de bataille DNS

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse (le piège « dig fait foi »)

Une société SaaS de taille moyenne a effectué une migration progressive d’une API interne d’un VPC à un autre. Le plan était propre : réduire les TTL à l’avance, mettre à jour les enregistrements A pendant une fenêtre de maintenance, surveiller les taux d’erreur, puis revenir en arrière si nécessaire. L’équipe testait la résolution avec dig depuis un bastion, voyait la nouvelle adresse IP et déclarait le DNS « terminé ».

Trente minutes plus tard, des flottes de workers ont commencé à échouer aux contrôles de santé. L’erreur n’était pas « NXDOMAIN » ni « impossible de résoudre l’hôte ». C’était des timeouts de connexion. L’équipe on‑call a chassé les groupes de sécurité, les passerelles NAT et les load balancers. Tout semblait en ordre. Pendant ce temps, dig montrait toujours la nouvelle adresse. La confiance restait mal placée.

Le piège : leurs workers étaient construits en Go, utilisant une configuration de résolveur qui contournait le stub local et possédait son propre comportement de cache. Sur les nœuds Ubuntu 24.04 affectés, systemd-resolved était correct, mais les processus Go restaient collés à d’anciennes réponses plus longtemps que prévu, en raison du résolveur interne de l’application et des patterns de réutilisation de connexion. Certains processus n’effectuaient même pas de nouvelles résolutions parce que des connexions keepalive s’accrochaient à des endpoints morts.

La résolution est venue en changeant la procédure de déploiement, pas en « vidant plus fort ». Ils ont ajouté un redémarrage contrôlé des processus après les basculements DNS pour cette classe de service, et ils ont validé la résolution via le même chemin que leurs workers (un petit binaire de diagnostic lié de la même façon). Ils ont aussi arrêté d’utiliser « dig sur le bastion » comme définition de la réalité.

La leçon est restée : le résolveur que vous testez doit correspondre à celui utilisé par votre charge. Sinon vous mesurez autre chose et appelez ça une validation.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux (édition forwarder cache local)

Une équipe plateforme entreprise a décidé « d’améliorer la performance DNS » sur des agents de build. Ils ont installé dnsmasq comme forwarder cache local, estimant que les scripts de build faisaient beaucoup de résolutions vers des dépôts internes d’artefacts. Ils ont aussi activé des paramètres de cache agressifs pour réduire la latence et diminuer la charge sur les résolveurs d’entreprise.

Ça a marché — jusqu’à ce que ça ne marche plus. Une rotation de certificat a coïncidé avec le déplacement d’un service interne derrière un nouveau VIP. Le nom de service est resté identique, l’IP a changé. Le DNS autoritatif et les résolveurs d’entreprise se comportaient correctement. Mais les agents de build continuaient d’essayer l’ancienne IP bien au‑delà du TTL. Certains se récupéraient au bout d’un moment, d’autres non, et les échecs étaient étrangement « collants » par machine.

La cause racine n’était pas un simple « bug dnsmasq ». C’était une dérive de configuration : certains agents avaient des tailles de cache et des règles de TTL différentes, et quelques‑uns avaient deux couches locales de résolveur (dnsmasq devant systemd-resolved) parce que les images avaient évolué dans le temps. Le résultat était des sémantiques de cache inconsistantes et une variance impossible à déboguer. Les ingénieurs ont commencé à redémarrer le réseau au hasard, ce qui aidait parfois et gaspillait surtout du temps.

La correction a été ennuyeuse mais efficace : supprimer dnsmasq sur la plupart des agents, le garder seulement là où le split DNS était réellement requis, et s’appuyer sur des résolveurs en amont stables conçus pour mettre en cache à grande échelle. Pour les rares cas nécessitant un forwarding local, ils ont standardisé les configs et ajouté un simple check « quel résolveur j’utilise » dans leur pipeline de provisioning.

Leçon d’optimisation : ajouter des couches de cache augmente le nombre de façons d’être en erreur. Les gains de performance existent, mais vous devez intégrer la maintenabilité dans le coût.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (discipline TTL et vérification graduée)

Une société de services financiers exploitait un dispositif de découverte de services interne où les enregistrements DNS étaient mis à jour par automatisation pendant des basculements. L’équipe avait déjà été brûlée par des caches obsolètes, alors ils ont fait quelque chose d’« inintéressant » : ils ont écrit un runbook et l’ont suivi comme des adultes.

Avant tout déplacement planifié, ils ont réduit les TTL 24 heures à l’avance. Pas à « 5 secondes » — à une valeur que leurs résolveurs et clients respecteraient réellement sans causer d’orage de requêtes. Ils avaient aussi une séquence de vérification standard : interroger l’autoritatif, interroger chaque résolveur récursif d’entreprise, puis interroger un client représentatif via le stub. Ce n’est qu’après concordance qu’ils basculaient le trafic.

Pendant un incident, un basculement s’est déroulé proprement mais un sous‑ensemble de clients frappait encore l’ancienne cible. Le runbook a rendu l’enquête rapide : l’autoritatif était correct, un résolveur récursif d’entreprise servait des données obsolètes. Comme ils disposaient déjà de la liste des recursors et d’un jeu de requêtes standard, ils ont isolé le mauvais résolveur, l’ont temporairement retiré de l’étendue DHCP, et ont rétabli le service pendant que l’équipe DNS réparait le résolveur.

Rien d’héroïque. Personne n’a « trouvé la commande magique pour vider ». Ils ont juste des preuves, dans l’ordre, et un plan pré‑convenu. C’est ce qui les a sauvés.

Erreurs fréquentes : symptôme → cause → correction

1) Symptom: “`dig` shows the new IP, but the app still hits the old one”

Cause racine : Chemins de résolveur différents ou cache/ réutilisation de connexion côté application. dig n’est pas votre application.

Correction : Validez avec getent ahosts (chemin glibc) et avec le comportement DNS du runtime de l’application. Envisagez de redémarrer le service après les basculements DNS si le runtime met en cache ou garde des connexions ouvertes.

2) Symptom: “Flushing local DNS does nothing”

Cause racine : Le mauvais cache. Le résolveur récursif en amont sert des données obsolètes, ou le nom est épinglé dans /etc/hosts.

Correction : Interrogez directement les résolveurs en amont avec dig @server. Vérifiez /etc/hosts. Escaladez auprès des responsables DNS si l’amont est erroné.

3) Symptom: “Works on Ethernet, fails on VPN (or the opposite)”

Cause racine : Split DNS et règles de résolveur par interface. Des domaines différents sont routés vers des résolveurs différents, parfois de manière inattendue.

Correction : Inspectez resolvectl dns et resolvectl domain. Corrigez les domaines routing‑only et les paramètres DNS poussés par le VPN plutôt que de vider des caches.

4) Symptom: “New hostname returns NXDOMAIN for minutes after creation”

Cause racine : Cache négatif à une couche de résolveur.

Correction : Videz les caches où NXDOMAIN est produit (systemd-resolved, dnsmasq, recursors en amont). Confirmez que l’autoritatif a bien l’enregistrement.

5) Symptom: “Random clients fail, others fine”

Cause racine : Incohérence du pool de résolveurs (deux recursors qui ne sont pas d’accord), ou images/configurations mixtes provoquant une dérive de comportement de cache.

Correction : Interrogez chaque résolveur configuré directement et comparez. Standardisez la configuration des résolveurs et supprimez les couches de cache supplémentaires sauf si elles résolvent un vrai besoin.

6) Symptom: “Hostname resolves to IPv6 and connections fail; IPv4 works”

Cause racine : Des enregistrements AAAA existent mais le chemin réseau IPv6 est cassé ou filtré ; le comportement Happy Eyeballs varie selon l’application.

Correction : Interrogez AAAA et A séparément, validez le routage IPv6, ou ajustez temporairement les enregistrements/politiques. Ne traitez pas cela comme un problème de cache tant que vous n’avez pas prouvé que c’en est un.

7) Symptom: “After changing DNS servers, machine still queries the old ones”

Cause racine : Configuration par interface obsolète, VPN qui pousse des réglages, ou un /etc/resolv.conf statique qui prend le pas.

Correction : Utilisez resolvectl status pour voir les serveurs actuels. Corrigez netplan/NetworkManager/la config VPN ; évitez d’éditer à la main des fichiers générés.

Listes de contrôle / plan étape par étape (faites ça, pas des impressions)

Checklist A: “DNS change just happened, some clients are wrong”

Sur un client affecté : capturer la vue de l’OS avec resolvectl query name.
Capturer la vue en amont : dig @current_upstream name +noall +answer +comments.
Comparer avec un second résolveur en amont si présent.
Si l’amont diffère : traitez comme une incohérence de résolveur. Escaladez et/ou retirez le mauvais résolveur de la rotation.
Si l’amont concorde mais est erroné : interrogez les serveurs autoritatifs (depuis un endroit autorisé) et corrigez les données DNS.
Si l’OS est correct mais l’application non : vérifiez le résolveur et les caches du runtime applicatif ; redémarrez/rechargez le service si approprié.

Checklist B: “Stop flushing the wrong cache”

Vérifiez ls -l /etc/resolv.conf. S’il pointe vers le stub de systemd, vous êtes en environnement systemd-resolved.
Vérifiez systemctl is-active systemd-resolved. S’il est inactif, le vider est un placebo.
Vérifiez les couches supplémentaires : systemctl is-active dnsmasq, systemctl is-active nscd.
Utilisez getent ahosts comme base pour « ce que voient les applications basées sur libc ».

Checklist C: “Planned migration with DNS flips”

Réduisez les TTL à l’avance (heures à un jour, selon le comportement de cache de votre environnement).
Documentez quels résolveurs sont utilisés (scopes DHCP, profils VPN, recursors datacenter).
Pendant la fenêtre, vérifiez dans cet ordre :
1. L’autoritatif répond correctement.
2. Chaque résolveur récursif répond correctement et le TTL est raisonnable.
3. Des clients représentatifs via le stub répondent correctement.
4. Les applications résolvent correctement via leur vrai chemin de résolveur.
Ayez un plan de rollback qui ne repose pas sur « vider les caches de tout le monde ». Si votre plan de rollback dépend de l’invalidation manuelle des caches humains, ce n’est pas un plan.

FAQ

1) Quel est le « bon » cache DNS à vider sur Ubuntu 24.04 ?

La plupart du temps : systemd-resolved. Utilisez sudo resolvectl flush-caches, puis vérifiez avec resolvectl query.

2) Pourquoi « redémarrer le réseau » corrige parfois le DNS ?

Parce que cela peut redémarrer ou reconfigurer la pile de résolveur (interfaces, serveurs DNS, domaines de recherche). C’est aussi un instrument grossier qui peut provoquer de nouvelles pannes. Préférez des vérifications ciblées avec resolvectl status.

3) Pourquoi `dig` affiche une réponse alors que `getent` en affiche une autre ?

dig interroge le serveur DNS que vous lui indiquez (ou votre valeur par défaut, selon comment vous l’exécutez). getent suit NSS et utilise souvent le stub local. Ils ne sont équivalents que si vous les faites interroger le même résolveur.

4) Est‑ce que glibc met en cache le DNS sur Ubuntu 24.04 ?

glibc lui‑même ne fournit pas un cache DNS général comme un démon le ferait. La mise en cache se fait typiquement dans systemd-resolved, dnsmasq, nscd, ou à l’intérieur des applications.

5) Comment savoir si `/etc/hosts` écrase le DNS ?

Vérifiez /etc/nsswitch.conf pour l’ordre du champ hosts:, puis recherchez le nom dans /etc/hosts. S’il est présent, le DNS est hors jeu tant que vous ne corrigez pas le fichier.

6) Et le cache DNS du navigateur sur Ubuntu ?

Les navigateurs mettent souvent en cache le DNS et peuvent utiliser leur propre résolveur ou DoH. Si les outils OS montrent la bonne réponse mais que le navigateur ne la montre pas, videz le cache du navigateur ou désactivez/ajustez DoH dans cet environnement.

7) Que faire si j’ai vidé `systemd-resolved` et que la réponse est toujours fausse ?

Alors la mauvaise réponse vient de l’amont ou du DNS autoritatif, ou vous n’utilisez pas systemd-resolved pour ce chemin de requête. Prouvez le comportement en amont avec dig @upstream et inspectez le DNS par interface avec resolvectl status.

8) Le split DNS via VPN peut‑il causer des symptômes ressemblant à un « cache DNS » ?

Oui. Cela peut ressembler à un cache parce que les réponses varient selon l’interface et les domaines routés. Utilisez resolvectl domain et resolvectl dns pour voir où vont les noms.

9) Dois‑je désactiver `systemd-resolved` pour simplifier le DNS ?

Généralement non. Le désactiver peut empirer le DNS VPN et par interface, pas l’améliorer. Si vous avez besoin d’une architecture de résolveur différente (par ex. Unbound localement), faites‑le intentionnellement et documentez‑le. La « simplicité » n’est pas simple si personne ne sait ce qui tourne.

10) Quelle est la méthode la plus sûre pour valider un changement DNS ?

Interrogez l’autoritatif, puis chaque résolveur récursif, puis des clients représentatifs via leur vrai chemin de résolveur. Si une couche diverge, traitez‑la comme l’incident jusqu’à preuve du contraire.

Conclusion : prochaines étapes concrètes à faire aujourd’hui

Arrêtez de traiter les vidages de cache DNS comme une purification spirituelle. Sur Ubuntu 24.04, le cache le plus commun qui compte est systemd-resolved, et le mode de défaillance le plus fréquent est de vider ce cache quand le mensonge vient de l’amont — ou quand l’application ne l’a jamais interrogé.

Faites ceci ensuite :

Sur vos images de flotte, standardisez une pile de résolveur unique (et retirez les couches de cache supplémentaires sauf si vous pouvez les justifier).
Apprenez à votre équipe à utiliser resolvectl status, resolvectl query et getent ahosts comme preuves de base.
Pour chaque incident lié au DNS, enregistrez : la réponse du stub client, la réponse du résolveur en amont, et si l’application utilise le chemin de résolveur OS.
Pour les migrations planifiées, construisez un runbook qui vérifie autoritatif → récursif → client, et inclut un rollback qui ne dépend pas de vider la mémoire des humains.