Ubuntu 24.04 « Échec temporaire de résolution de nom » : arrêtez de deviner et réparez le DNS correctement

novembre 24, 2025 • février 3, 2026 • Lecture : 25 min • Views: 6

Cet article vous a aidé ?

Si vous voyez Temporary failure in name resolution sur Ubuntu 24.04, vous perdez déjà du temps de la pire manière possible : le système est en ligne, l’application est en panne, et tout le monde reproche « le réseau ».

Cette erreur n’est presque jamais mystique. C’est généralement une rupture très précise entre votre application et la chaîne de résolution : libc → NSS → systemd-resolved → DNS en amont (ou un stub local) → routage/pare-feu → serveur de noms réel. La solution n’est pas « essayer 8.8.8.8 et espérer ». La solution consiste à mesurer chaque saut puis changer la seule chose qui est réellement défaillante.

Ce que l’erreur signifie réellement (et ce qu’elle ne signifie pas)

Temporary failure in name resolution est typiquement renvoyé par la couche résolveur quand une requête DNS ne peut pas être complétée pour le moment. En termes POSIX, c’est souvent EAI_AGAIN provenant de getaddrinfo(). Le système dit : « J’ai essayé de résoudre un nom et je n’ai pas réussi à atteindre une chaîne de résolution fonctionnelle. »

Ce que cela ne veut pas dire :

« L’internet est coupé. » Votre route par défaut peut très bien fonctionner.
« Le DNS est mal configuré. » Parfois les paramètres DNS sont corrects, mais UDP/53 est bloqué, le MTU est erroné, ou vous routez vers la mauvaise interface.
« C’est forcément la faute de systemd-resolved. » C’est souvent juste le messager.

Ce que cela signifie généralement en production :

Votre machine ne sait pas lesquels serveurs DNS interroger (mauvaise config, config vide, config écrasée).
Votre machine sait quels serveurs interroger, mais ne peut pas les atteindre (routage, pare-feu, VPN, lien cassé, indisponibilité du serveur DNS).
Votre machine atteint un serveur DNS qui répond parfois (timeouts, perte de paquets, problèmes EDNS/MTU, amont instable).
Votre machine interroge le mauvais serveur DNS pour le nom (split DNS, domaines de recherche, mauvaise priorité d’interface).

Une citation à garder au mur (idée paraphrasée) : « L’espoir n’est pas une stratégie » — maxime SRE largement répétée et souvent attribuée aux responsables opérations. Le DNS mérite la même énergie : mesurer, ne pas deviner.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est le chemin le plus rapide vers le goulot d’étranglement. Exécutez-le dans l’ordre. Ne passez pas aux « corrections » tant que vous ne pouvez pas nommer le saut défaillant.

Premier : est-ce le DNS ou le routage ?

Résolvez un nom via le résolveur système (getent). Si cela échoue, poursuivez.
Résolvez via un serveur DNS connu et sain (dig @x.x.x.x). Si cela fonctionne, votre réseau en amont est OK et votre chaîne de résolveur locale est cassée.
Faites un ping vers une IP connue (comme votre passerelle par défaut ou une IP publique si autorisé). Si la connectivité IP est cassée, DNS n’est qu’un symptôme.

Deuxième : systemd-resolved est-il sain et pointé vers quelque chose de raisonnable ?

resolvectl status : vérifiez quels serveurs DNS sont utilisés par lien et globalement.
ls -l /etc/resolv.conf : confirmez si vous utilisez le résolveur stub ou un fichier statique, et si cela correspond à votre intention.
systemctl status systemd-resolved : confirmez qu’il tourne et n’est pas bloqué dans une boucle.

Troisième : le serveur DNS choisi est-il joignable et répond-il ?

Testez la joignabilité UDP/TCP vers le serveur DNS (les timeouts importent plus que les « refusés »).
Interrogez avec dig pour les enregistrements A et AAAA ; comparez les comportements. L’IPv6 fonctionne souvent juste assez pour vous faire perdre un après-midi.
Si split DNS : assurez-vous que la requête sort par l’interface prévue et avec les bonnes règles de routage de domaine.

Blague sèche #1 : le DNS est le seul système où « ce n’est qu’un nom » peut faire tomber la paie.

Pile DNS Ubuntu 24.04 en pratique

Ubuntu 24.04 (comme les versions récentes d’Ubuntu) utilise typiquement :

Netplan pour définir la configuration réseau (YAML sous /etc/netplan/).
systemd-networkd ou NetworkManager comme backend réseau, selon serveur/bureau et votre configuration.
systemd-resolved comme résolveur stub local en cache, généralement lié à 127.0.0.53.
NSS (Name Service Switch) règles dans /etc/nsswitch.conf déterminant si les recherches utilisent DNS, files, mDNS, etc.
/etc/resolv.conf comme interface de compatibilité pour les outils hérités. Sur un Ubuntu moderne, c’est souvent un lien symbolique vers un fichier géré par systemd.

Voici le modèle mental pratique. Quand une application demande « quel est repo.internal.corp ? »

L’application appelle getaddrinfo().
glibc consulte /etc/nsswitch.conf (ligne hosts:) et choisit les méthodes.
Pour le DNS, glibc lit /etc/resolv.conf et utilise cette liste de nameservers.
Si ce fichier pointe vers 127.0.0.53, les requêtes vont à systemd-resolved.
systemd-resolved choisit un serveur DNS en amont basé sur la configuration par interface et les domaines de routage, puis émet la requête.

Donc quand vous « éditez resolv.conf », vous pourriez modifier un lien symbolique qui sera écrasé, ou vous pourriez contourner le chemin de résolveur prévu. Vous pouvez le faire fonctionner temporairement et créer un piège pour le Vous du futur.

Faits intéressants et contexte historique (court mais utile)

Le DNS précède la carrière de la plupart. Il a été conçu au début des années 1980 comme remplacement distribué d’un unique fichier HOSTS.TXT que tout le monde devait télécharger.
« resolv.conf » est un fossile qui refuse de mourir. C’est toujours l’interface universelle même si les systèmes modernes ont des règles DNS dynamiques par lien.
systemd-resolved a introduit un stub local par défaut. C’est pourquoi vous voyez souvent nameserver 127.0.0.53 — ce n’est pas « faux », c’est une couche d’indirection.
Le DNS sur UDP est rapide jusqu’à ce qu’il ne le soit plus. La perte de paquets transforme le « rapide » en « mystérieusement lent », car les retransmissions et timeouts s’empilent à travers bibliothèques et applis.
La bascule vers TCP compte plus que les gens ne l’admettent. Les réponses volumineuses, DNSSEC ou certains middleboxes peuvent forcer TCP/53, et si TCP est bloqué vous obtenez des timeouts qui ressemblent à des pannes aléatoires.
Les domaines de recherche sont des outils de productivité et des générateurs d’incidents. Un point manquant peut déclencher plusieurs requêtes (api devient api.prod.corp, api.corp, etc.), ajoutant latence et confusion.
La mise en cache négative existe. Si votre résolveur met en cache « NXDOMAIN » et que vous venez de créer un enregistrement, vous pouvez passer tout le TTL à vous disputer avec la réalité.
Le split DNS est devenu courant à cause des VPN et du SaaS. Votre laptop/serveur peut avoir besoin du DNS public pour le monde et du DNS privé pour les noms internes, simultanément.
Les valeurs par défaut d’Ubuntu ont évolué dans le temps. Les anciennes versions utilisaient resolvconf ou des écritures DHCP directes ; les modernes préfèrent les outils systemd. Copier-coller d’anciens playbooks peut casser des choses silencieusement.

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

Voici des tâches réelles que j’exécuterais sur un serveur Ubuntu 24.04 pendant un incident. Chacune inclut : commande, sortie exemple, ce que cela signifie, et la décision à prendre.

Task 1: Confirm the symptom using the system resolver (not ping)

cr0x@server:~$ getent ahosts archive.ubuntu.com
getent: Name or service not known

Sens : Ceci utilise libc/NSS et reflète ce que vivent la plupart des applications. « Name or service not known » ou des timeouts ici confirment que ce n’est pas juste ping qui est bizarre.

Décision : Poursuivez le débogage de la chaîne de résolveur. Si getent fonctionne mais que votre appli échoue, suspectez des paramètres DNS spécifiques à l’application (containers, chroot, bibliothèques de résolveur personnalisées).

Task 2: Check whether IP routing works at all

cr0x@server:~$ ip route
default via 10.0.0.1 dev ens3 proto dhcp src 10.0.0.42 metric 100
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.42

Sens : Vous avez une route par défaut via 10.0.0.1. S’il n’y a pas de route par défaut, le DNS peut échouer parce que rien n’atteint les serveurs en amont.

Décision : Si la route par défaut est absente/incorrecte, corrigez d’abord le réseau (Netplan, DHCP, état de l’interface) avant de toucher au DNS.

Task 3: Ping the default gateway (local L2 sanity)

cr0x@server:~$ ping -c 2 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.391 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.412 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.391/0.401/0.412/0.010 ms

Sens : L2/L3 vers la passerelle est OK. Les échecs DNS sont moins susceptibles d’être « la carte réseau est morte ».

Décision : Montez dans la pile : configuration du résolveur et joignabilité DNS.

Task 4: Inspect /etc/resolv.conf (symlink tells the story)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 May  8 10:14 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Sens : Cet hôte utilise le résolveur stub systemd à 127.0.0.53. Si vous « corrigez le DNS » en éditant /etc/resolv.conf directement, il sera probablement écrasé ou ignoré.

Décision : Utilisez resolvectl et la configuration Netplan/NetworkManager plutôt que d’éditer le fichier à la main.

Task 5: Verify systemd-resolved is running and not degraded

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 Wed 2025-12-18 09:51:22 UTC; 2h 13min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18712)
     Memory: 7.9M
        CPU: 1.231s
     CGroup: /system.slice/systemd-resolved.service
             └─812 /usr/lib/systemd/systemd-resolved

Sens : Le service est actif. Cela ne garantit pas que l’amont DNS est joignable, mais écarte « le démon résolveur planté ».

Décision : Regardez la configuration du résolveur et la joignabilité en amont ensuite.

Task 6: Check resolver configuration with resolvectl

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

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.internal

Sens : Les serveurs DNS sont 10.0.0.53 et 10.0.0.54 ; domaine de recherche corp.internal. Cela semble plausible. Si cela n’affiche aucun serveur DNS, vous avez trouvé le problème.

Décision : Si les serveurs DNS sont vides ou incorrects, corrigez Netplan/DHCP/NetworkManager. S’ils semblent corrects, testez la joignabilité et le comportement des réponses.

Task 7: Query through systemd-resolved explicitly

cr0x@server:~$ resolvectl query archive.ubuntu.com
archive.ubuntu.com: resolve call failed: Temporary failure in name resolution

Sens : Cela confirme que l’échec se produit au niveau de systemd-resolved ou au-delà (pas un réglage DNS spécifique à l’appli).

Décision : Interrogez directement les serveurs DNS en amont pour séparer « resolved » du « réseau amont ».

Task 8: Query the upstream DNS server directly with dig (bypass the stub)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Sens : Le serveur DNS configuré n’est pas joignable (ou ne répond pas). Ce n’est pas un problème de configuration de systemd-resolved ; c’est un problème de connectivité ou côté serveur DNS.

Décision : Vérifiez le routage vers le serveur DNS, les règles du pare-feu, l’état du VPN, et si le serveur DNS est vivant.

Task 9: Confirm you can reach the DNS server at the network layer

cr0x@server:~$ ping -c 2 10.0.0.53
PING 10.0.0.53 (10.0.0.53) 56(84) bytes of data.
64 bytes from 10.0.0.53: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.0.0.53: icmp_seq=2 ttl=63 time=1.09 ms

--- 10.0.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1014ms
rtt min/avg/max/mdev = 1.09/1.10/1.12/0.015 ms

Sens : Le serveur est joignable par ICMP. Cela ne prouve pas que UDP/53 ou TCP/53 est autorisé, mais c’est un bon signe.

Décision : Testez explicitement UDP et TCP pour le DNS.

Task 10: Test UDP/53 and TCP/53 behavior (because middleboxes exist)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +tcp

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41861
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;archive.ubuntu.com.          IN      A

;; ANSWER SECTION:
archive.ubuntu.com.   60      IN      A       91.189.91.81

;; Query time: 24 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 18 12:06:12 UTC 2025
;; MSG SIZE  rcvd: 59

Sens : Les requêtes UDP expirent, mais TCP fonctionne. C’est le classique « UDP/53 bloqué quelque part » (pare-feu hôte, ACL réseau, security group, ou politique DNS trop zélée).

Décision : Corrigez le pare-feu/politique réseau pour UDP/53, ou forcez TCP uniquement comme mesure d’urgence (pas idéal).

Task 11: Check local firewall rules (UFW and nftables)

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                ct state established,related accept
                iif "lo" accept
                tcp dport 22 accept
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Sens : La chaîne output est acceptante, donc le pare-feu local ne bloque probablement pas UDP/53 sortant. Si votre politique output était drop ou si vous aviez un deny explicite, c’est votre coupable.

Décision : Si le pare-feu local est propre, regardez les ACL amont/security groups/NACL du VPC, ou le pare-feu du serveur DNS lui-même.

Task 12: Confirm which backend manages the link (NetworkManager vs networkd)

cr0x@server:~$ networkctl status ens3
● 2: ens3
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens3.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.0.0.42 (DHCP4)
                       Gateway: 10.0.0.1
                           DNS: 10.0.0.53 10.0.0.54

Sens : Cette interface est gérée par systemd-networkd via un fichier généré par Netplan. Vos paramètres DNS doivent être corrigés dans Netplan (ou DHCP), pas dans NetworkManager.

Décision : Éditez /etc/netplan/*.yaml et appliquez.

Task 13: Inspect Netplan DNS config (and spot “looks right, behaves wrong”)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true

Sens : Le DNS vient du DHCP, pas d’une configuration statique. Si le DHCP distribue des serveurs DNS morts, vous échouerez même si la configuration locale semble « propre ».

Décision : Corrigez les options DHCP en amont, ou surchargez le DNS localement dans Netplan pour ce rôle d’hôte.

Task 14: Override DNS servers in Netplan (the right way) and apply

cr0x@server:~$ sudo tee /etc/netplan/50-dns-override.yaml >/dev/null <<'EOF'
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      nameservers:
        addresses: [10.0.0.53, 10.0.0.54]
        search: [corp.internal]
EOF

cr0x@server:~$ sudo netplan apply

Sens : Vous avez déclaré l’intention dans l’interface supportée. Si quelque chose l’écrase plus tard, vous avez maintenant un artefact de configuration à auditer.

Décision : Re-vérifiez resolvectl status et lancez une requête à nouveau. Si cela échoue encore, ce n’est pas un problème de « serveurs DNS manquants ».

Task 15: Check journal logs for resolved (timeouts leave fingerprints)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "20 min ago" --no-pager
Dec 18 11:52:07 server systemd-resolved[812]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.53.
Dec 18 12:02:14 server systemd-resolved[812]: DNS server 10.0.0.53: Timeout while contacting DNS server.
Dec 18 12:02:19 server systemd-resolved[812]: Switching to DNS server 10.0.0.54.

Sens : Resolved subit des timeouts et bascule. « Degraded feature set » pointe souvent vers des problèmes MTU/fragmentation, un mauvais support EDNS0, ou des middleboxes.

Décision : Si plusieurs serveurs DNS timeoutent, c’est la connectivité. Si un seul est mauvais, retirez/remplacez-le. Si EDNS0 déclenche des échecs, vérifiez le MTU/chemin et le comportement du serveur DNS.

Task 16: Validate NSS order (sometimes you’re not even using DNS)

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

Sens : Le DNS est consulté après files et une logique mDNS. C’est normal sur beaucoup d’installations Ubuntu. Si vous êtes en environnement serveur et que mDNS cause des délais, cette ligne peut avoir de l’importance.

Décision : Si les recherches se bloquent avant d’échouer, considérez si mDNS ou des services de noms locaux mal configurés retardent. N’« optimisez » pas cela sans comprendre le rayon d’impact (voir histoire plus loin).

Blague sèche #2 : Si vous codez en dur le DNS partout, vous finirez par exploiter un système distribué entièrement composé d’exceptions.

Trois mini-histoires d’entreprise issues du terrain

Incident causé par une fausse hypothèse : « Ce ne peut pas être le DNS parce que l’IP pingue »

Une entreprise de taille moyenne exploitait une flotte de serveurs Ubuntu dans un VPC cloud. Un mardi, les builds ont commencé à échouer avec l’erreur familière pendant les installations de paquets. Le canal incident s’est rempli vite : les nœuds de build pouvaient pinger la gateway NAT, faire des curl sur une IP publique, et atteindre même le dépôt d’artefacts par IP. L’hypothèse initiale était donc : « Le DNS va bien ; le repo est en panne. »

Le repo n’était pas en panne. Les nœuds de build utilisaient un forwarder DNS corporate, joignable uniquement via une règle de security group qui avait récemment été « resserrée ». L’ICMP était autorisé, le TCP/443 aussi, mais l’UDP/53 sortant depuis ce subnet avait été supprimé. Pas malveillant — juste quelqu’un qui optimisait un jeu de règles avec un tableur.

L’équipe a perdu des heures parce qu’elle testait la mauvaise chose. Le ping du serveur DNS réussissait, ce qui renforçait l’hypothèse. Mais les requêtes DNS étaient UDP et étaient silencieusement abandonnées. Les outils de build réessayaient, subissaient des timeouts, et tombaient en comportements incohérents selon les langages et bibliothèques. Donc c’était intermittent.

La correction fut ennuyeuse : restaurer l’UDP/53 egress pour ce subnet vers les forwarders, et documenter que DNS n’est pas « juste joignable ». Après, ils ont ajouté un test canari lançant séparément dig +notcp et dig +tcp, car « DNS marche » n’est pas un booléen unique.

Optimisation qui s’est retournée contre eux : mettre plus en cache (et cacher les mauvaises réponses)

Dans une autre société, une équipe plateforme voulait des déploiements plus rapides. Ils ont constaté beaucoup de requêtes DNS répétées lors des pulls de containers, de la découverte de services et de la télémétrie. Leur idée : augmenter agressivement la mise en cache et réduire la charge en amont.

Ils ont poussé ces changements largement. Le volume de requêtes a chuté. Les graphiques semblaient super. Puis la bizarrerie a commencé : certains hôtes ne pouvaient plus atteindre de nouveaux services pendant des minutes après un déploiement. D’autres résolvaient un service vers une ancienne IP longtemps après le déplacement. Quelques nœuds se « réglaient » après un redémarrage, ce qui rendait l’incident surnaturel.

La cause n’était pas « la mise en cache est mauvaise ». La cause était la mise en cache sans discipline. Les enregistrements de service avaient de faibles TTL pour une raison (basculement rapide, blue/green). En imposant des caches plus longs et en superposant des caches (cache nœud + forwarder), ils ont multiplié l’effet TTL. La mise en cache négative a ajouté une autre complication : des NXDOMAIN transitoires se sont retrouvés épinglés.

Ils ont annulé les paramètres agressifs et ciblé plutôt le vrai goulot : capacité et latence des résolveurs en amont, plus des TTLs cohérents avec leurs mécanismes de déploiement. La performance s’est améliorée sans mentir au niveau DNS.

Pratique ennuyeuse mais correcte qui a sauvé la mise : configuration DNS par rôle et un test clair

Une organisation financière exploitait des serveurs Ubuntu 24.04 à travers plusieurs zones réseau : interface utilisateur, application interne, et données restreintes. Chaque zone avait des besoins DNS légèrement différents. L’approche tentante était « une image unique » avec « une config résolveur unique ». Ils ne l’ont pas fait.

Ils ont maintenu des snippets Netplan par rôle : chaque rôle déclarait explicitement ses serveurs DNS et domaines de recherche, avec DHCP autorisé pour l’adressage mais non fiable pour les détails du résolveur. L’équipe réseau fournissait toujours le DNS via DHCP, mais les hôtes ne s’en remettaient pas aveuglément.

La partie clé : une vérification de santé qui s’exécutait sur chaque hôte, toutes les quelques minutes, et rapportait trois mesures : (1) recherche getent vers un nom interne, (2) dig vers chaque serveur DNS configuré via UDP, et (3) un test de bascule TCP. La vérification produisait des modes d’échec non ambigus : « résolveur local cassé » vs « serveur DNS inaccessible » vs « UDP bloqué ».

Quand un changement en amont a cassé l’UDP pour une zone, l’alerte ne disait pas « résolution de nom échouée ». Elle disait « UDP/53 bloqué vers dns-a ; TCP/53 fonctionne ». L’équipe réseau a corrigé l’ACL en minutes parce que l’énoncé du problème était précis, et l’équipe plateforme n’a pas perdu de temps à redémarrer des services comme rituel.

Erreurs courantes : symptômes → cause racine → correction

Voici les schémas que je vois régulièrement sur Ubuntu 24.04. Les symptômes se ressemblent ; les corrections non.

1) Symptom: `apt update` fails, but `ping 1.1.1.1` works

Cause racine : Chaîne de résolveur cassée ou DNS en amont inaccessible, alors que le routage général fonctionne.
Correction : Utilisez resolvectl status pour identifier les serveurs DNS actifs ; puis dig @server pour tester la joignabilité. Corrigez DHCP/Netplan DNS ou pare-feu/ACL pour UDP/TCP 53.

2) Symptom: `/etc/resolv.conf` shows correct nameserver, but it keeps reverting

Cause racine : /etc/resolv.conf est géré (lien vers systemd-resolved ou généré par NetworkManager). Les modifications manuelles sont écrasées.
Correction : Configurez le DNS dans Netplan (networkd) ou NetworkManager, ou ajustez /etc/systemd/resolved.conf si vous voulez vraiment des overrides globaux. Ne luttez pas contre le générateur.

3) Symptom: Internal names fail, public names work (or vice versa)

Cause racine : Split DNS mal routé (mauvaise interface choisie, domaines de routage manquants, DNS VPN non appliqué).
Correction : Vérifiez le DNS et les domaines par lien dans resolvectl status. Assurez-vous que le bon lien a le bon DNS Domain et que le client VPN s’intègre correctement (ou configurez des domaines par lien via Netplan/NetworkManager).

4) Symptom: DNS works for a while after reboot, then fails later

Cause racine : Renouvellement DHCP change les serveurs DNS, reconnect VPN change la priorité des liens, ou cloud-init/scripts réseau réécrivent la config.
Correction : Identifiez l’auteur : vérifiez journalctl pour les événements réseau, confirmez la config Netplan, et si besoin verrouillez le DNS dans Netplan ou NetworkManager. Évitez les éditions ponctuelles.

5) Symptom: `dig` works, but applications still fail

Cause racine : L’appli utilise un chemin de résolveur différent (container avec son propre resolv.conf, config DNS statique, paramètres JVM), ou la config NSS diffère dans l’environnement.
Correction : Testez avec getent sur l’hôte et à l’intérieur du container. Comparez /etc/resolv.conf et /etc/nsswitch.conf dans les deux contextes. Corrigez au bon niveau.

6) Symptom: UDP queries time out, TCP works

Cause racine : UDP/53 bloqué ou altéré ; parfois MTU/fragmentation/EDNS provoque l’échec des grosses réponses UDP.
Correction : Autorisez UDP/53. Si EDNS/MTU est suspecté, cherchez « degraded feature set » dans les logs de resolved et validez le path MTU ou le support EDNS du serveur DNS.

7) Symptom: Very slow lookups, then intermittent failures

Cause racine : Expansion des domaines de recherche provoquant plusieurs requêtes ; perte de paquets ; l’un des serveurs DNS blackhole.
Correction : Utilisez resolvectl statistics (si disponible) et dig avec +tries=1 +time=1 vers chaque serveur. Retirez les serveurs morts ; réduisez les domaines de recherche pour les rôles serveur.

Listes de contrôle / plan pas-à-pas (rendre ça ennuyeux et correct)

Step-by-step: restore DNS on a broken Ubuntu 24.04 host

Confirmer que c’est réel : exécutez getent ahosts example.com. S’il fonctionne, votre problème est de plus haut niveau (proxy, TLS, config appli).
Confirmer le routage : ip route et ping la gateway.
Vérifier le mode résolveur : ls -l /etc/resolv.conf.
Inspecter la config de resolved : resolvectl status et notez :
- Serveurs DNS globaux
- Serveurs DNS par lien
- Domaines de recherche / de routage
- Quel lien est marqué route par défaut
Contourner la pile : dig @<dns-server> example.com A avec timeout court. Faites-le pour chaque serveur configuré.
Tester UDP vs TCP : dig +notcp et dig +tcp vers le même serveur.
Vérifier le pare-feu local : ufw status verbose et nft list ruleset.
Corriger le bon propriétaire de la config :
- Si interface gérée par networkd : corrigez le YAML Netplan et netplan apply.
- Si gérée par NetworkManager : utilisez nmcli pour définir DNS et propriétés de connexion.
- Si le DHCP est fautif : corrigez l’option 6 DHCP en amont, puis renouvelez le bail.
Valider après changement : resolvectl query, getent, et un workflow réel (apt update si c’est le chemin qui échoue).
Stabiliser : ajoutez une petite vérification DNS dans votre monitoring pour détecter la dérive et les pannes partielles avant les utilisateurs.

Operational checklist: prevent the next incident

Standardisez « qui possède les paramètres DNS » par rôle d’hôte : uniquement DHCP, override Netplan, ou policy NetworkManager. Choisissez une approche.
Assurez au moins deux serveurs DNS, mais ne listez pas des seconds morts « pour plus tard ». Un secondaire mort peut encore vous coûter des secondes par requête selon le comportement de retry.
Documentez les domaines de split DNS et quelle interface les fournit (surtout avec les clients VPN et réseaux overlay).
Testez UDP et TCP DNS en CI pour les images de base si vous opérez dans des réseaux fortement filtrés.
Gardez les domaines de recherche courts pour les serveurs. Les laptops devs peuvent tolérer la commodité ; la production veut de la détermination.
Décidez si IPv6 est supporté. Si c’est à moitié supporté, vous vous inscrivez volontairement à des timeouts étranges.

FAQ

1) Why does Ubuntu show `nameserver 127.0.0.53` in `/etc/resolv.conf`?

Il s’agit du stub local pour systemd-resolved. Les applications interrogent localhost ; resolved relaie vers les vrais serveurs DNS selon la config par lien et met en cache les réponses.

2) Should I disable systemd-resolved to “fix DNS”?

Seulement si vous avez une raison claire et un plan. Le désactiver peut fonctionner, mais c’est un outil trop grossier qui casse souvent le split DNS, le comportement VPN, et la maintenance future. Corrigez d’abord la joignabilité en amont ou la config Netplan/NetworkManager.

3) I edited `/etc/resolv.conf` and it worked—why did it break later?

Parce que ce fichier est souvent généré. Votre modification a soit touché le fichier stub (qui est régénéré) soit remplacé un lien symbolique qu’un paquet/service attend. La correction durable se fait dans Netplan, NetworkManager, ou la config resolved.

4) Why do some tools work while others fail (e.g., `dig` works, `apt` fails)?

dig peut interroger un serveur spécifique directement, contournant le chemin résolveur système. apt utilise généralement le résolveur libc et ce que l’hôte fournit via NSS et /etc/resolv.conf. Testez avec getent pour reproduire le comportement applicatif.

5) What’s the fastest way to tell “DNS config issue” vs “DNS server unreachable”?

Exécutez resolvectl status pour voir quel serveur vous utilisez, puis dig @that-server example.com avec un timeout court. Si la requête directe timeoute, le chemin vers le serveur est le problème. Si elle fonctionne, votre chaîne résolveur locale est mal câblée.

6) Why does UDP matter if TCP works?

La plupart des requêtes DNS utilisent UDP par défaut pour la performance. Si UDP/53 est bloqué, beaucoup de clients vont timeout avant de retomber sur TCP (si elles le font). Cela ressemble à des pannes intermittentes et à des pics de latence.

7) How do VPNs cause “Temporary failure in name resolution” after disconnect?

Les clients VPN ajoutent souvent du DNS et des domaines de routage spécifiques au lien, puis ne nettoient pas correctement ou ne restaurent pas l’état précédent. Vous vous retrouvez avec des serveurs DNS injoignables après la déconnexion du VPN, ou une interface différente devient « par défaut » pour le routage DNS.

8) Should I put public resolvers (like 1.1.1.1) on servers as a fallback?

Pas par réflexe. En entreprise vous pouvez divulguer des noms internes ou casser des contrôles de politique. En production, préférez des résolveurs destinés à cette zone réseau, et assurez-vous qu’ils sont joignables avec les règles de pare-feu correctes.

9) My DNS servers are reachable, but resolved logs say “degraded feature set UDP instead of UDP+EDNS0.” Is that bad?

C’est un indice. Cela pointe généralement vers un chemin qui droppe les paquets UDP fragmentés ou maltraite EDNS0. Vous pouvez encore « fonctionner », mais vous êtes proche d’échecs intermittents — surtout avec DNSSEC, de grands enregistrements TXT, ou des résolveurs très chargés.

10) What’s a safe “emergency workaround” during an outage?

Utilisez un override Netplan temporaire pour pointer vers des serveurs DNS internes connus et sains pour cette zone, appliquez-le et validez. Évitez d’éditer /etc/resolv.conf à la main sauf si vous acceptez qu’il puisse être écrasé et que vous documentez la dérogation.

Conclusion: next steps you can do today

Arrêtez de traiter Temporary failure in name resolution comme un événement météo. Sur Ubuntu 24.04, les pannes DNS sont diagnostiquables si vous respectez la chaîne : application → NSS → resolv.conf → systemd-resolved → DNS en amont → politique réseau.

Prochaines étapes qui rapportent tout de suite :

Adoptez le playbook de diagnostic rapide et formez votre rotation on-call.
Standardisez la propriété du DNS (Netplan vs NetworkManager vs DHCP) par rôle d’hôte, et consignez-la dans le repo qui construit vos images.
Ajoutez un petit canari DNS qui distingue : défaillance du résolveur local, panne du serveur en amont, et problèmes de politique UDP/TCP.
Quand vous corrigez, corrigez au bon niveau — pour que la réparation tienne après renouvellements, reboots, et drames VPN.