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

Le modèle réel : où les réponses DNS sont mises en cache sur Ubuntu 24.04

Le DNS sur un hôte Ubuntu moderne est une course de relais, et chaque coureur peut tenir son propre carnet. Quand vous demandez « quel est api.example.internal aujourd’hui ? », la réponse peut venir de :

1) Votre application (oui, votre application)

Beaucoup de runtimes mettent en cache le DNS de façon agressive ou étrange :

• Java : la mise en cache DNS dépend des propriétés de sécurité ; dans certaines configurations, elle peut conserver les entrées indéfiniment.
• Go : peut utiliser le résolveur système ou un résolveur pur-Go selon les flags de compilation et l’environnement ; le comportement varie.
• Python : les bibliothèques peuvent mettre en cache, les clients HTTP peuvent réutiliser des connexions, et les « problèmes DNS » sont parfois des sockets keep-alive obsolètes.
• glibc : historiquement n’offre pas un cache DNS complet, mais a des comportements comme options attempts, timeout, et peut être influencé par des modules NSS.

Si votre application met en cache le DNS, vider systemd-resolved ne servira à rien. Redémarrer l’application peut être nécessaire.

2) NSS (Name Service Switch) et son ordre d’opérations

Le fichier /etc/nsswitch.conf décide si l’hôte vérifie /etc/hosts avant le DNS, s’il utilise mDNS, et plus encore. Une ligne comme :

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

…signifie que /etc/hosts peut remplacer le DNS, et que mDNS peut court-circuiter les résolutions. Quand quelqu’un dit « le DNS ment », ce n’est parfois pas le DNS — c’est NSS qui obéit à vos fichiers locaux.

3) systemd-resolved (le suspect habituel sur Ubuntu 24.04)

Ubuntu 24.04 exécute couramment systemd-resolved et pointe /etc/resolv.conf vers un résolveur stub (souvent 127.0.0.53). Ce stub met en cache les réponses, effectue la validation DNSSEC selon la configuration, peut faire du DNS-over-TLS, et peut router les requêtes par lien (par interface) selon les paramètres réseau.

4) Un résolveur cache local installé volontairement

Certaines environnements déploient dnsmasq, unbound ou bind9 sur des hôtes ou des nœuds. C’est un cache séparé. Vider systemd-resolved ne videra pas unbound. Choquant, je sais.

5) Résolveurs en amont : DNS d’entreprise, résolveurs VPC, kube-dns/CoreDNS, résolveurs ISP

Même si votre hôte est propre, les résolveurs en amont mettent aussi en cache — souvent avec leurs propres TTL minimaux, comportement de préfetch, ou paramètres de cache négatif. Si votre résolveur en amont sert des données périmées, votre hôte ne peut pas « le vider ». Vous ne pouvez que le contourner ou forcer son rafraîchissement (et vous n’aurez peut‑être pas la permission).

6) Boîtiers réseau et produits de sécurité « aidants »

Certains réseaux d’entreprise interceptent le DNS. Certains réécrivent des réponses. Certains bloquent des domaines spécifiques. Si vos paquets n’atteignent jamais le résolveur que vous pensez utiliser, le cache que vous videz est sans importance.

Une idée paraphrasée, parce que c’est toujours le meilleur conseil opérationnel : une idée paraphrasée — on ne peut pas corriger ce que l’on ne peut pas observer (attribué aux thèmes fiabilité/DevOps de Gene Kim).

Règle opérationnelle : Avant de vider quoi que ce soit, prouvez quelle couche a répondu à la question et quel résolveur a réellement été contacté. Sinon vous « réparez » le DNS comme on « répare » les imprimantes : en les rudoyant.

Blague n°1 : Le DNS est le seul système où « c’est en cache » est à la fois une explication et une confession.

Faits intéressants et contexte historique (pourquoi le bazar d’aujourd’hui a du sens)

1. Le caching négatif DNS existe depuis des décennies. Les réponses NXDOMAIN peuvent être mises en cache en utilisant la valeur « minimum » du SOA, donc « ça n’existait pas il y a cinq minutes » peut persister.
2. L’histoire des résolveurs sur Ubuntu a changé plusieurs fois. Entre resolvconf, systemd-resolved, NetworkManager et netplan, l’endroit « correct » pour configurer le DNS dépend de l’époque.
3. /etc/resolv.conf est souvent un lien symbolique désormais. Sur les systèmes systemd il peut pointer vers un fichier stub géré par resolved ; l’éditer directement peut être annulé au redémarrage ou lors d’un changement de lien.
4. glibc a historiquement évité un cache DNS complet. Cette décision a poussé la mise en cache vers des démons dédiés (comme nscd) puis vers systemd-resolved et les applications.
5. Les navigateurs sont devenus leurs propres résolveurs. Les navigateurs modernes effectuent un caching agressif, du prefetching, et parfois du DNS-over-HTTPS ; « fonctionne avec dig » ne garantit pas « fonctionne dans Chrome ».
6. Le TTL n’est pas une promesse ; c’est un indice. Certains résolveurs plafonnent les TTLs (mini/maxi), et certains clients étendent le caching selon des politiques internes.
7. Le DNS à horizon partagé (split-horizon) est une fonctionnalité, pas un bug. Le même nom peut légitimement résoudre différemment selon le réseau source ; la « mauvaise » réponse peut être la bonne pour une autre interface.
8. L’IPv6 peut « gagner » même quand vous ne le voulez pas. Beaucoup de clients essayent AAAA en premier ; si votre chemin IPv6 est cassé, ça ressemble à de l’instabilité DNS.
9. systemd-resolved peut router le DNS par lien. VPN activé ? Maintenant la moitié de vos noms va au résolveur VPN et l’autre moitié au résolveur LAN, selon les domaines de routage.

Playbook de diagnostic rapide (vérifiez ceci en premier, dans l’ordre)

Voici le chemin le plus court vers la vérité quand « le DNS est erroné » sur Ubuntu 24.04. Ne improvisez pas. Suivez la chaîne.

Étape 1 : Identifiez ce que fait réellement l’application

• Utilise-t-elle le résolveur système (glibc/NSS) ou un résolveur interne (navigateur, JVM, Go netgo) ?
• Le « problème DNS » est-il en réalité un pool de connexions TCP obsolète ?
• S’exécute-t-elle dans un conteneur avec son propre /etc/resolv.conf ?

Étape 2 : Prouvez la pile de résolveur de l’hôte

• /etc/resolv.conf est-il un stub vers 127.0.0.53 ?
• systemd-resolved est-il actif ?
• Y a-t-il dnsmasq, unbound, nscd impliqués ?

Étape 3 : Comparez les réponses entre les chemins

• Comparez getent hosts (chemin NSS) vs dig @server (résolveur direct) vs le comportement de l’app.
• Vérifiez A et AAAA, et confirmez lequel est utilisé.

Étape 4 : Si c’est du caching, trouvez quel cache

• Videz systemd-resolved seulement s’il s’agit de la couche en jeu.
• Si le résolveur en amont est périmé, contournez-le ou interrogez les résolveurs autoritaires/alternatifs pour confirmer.
• Si l’app met en cache, redémarrez ou reconfigurez l’app — n’utilisez pas l’OS comme une massue.

Étape 5 : Validez sur le réseau

• Utilisez tcpdump sur le port 53 (ou 853 pour DoT) pour voir si les requêtes quittent la machine.
• Si aucun paquet ne part, vous n’êtes pas face à un problème de « serveur DNS » ; vous avez un mécanisme de résolution local.

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

Ces tâches sont conçues pour être exécutées sur des serveurs et postes Ubuntu 24.04. Chaque tâche inclut (1) une commande, (2) ce que la sortie signifie, et (3) la décision suivante.

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

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

Signification : Vous utilisez le stub de systemd-resolved. La plupart des applications interrogeront 127.0.0.53, pas directement vos serveurs DNS en amont.

Décision : Arrêtez d’éditer /etc/resolv.conf manuellement. Inspectez la configuration de resolved et le DNS par lien.

Task 2: Confirm systemd-resolved is active

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 Fri 2025-12-26 10:12:01 UTC; 2h 41min ago
       Docs: man:systemd-resolved.service(8)

Signification : Un stub cache local est en jeu.

Décision : Utilisez resolvectl comme outil de diagnostic principal ; vider resolved peut être pertinent.

Task 3: Find the actual upstream DNS servers resolved is using

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
        DNS Domain: corp.internal

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.internal

Signification : Les serveurs en amont sont 10.20.0.53/54, et il existe un domaine de routage (corp.internal).

Décision : Si les réponses sont périmées, vous devez déterminer si la périmée vient du cache de resolved ou de 10.20.0.53.

Task 4: Compare the NSS path vs direct DNS query

cr0x@server:~$ getent hosts api.corp.internal
10.50.12.19     api.corp.internal

cr0x@server:~$ dig +short api.corp.internal
10.50.12.19

Signification : Pour l’instant, NSS et le stub resolver sont d’accord.

Décision : Si l’application touche encore une ancienne IP, suspectez le caching côté application ou la réutilisation de connexions.

Task 5: Bypass the stub and query the upstream server directly

cr0x@server:~$ dig @10.20.0.53 api.corp.internal +noall +answer +ttlid
api.corp.internal.  30  IN  A  10.50.12.19

Signification : Le résolveur en amont renvoie 10.50.12.19 avec TTL 30 secondes.

Décision : Si votre hôte renvoie autre chose, le problème est local (caching/routage). Si l’amont est erroné, vider localement est de la scénographie.

Task 6: Check whether /etc/hosts is overriding DNS

cr0x@server:~$ grep -n 'api.corp.internal' /etc/hosts || true
12:10.10.10.10 api.corp.internal

Signification : Vous avez une substitution codée en dur. NSS retournera probablement ceci avant le DNS.

Décision : Supprimez ou corrigez l’entrée, puis retestez avec getent hosts. Vider les caches ne réparera pas un fichier.

Task 7: Inspect NSS order for host lookups

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

Signification : files (aka /etc/hosts) vient en premier. mDNS peut intercepter certains noms.

Décision : Si vous poursuivez un nom pouvant être traité par mDNS (.local), testez avec et sans. Si la politique interdit les surprises mDNS, ajustez l’ordre.

Task 8: Flush systemd-resolved cache (only when it’s the right layer)

cr0x@server:~$ sudo resolvectl flush-caches

Signification : Resolved supprime les réponses positives et négatives en cache.

Décision : Relancez immédiatement resolvectl query name ou getent hosts. Si les réponses ne changent pas, le « mensonge » n’est pas dans le cache de resolved.

Task 9: Show cache statistics (is the cache even being used?)

cr0x@server:~$ resolvectl statistics
DNSSEC Verdicts:                 Secure=0 Insecure=0 Bogus=0 Indeterminate=0
Cache:                           Current Cache Size=42 Max Cache Size=4096
Cache Hits:                      118
Cache Misses:                    67
Cache Evictions:                 0
DNS Transactions:                79

Signification : Resolved met en cache et sert des hits. Si les hits sont élevés et que des réponses erronées persistent, vider peut aider — sauf si la mauvaise réponse est re-récupérée depuis l’amont.

Décision : Si les hits du cache sont proches de zéro, votre problème est probablement ailleurs : caching applicatif ou un autre résolveur.

Task 10: Query through resolved with verbose details

cr0x@server:~$ resolvectl query api.corp.internal
api.corp.internal: 10.50.12.19                       -- link: ens160

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

Signification : Il montre quel lien/interface a été utilisé. C’est critique quand il y a des VPNs ou plusieurs NICs.

Décision : Si la requête sort par le « mauvais » lien, corrigez les paramètres DNS par lien (netplan/NetworkManager/systemd-networkd), pas les caches.

Task 11: Catch DNS on the wire (prove whether queries leave the host)

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:41:15.219233 ens160 Out IP 10.20.1.44.53344 > 10.20.0.53.53: 12345+ A? api.corp.internal. (35)
10:41:15.245090 ens160 In  IP 10.20.0.53.53 > 10.20.1.44.53344: 12345 1/0/0 A 10.50.12.19 (51)

Signification : Les requêtes partent vers 10.20.0.53 et les réponses reviennent. Si votre application voit encore une IP différente, le problème est au‑dessus du chemin du résolveur OS (cache applicatif ou réutilisation de connexion) ou une différence split-horizon dans l’environnement applicatif.

Décision : Si vous ne voyez aucune requête sortante lors des recherches, vous touchez un cache local ou un mécanisme complètement différent (comme DoH dans un navigateur).

Task 12: Check if DoT (port 853) is used

cr0x@server:~$ sudo tcpdump -ni any 'tcp port 853'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:43:50.102991 ens160 Out IP 10.20.1.44.42132 > 10.20.0.53.853: Flags [S], seq 205383221, win 64240, options [mss 1460,sackOK,TS val 151512 ecr 0,nop,wscale 7], length 0

Signification : Vous utilisez DNS-over-TLS. Certains boîtiers et outils supposent UDP/53 uniquement ; ils vous induiront en erreur.

Décision : Lors du diagnostic « DNS bloqué », vérifiez les règles de pare‑feu pour le port 853 et confirmez la prise en charge côté résolveur.

Task 13: Validate what a container sees (Docker example)

cr0x@server:~$ sudo docker run --rm alpine:3.20 cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

Signification : Les conteneurs peuvent utiliser le DNS embarqué de Docker (127.0.0.11), qui est sa propre couche de cache/forwarding.

Décision : Si seuls les conteneurs sont affectés, arrêtez de vider les caches de l’hôte et inspectez la configuration DNS des conteneurs et du moteur.

Task 14: See what IPs your app is actually connecting to

cr0x@server:~$ sudo ss -tnp | grep ':443' | head
ESTAB 0 0 10.20.1.44:50412 10.10.10.10:443 users:(("myapp",pid=23144,fd=27))

Signification : L’application est connectée à 10.10.10.10. Si le DNS dit 10.50.12.19, vous pouvez avoir un pool de connexions périmé, un résultat résolu ancien dans le processus, ou une substitution /etc/hosts.

Décision : Redémarrez l’application ou recyclez son pool de connexions ; ne blâmez pas le DNS tant que vous n’avez pas prouvé qu’une nouvelle résolution a lieu.

Task 15: Check for nscd (another caching layer)

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

Signification : nscd n’est pas actif. Bien : un cache de moins à gérer.

Décision : S’il est actif dans votre environnement, apprenez comment il met en cache et videz-le intentionnellement ; sinon vous courrez après des fantômes.

Task 16: Identify who owns port 53 locally (conflicts)

cr0x@server:~$ sudo ss -lunp | grep ':53 ' || true
UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=862,fd=13))

Signification : Le stub resolver écoute. Si vous attendiez dnsmasq sur 127.0.0.1:53, il y a une incohérence.

Décision : Ne lancez pas plusieurs démons DNS locaux sans plan ; décidez quel processus possède le stub et comment les clients doivent y accéder.

Task 17: Check for negative caching (NXDOMAIN) that might be stuck

cr0x@server:~$ resolvectl query doesnotexist.corp.internal
doesnotexist.corp.internal: resolve call failed: 'does not exist'

Signification : NXDOMAIN est en jeu. Si ce nom vient juste d’être créé, vous luttez peut‑être contre un cache négatif en amont ou local.

Décision : Videz les caches locaux, puis interrogez l’amont directement. Si l’amont renvoie toujours NXDOMAIN, le changement DNS n’a pas encore été propagé là‑bas.

Vider le bon cache (et pourquoi les conseils habituels sont faux)

Le mauvais conseil classique est : « Sur Linux, exécutez sudo systemctl restart networking » ou « redémarrez NetworkManager » ou « éditez /etc/resolv.conf et mettez 8.8.8.8 ». Ce conseil a sa place dans un musée à côté des modems dial‑up.

Ce que « vider le DNS » peut signifier sur Ubuntu 24.04

• Vider systemd-resolved : sudo resolvectl flush-caches
• Redémarrer resolved (plus lourd) : sudo systemctl restart systemd-resolved
• Vider le cache DNS du navigateur : pas une commande OS ; c’est une action dans le navigateur
• Vider le DNS embarqué Docker : nécessite souvent de redémarrer les conteneurs ou le démon ; ce n’est pas le stub de l’hôte
• Vider le résolveur en amont : nécessite l’accès à ce résolveur ; vous ne pouvez pas le faire depuis une machine cliente

Comment choisir le bon vidage

Utilisez cet arbre de décision :

1. Si getent hosts name est erroné mais dig @upstream name est correct : videz systemd-resolved (et vérifiez les domaines de routage par lien).
2. Si getent est correct mais votre application est erronée : c’est probablement du cache applicatif, des connexions persistantes obsolètes, ou un chemin de résolveur différent (DoH, netgo, JVM).
3. Si dig @upstream est erroné : vider localement ne servira à rien. Mettez en escalade auprès des propriétaires DNS ou contournnez pour valider ; ne continuez pas à vider les clients.
4. Si les conteneurs sont erronés mais l’hôte est correct : vous êtes en territoire DNS conteneur (127.0.0.11, kube-dns, CoreDNS, node-local-dns).

Le seul « vidage » que vous devriez faire par défaut

Aucun. Le vidage par défaut est du travail inutile. Votre comportement par défaut devrait être de prouver le chemin, puis vider la couche qui met réellement en cache.

Blague n°2 : Redémarrer NetworkManager pour réparer le DNS, c’est comme redémarrer le bureau parce qu’il y a une faute de frappe.

Trois mini-récits d’entreprise issus des tranchées DNS

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« j’ai vidé le DNS, toujours cassé »)

Une entreprise SaaS de taille moyenne a déployé un nouvel endpoint API interne derrière un load balancer. Le changement était propre : mise à jour du DNS d’un ancien VIP vers le nouveau, TTL fixé à 30 secondes, et une fenêtre de migration lente. L’on‑call a lancé dig et a vu la nouvelle IP immédiatement. Élan de victoire.

Mais les serveurs d’application continuaient d’appeler l’ancien VIP pendant encore une heure. Certaines requêtes réussissaient (parce que l’ancien VIP servait encore quelque chose), d’autres tombaient sur un pool de backends morts et retournait des timeouts. Le canal d’incident s’est rempli de « le DNS est caché quelque part ». Quelqu’un a vidé systemd-resolved sur un sous-ensemble de serveurs. Aucun changement.

La mauvaise hypothèse : que l’application utilisait le résolveur OS à chaque requête. Ce n’était pas le cas. L’application était un service JVM avec une configuration de cache DNS héritée d’une ancienne image de base. Elle mettait en cache les résultats positifs plus longtemps que tout le monde ne s’en souvenait, et le service utilisait un pool de connexions persistant qui ne ré‑résolvait pas de toute façon.

La correction n’a pas été « vider le DNS ». La correction fut : réduire le TTL de cache DNS dans la JVM pour ce service, ajouter une étape de déploiement « recycler le pool de connexions » lors des changements d’endpoint, et améliorer les runbooks pour que « dig dit X » ne mette pas fin à l’investigation.

Ils ont aussi appris une leçon douloureuse : le TTL DNS n’oblige pas les clients à se comporter. Il le suggère poliment. Les systèmes de production ne sont pas connus pour leur politesse.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (cache local partout)

Une grande entreprise avec un mesh de microservices bavard a décidé de réduire la charge sur les résolveurs centraux. Idée rationnelle : installer un résolveur cache local sur chaque VM. Ils ont choisi un forwarder léger avec des valeurs de cache agressives. La latence a amélioré sur des tests synthétiques. Les graphes des résolveurs semblaient plus calmes. Tout le monde est rentré chez soi à l’heure pendant deux semaines.

Puis ils ont eu un incident de réponse sécurité où ils devaient rediriger rapidement un ensemble de noms de service loin d’un segment réseau compromis. Les changements DNS ont été faits au central. Certains nœuds ont mis à jour rapidement, d’autres pas. Le plan « cache partout » était devenu « incohérence partout ».

Ce qui les a mordus n’était pas seulement le caching positif. Le caching négatif et le comportement serve-stale (configuré pour masquer les flaps en amont) faisaient que certains hôtes continuaient à renvoyer de vieilles réponses même quand l’amont avait changé. Le but du DNS — indirection rapide — avait été émoussé par un « tuning » de performance.

La correction a nécessité deux changements : des plafonds de TTL pilotés par politique (ne pas étendre au-delà du TTL autoritatif pour les noms critiques), et un levier opérationnel clair pour invalider les caches pour des zones spécifiques pendant des incidents. Ils ont conservé le cache local, mais l’ont traité comme une infrastructure de production avec contrôle de changement et observabilité, pas comme un « hack » de performance.

La leçon : les caches ne sont pas gratuits. Ce sont de petites bases de données distribuées avec une personnalité.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (prouver sur le réseau)

Une équipe fintech exploitait Ubuntu 24.04 sur un mélange de bare metal et de VMs. Un matin, un sous-ensemble de nœuds n’arrivait plus à atteindre l’API d’un partenaire de paiement après un changement DNS côté partenaire. Le partenaire jurait que le DNS avait été mis à jour. Le dig de l’équipe sur un hôte était d’accord. D’autres hôtes ne l’étaient pas. L’angoisse est arrivée tôt.

L’on‑call a suivi une routine ennuyeuse mais fiable : d’abord resolvectl status pour confirmer les serveurs en amont ; ensuite getent hosts pour le comportement NSS ; enfin dig @upstream. Les résultats ont été cohérents : certains nœuds interrogeaient un résolveur d’entreprise, d’autres un autre, à cause d’un routage DNS par lien après un événement de bascule VPN.

Ils n’ont pas « vidé le DNS et prié ». Ils ont capturé un court tcpdump montrant exactement quel résolveur chaque hôte affecté interrogeait et les réponses renvoyées. Cette capture de paquets a clos le débat en dix minutes, parce que les paquets ne font pas de politique.

Une fois la cause racine — chemins de résolveur séparés — claire, ils ont corrigé la configuration réseau pour que tous les nœuds utilisent la même paire de résolveurs pour ce domaine de routage, et ajouté une surveillance qui vérifie la liste des serveurs DNS par lien de resolved pour détecter les dérives.

Ce n’était pas glamour. C’était correct. Et ça a évité des heures d’accusations entre l’équipe applicative, l’équipe réseau et un partenaire externe.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: dig shows new IP, app still uses old IP

Cause racine : Cache DNS côté application ou réutilisation persistante des connexions (pooling/keep-alive). Parfois l’app ne résout plus après le démarrage.

Correction : Vérifiez avec ss -tnp quelle IP est connectée ; recyclez l’app/pool ; configurez le TTL DNS du runtime ; assurez-vous que les résolutions ont lieu par requête quand c’est nécessaire.

2) Symptom: Flushing systemd-resolved changes nothing

Cause racine : Le mauvais cache. Soit l’amont est périmé, soit le client n’utilise pas resolved (conteneurs, DoH, résolveur custom).

Correction : Interrogez l’amont directement avec dig @server ; vérifiez /etc/resolv.conf des conteneurs ; capturez le trafic DNS avec tcpdump.

3) Symptom: Only some interfaces/nodes resolve internal domains

Cause racine : Routage DNS par lien / domaines split-horizon ; VPN ou NIC secondaire a modifié les domaines de routage de resolved.

Correction : Utilisez resolvectl status et resolvectl query pour voir quel lien a répondu ; corrigez la configuration netplan/NetworkManager pour que la bonne interface possède le domaine.

4) Symptom: Name “does not exist” after you just created it

Cause racine : Caching négatif (local ou en amont). Votre résolveur a mis en cache NXDOMAIN selon les paramètres SOA.

Correction : Videz les caches locaux ; interrogez plusieurs résolveurs en amont ; attendez la fin du TTL négatif ou invalidez le cache en amont si vous le contrôlez.

5) Symptom: getent hosts returns a weird IP that dig doesn’t

Cause racine : Substitution dans /etc/hosts ou ordre NSS / interception mDNS.

Correction : Inspectez /etc/hosts et /etc/nsswitch.conf ; supprimez les overrides périmés ; relancez getent hosts.

6) Symptom: IPv4 works sometimes, IPv6 fails and it “looks like DNS”

Cause racine : Enregistrement AAAA présent ; le client préfère IPv6 ; le chemin IPv6 est cassé.

Correction : Vérifiez dig AAAA name ; validez la connectivité IPv6 ; corrigez le routage/pare‑feu ou ajustez la politique du client.

7) Symptom: Containers fail to resolve, host resolves fine

Cause racine : Couche DNS du runtime conteneur (127.0.0.11) ou configuration DNS Kubernetes ; le cache node-local peut différer.

Correction : Inspectez /etc/resolv.conf dans les conteneurs ; testez la résolution depuis l’intérieur du conteneur ; ajustez la configuration du démon/kube DNS au lieu des caches hôte.

8) Symptom: DNS queries time out sporadically

Cause racine : Pare‑feu, problèmes MTU, ou atteignabilité du résolveur ; parfois le fallback TCP est bloqué ; parfois DoT est bloqué.

Correction : Utilisez tcpdump pour voir les retries ; testez TCP/53 et TCP/853 ; confirmez le routage et les règles de sécurité.

Checklists / plan étape par étape

Incident checklist: “DNS is wrong on Ubuntu 24.04”

1. Confirmez ce que vous testez : Testez‑vous l’application, NSS ou le DNS direct ?
2. Vérifiez le mode résolveur : ls -l /etc/resolv.conf et systemctl status systemd-resolved.
3. Inspectez le DNS par lien : resolvectl status.
4. Comparez les réponses : getent hosts name vs dig name vs dig @upstream name.
5. Vérifiez les overrides : grep name /etc/hosts et grep '^hosts:' /etc/nsswitch.conf.
6. Videz seulement si justifié : sudo resolvectl flush-caches.
7. Validez sur le réseau : tcpdump pour le port 53/853 pendant les requêtes.
8. Si le mismatch applicatif persiste : confirmez les connexions (ss -tnp), redémarrez/recyclez l’app/pool, et inspectez le caching runtime.
9. Si l’amont est périmé : escaladez aux propriétaires DNS ou contournez pour valider ; ne continuez pas à vider les clients.

Prevention checklist: stop future “DNS lies”

1. Standardisez la propriété des résolveurs : décidez si resolved est le stub partout, ou si vous exécutez un résolveur local dédié. N’utilisez pas les deux par accident.
2. Définissez des attentes TTL sensées : documentez les TTL que votre organisation utilise pour les noms critiques et comment les caches peuvent les plafonner.
3. Opérationnalisez les changements DNS : pour les migrations d’endpoint, incluez des étapes de redémarrage/appel de recycle du pool applicatif quand les clients peuvent mettre en cache.
4. Surveillez la dérive des résolveurs : alertez si les serveurs DNS par lien diffèrent de l’attendu (surtout après des événements VPN).
5. Séparez « résolution de noms » et « connectivité » dans les runbooks : vérifiez toujours l’IP réellement connectée et la route, pas seulement les réponses DNS.
6. Formez les équipes sur NSS : faites de getent l’outil par défaut « ce que verront les applications ? ».

FAQ

1) On Ubuntu 24.04, what is the correct command to flush DNS?

Si vous utilisez systemd-resolved (courant sur 24.04), utilisez sudo resolvectl flush-caches. Mais seulement après avoir prouvé que resolved est la couche de cache dans votre chemin.

2) Why does dig show one IP but my application uses another?

dig est un client DNS direct ; votre application utilise probablement NSS et la pile résolveur système, ou elle met en cache en‑processus, ou elle réutilise des connexions existantes. Comparez getent hosts et vérifiez les connexions actives avec ss -tnp.

3) Is restarting systemd-resolved better than flushing caches?

Redémarrer est plus lourd et peut perturber brièvement la résolution. Préférez resolvectl flush-caches d’abord. Redémarrez seulement si resolved est bloqué (rare) ou si vous avez changé sa configuration.

4) Why shouldn’t I edit /etc/resolv.conf directly?

Parce que sur Ubuntu 24.04 c’est souvent un lien géré par systemd/netplan/NetworkManager. Vos modifications peuvent disparaître au reboot ou lors d’un changement de lien, et vous déboguerez le fichier d’hier.

5) What’s the best “truth” command for what the system will resolve?

getent hosts name. Il suit les règles NSS, incluant /etc/hosts, mDNS, et le DNS via la pile résolveur configurée.

6) Can systemd-resolved route DNS differently for different interfaces?

Oui. Il peut sélectionner des serveurs DNS et des domaines de recherche par lien. C’est une cause fréquente de « certains nœuds fonctionnent, d’autres non », surtout avec les VPN.

7) How do I know if the cache problem is upstream and not local?

Interrogez le serveur en amont directement : dig @DNS_SERVER name. Si l’amont est erroné, vider les caches locaux ne changera pas la réponse.

8) Why does a newly created DNS record still return NXDOMAIN?

Caching négatif. Les réponses NXDOMAIN peuvent être mises en cache selon les paramètres SOA. Videz les caches locaux, puis vérifiez l’amont ; si l’amont renvoie toujours NXDOMAIN, attendez ou invalidez le cache amont si vous le contrôlez.

9) My host resolves fine but containers don’t. Why?

Les conteneurs utilisent souvent une adresse résolveur différente (comme le 127.0.0.11 de Docker) et des règles de forwarding différentes. Diagnostiquez depuis l’intérieur du conteneur et corrigez la couche DNS conteneur — pas le stub de l’hôte.

10) How can I prove which resolver IP my host is using without guessing?

resolvectl status montre le serveur DNS courant et les serveurs DNS par lien. Associez cela à tcpdump pour confirmer que le trafic va bien où vous pensez.

Conclusion : prochaines étapes qui font réellement avancer les choses

Si vous ne retenez qu’une habitude opérationnelle de ce cas : arrêtez de dire « vider le DNS » comme si c’était un levier unique. Sur Ubuntu 24.04 c’est une pile. Votre travail est d’identifier quelle couche ment — ou plus souvent, quelle couche répète fidèlement une vérité périmée qu’elle a apprise précédemment.

Faites ceci la prochaine fois, dans cet ordre :

1. Utilisez getent hosts pour voir ce que verront les applications.
2. Utilisez resolvectl status et resolvectl query pour voir quel lien et quel résolveur en amont sont impliqués.
3. Utilisez dig @upstream pour séparer le cache local de la péremption en amont.
4. Utilisez tcpdump quand les débats commencent. Les paquets tranchent les débats.
5. Videz seulement le cache dont vous avez prouvé la présence dans le chemin.

Et quand quelqu’un suggère de redémarrer des services réseau au hasard parce que « le DNS est bizarre », fournissez‑lui une capture de paquets et une copie de votre runbook. Doucement. Vous devrez encore travailler avec cette personne demain.