DNS « Échec temporaire de la résolution de noms » : 5 causes principales et ordre de correction

janvier 31, 2026 • février 3, 2026 • Lecture : 26 min • Views: 8

Cet article vous a aidé ?

Vous êtes de garde. Un déploiement est à moitié fait. Soudain, toutes les machines commencent à se plaindre : Temporary failure in name resolution.
Pas un « NXDOMAIN », pas un « connection refused ». Juste ce haussement d’épaules vague et exaspérant.

Cette erreur est la façon pour DNS de dire : « J’ai essayé, j’ai attendu, et j’ai abandonné. » La solution n’est pas de « redémarrer le réseau » (arrêtez de faire ça).
La solution consiste à comprendre quelle couche échoue — et les vérifier dans le bon ordre pour ne pas perdre une heure à vous battre avec /etc/resolv.conf comme s’il vous devait de l’argent.

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

« Échec temporaire de la résolution de noms » est généralement le résolveur userland qui dit : « Je n’ai pas pu obtenir de réponse pour le moment. »
Sur Linux avec glibc, cela correspond souvent à EAI_AGAIN de getaddrinfo() — un échec transitoire de résolution.
Ce n’est pas la même chose que « le nom n’existe pas ».

Si vous voulez raisonner comme un SRE, traduisez le message en l’une de ces catégories :

Je ne peux pas atteindre un résolveur (chemin réseau, pare-feu, mauvaise IP, résolveur arrêté).
J’ai atteint un résolveur mais il ne répond pas (timeouts, UDP bloqué, problèmes EDNS, limitations de débit).
J’ai reçu une réponse mais le client l’a rejetée (validation DNSSEC, troncation, fallback TCP bloqué, cache corrompu).
J’ai posé la mauvaise question (domaines de recherche, ndots, surprises du split-horizon).

L’essentiel : l’erreur concerne le processus (tentative de résolution), pas la vérité du nom.
C’est pour cela que des redémarrages aléatoires « aident » parfois — parce qu’ils réinitialisent un cache, une socket, ou une course. C’est aussi pourquoi ces mêmes redémarrages reviendront vous hanter.

Une citation à garder au mur :
L’espoir n’est pas une stratégie. — Général Gordon R. Sullivan

Les 5 causes principales (dans l’ordre où il faut les corriger)

Cause racine n°1 : L’hôte n’utilise pas le résolveur que vous croyez

Linux moderne a plusieurs couches qui peuvent « posséder » le DNS : NetworkManager, systemd-resolved, clients DHCP, agents VPN,
conteneurs, et les bons vieux fichiers écrits à la main. « Échec temporaire » est fréquent quand ces couches ne sont pas d’accord, et votre appli interroge fidèlement une impasse.

Modes de défaillance typiques :

/etc/resolv.conf pointe vers 127.0.0.53 mais systemd-resolved est arrêté ou mal configuré.
/etc/resolv.conf a été écrasé par DHCP ou un VPN, laissant un nameserver inaccessible depuis ce réseau.
À l’intérieur des conteneurs, resolv.conf est hérité de l’hôte mais n’a pas de sens dans cet espace de noms.

Ordre de correction : confirmez quel résolveur est configuré, ensuite confirmez qu’il est joignable, puis confirmez qu’il répond pour les bons zones.
Ne touchez pas au DNS en amont tant que vous ne pouvez pas prouver que le client interroge le bon endroit.

Cause racine n°2 : Le chemin réseau vers le résolveur est cassé (routage, VPN, pare-feu)

Le DNS est un service réseau. Parfois, le réseau est le problème. Choquant, je sais.
Un résolveur peut être « up » et « sain » et quand même injoignable depuis un sous-réseau spécifique parce que quelqu’un a changé le routage,
resserré l’egress, ou activé un VPN qui a détourné votre route par défaut.

Le DNS est aussi spécial parce qu’il utilise UDP 53 par défaut et revient sur TCP 53 en fallback. Beaucoup d’équipements de sécurité traitent UDP et TCP différemment.
Si UDP est bloqué, vous verrez des timeouts. Si le fallback TCP est bloqué, les réponses volumineuses (ou DNSSEC) échouent d’une manière qui ressemble à un « échec temporaire ».

Ordre de correction : vérifiez la connectivité L3 vers l’IP du résolveur, vérifiez UDP 53, puis vérifiez TCP 53.
La plus rapide erreur est de déboguer des « enregistrements DNS » alors que les paquets meurent dans une règle de pare-feu écrite par quelqu’un qui déteste la joie.

Cause racine n°3 : Votre résolveur est malade (surchargé, mal configuré, ou en panne partielle)

Les résolveurs récursifs sont de l’infrastructure. L’infrastructure se fatigue.
Sous charge, les résolveurs laissent tomber des paquets, remplissent leurs files, ou appliquent des rate-limits. Certaines pannes sont « partielles » : seulement certains domaines,
seulement les AAAA, seulement les zones signées DNSSEC, seulement lors d’absences de cache.

Déclencheurs courants :

Tempêtes de cache miss après un redémarrage, ou après l’expiration des TTL sur des noms populaires.
Transfert défectueux vers des résolveurs upstream (forwarders ISP/entreprise down ou bloqués).
Taille EDNS inappropriée provoquant troncation et problèmes de fallback TCP.
Rate limiting contre des clients NATés (un cluster entier ressemble à une seule IP source).

Ordre de correction : testez le résolveur directement avec dig, surveillez la latence et les taux de SERVFAIL/timeout, puis validez la récursion et le forwarding.
Si le résolveur est à vous, regardez CPU, mémoire, tampons de socket et logs de requêtes. S’il n’est pas à vous, utilisez un autre résolveur comme contrôle.

Cause racine n°4 : Cache négatif, domaines de recherche et comportements surprenants du résolveur

Le résolveur fait plus que « poser une question au DNS ». Il tente des suffixes, il retente, il choisit A vs AAAA dans un ordre particulier,
et il met en cache des réponses négatives d’une manière qui semble personnelle.

Un classique : les domaines de recherche plus le comportement « ndots ». Un nom court comme api peut être essayé comme :
api.corp.example, puis api.dev.example, puis enfin api..
Si ces domaines intermédiaires sont lents ou cassés, votre requête « simple » a maintenant une latence de plusieurs secondes et des « échecs temporaires » occasionnels.

Ordre de correction : reproduisez avec dig et des noms pleinement qualifiés, inspectez les domaines de recherche, et testez A/AAAA séparément.
Évitez de bidouiller les TTL ou de vider les caches tant que vous n’avez pas prouvé que c’est pas l’algorithme du client qui vous mord.

Cause racine n°5 : Problèmes DNS autoritatifs (zone cassée, délégation erronée, DNSSEC, ou effondrement en amont)

Parfois c’est vraiment « DNS, DNS ». Le côté autoritatif est mauvais : la délégation pointe vers des serveurs morts, des glue records manquent,
des signatures DNSSEC ont expiré, ou un transfert de zone n’a pas eu lieu et le secondaire sert des données périmées.

Ces problèmes apparaissent souvent comme SERVFAIL ou timeouts depuis le résolveur récursif. Le client voit « échec temporaire », parce que la récursion a échoué.

Ordre de correction : lancez dig +trace, validez la délégation et la joignabilité des serveurs autoritatifs, puis corrigez DNSSEC ou le contenu de la zone.
Ceci vient en dernier dans l’ordre pour une raison : on l’accuse souvent et il est moins souvent coupable.

Mode d’intervention rapide (premier/deuxième/troisième)

Votre objectif n’est pas de devenir un philosophe du DNS. Votre objectif est de trouver le goulot d’étranglement en quelques minutes.
Voici la procédure que j’utilise quand la production brûle et que tout le monde tape « le DNS est en panne ? » dans chaque chat.

Premier : confirmer s’il s’agit d’une config locale, d’un démon local ou du réseau

Vérifiez quel résolveur vous utilisez (resolv.conf, état systemd-resolved).
Faites une requête contre l’IP du résolveur configuré directement avec dig.
Si cela échoue, testez la joignabilité basique du résolveur (ping n’est pas suffisant, mais c’est un début).

Second : établir un résolveur de contrôle et comparer

Interrogez le même nom via un résolveur connu bon (un résolveur public ou un autre résolveur interne).
Si le contrôle fonctionne, le problème vient probablement de votre résolveur ou du chemin jusqu’à lui.
Si le contrôle échoue aussi, suspectez le DNS autoritatif ou des restrictions réseau plus larges.

Troisième : décider si vous faites face à des timeouts, SERVFAIL ou au comportement du client

Timeouts suggèrent chemin réseau/pare-feu ou résolveur surchargé qui laisse tomber des paquets.
SERVFAIL suggère échec de récursion, problèmes DNSSEC, ou délégation cassée en amont.
Lent puis échec suggère expansion de domaines de recherche, ndots, ou blocage du fallback TCP.

Blague #1 : Le DNS, c’est comme un annuaire téléphonique qui décide parfois d’être un recueil de poésie. Techniquement toujours « du texte », émotionnellement inutile.

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

Ci-dessous se trouvent des tâches réelles que vous pouvez lancer sur un hôte Linux. Chacune inclut ce que signifie la sortie et la décision à prendre.
Exécutez-les dans l’ordre jusqu’à ce que vous rencontriez une contradiction. Les contradictions sont l’endroit où se trouve la vérité.

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

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

Signification : Cet hôte utilise le listener stub de systemd-resolved (127.0.0.53). Si systemd-resolved est arrêté, le DNS est en panne.

Décision : Vérifiez la santé de systemd-resolved ensuite. Si resolv.conf est un fichier régulier, inspectez directement ses lignes nameserver.

Task 2: Inspect nameservers and search domains

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

Signification : Les recherches peuvent s’étendre via search. Les noms courts peuvent entraîner plusieurs requêtes et des délais.

Décision : Lors des tests, essayez toujours le FQDN et évitez l’ambiguïté. Gardez à l’esprit les domaines de recherche pour les cas « lent puis échec ».

Task 3: Check systemd-resolved status and which upstream DNS it uses

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

Signification : systemd-resolved est actif et a des résolveurs upstream configurés (10.20.30.53/54).

Décision : Interrogez directement ces résolveurs upstream avec dig @10.20.30.53. Si le status est manquant ou vide, corrigez d’abord la config locale.

Task 4: Verify the local stub listener is actually listening

cr0x@server:~$ ss -ulpn | grep ':53 '
UNCONN 0      0         127.0.0.53%lo:53        0.0.0.0:*    users:(("systemd-resolve",pid=812,fd=14))

Signification : Le résolveur stub écoute sur UDP 53 sur loopback.

Décision : Si vous ne le voyez pas, redémarrez/réparez systemd-resolved (ou arrêtez d’utiliser le stub et pointez resolv.conf vers de vrais résolveurs).

Task 5: Query a name through the system resolver (baseline)

cr0x@server:~$ getent ahosts example.com
93.184.216.34   STREAM example.com
93.184.216.34   DGRAM  example.com
93.184.216.34   RAW    example.com

Signification : Le chemin du résolveur libc fonctionne (NSS + DNS). C’est plus proche de ce que les applications utilisent que dig.

Décision : Si getent échoue mais que dig fonctionne, suspectez la configuration NSS, nscd, ou le comportement spécifique du résolveur de l’application.

Task 6: Query the configured upstream resolver directly (bypass local stub)

cr0x@server:~$ dig @10.20.30.53 example.com +time=2 +tries=1

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

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 10.20.30.53#53(10.20.30.53) (UDP)
;; WHEN: Tue Jan 02 10:22:48 UTC 2026
;; MSG SIZE  rcvd: 56

Signification : Le résolveur upstream est joignable et répond rapidement.

Décision : Si cela marche mais que le résolveur système échoue, concentrez-vous sur le démon local, NSS, ou le comportement search/ndots. Si ça timeoute, passez aux vérifications du chemin réseau.

Task 7: Distinguish timeout vs SERVFAIL vs NXDOMAIN

cr0x@server:~$ dig @10.20.30.53 does-not-exist.example.com +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 does-not-exist.example.com +time=2 +tries=1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Signification : NXDOMAIN est une réponse définitive « le nom n’existe pas ». Ce n’est pas un « échec temporaire ».

Décision : Si votre appli affiche « échec temporaire » alors que dig affiche NXDOMAIN, suspectez les domaines de recherche et le fait que l’appli interroge un nom différent de celui que vous pensez.

Task 8: Check raw reachability to the resolver IP and route selection

cr0x@server:~$ ip route get 10.20.30.53
10.20.30.53 via 10.20.10.1 dev eth0 src 10.20.10.44 uid 1000
    cache

Signification : Le noyau sait comment atteindre le résolveur et quelle interface il utiliserait.

Décision : Si cette route est incorrecte (par ex. passe par une interface VPN), vous avez trouvé votre « échec temporaire ». Corrigez le routage/split tunneling VPN.

Task 9: Prove UDP 53 works (not just ICMP)

cr0x@server:~$ nc -u -vz 10.20.30.53 53
Connection to 10.20.30.53 53 port [udp/domain] succeeded!

Signification : Vous pouvez envoyer de l’UDP vers le port 53. Cela ne prouve pas que les réponses reviennent, mais c’est un signal rapide.

Décision : Si cela échoue, arrêtez de débattre des enregistrements DNS. Vous avez un pare-feu, un groupe de sécurité, ou un problème de routage.

Task 10: Prove TCP 53 works (needed for truncation/DNSSEC/large answers)

cr0x@server:~$ nc -vz 10.20.30.53 53
Connection to 10.20.30.53 53 port [tcp/domain] succeeded!

Signification : Le fallback TCP est possible. Si UDP marche mais TCP ne marche pas, certaines requêtes « échoueront au hasard » — surtout avec DNSSEC ou beaucoup d’enregistrements.

Décision : Si TCP est bloqué, réparez-le. Des contournements comme « désactiver DNSSEC » sont un dernier recours et souvent une mauvaise idée.

Task 11: Detect truncation and TCP fallback behavior

cr0x@server:~$ dig @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32801
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Signification : SERVFAIL sur un domaine connu pour être cassé DNSSEC indique que la validation DNSSEC est appliquée par le résolveur.

Décision : Si vos domaines internes renvoient SERVFAIL à cause de DNSSEC, corrigez la signature/les enregistrements DS. N’éteignez pas la validation DNSSEC sans comprendre les conséquences.

Task 12: Trace delegation to see if authoritative servers are broken

cr0x@server:~$ dig +trace app.corp.example

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> +trace app.corp.example
.                       518400  IN      NS      a.root-servers.net.
...
example.                172800  IN      NS      ns1.example.
example.                172800  IN      NS      ns2.example.
corp.example.           86400   IN      NS      ns1.corp.example.
corp.example.           86400   IN      NS      ns2.corp.example.
app.corp.example.       60      IN      A       10.50.0.25

Signification : Le trace montre la chaîne de délégation. Si elle s’arrête à une étape, vous avez trouvé où la résolution casse.

Décision : Si le trace échoue à votre niveau autoritatif, concentrez-vous là : pare-feu vers les serveurs auth, NS incorrects, glue périmée, ou masters hors service.

Task 13: Confirm the resolver’s view of a specific interface (systemd-resolved)

cr0x@server:~$ resolvectl dns eth0
Link 2 (eth0): 10.20.30.53 10.20.30.54

Signification : Les serveurs DNS sont assignés par lien ; les interfaces VPN peuvent écraser cela.

Décision : Si le mauvais lien a les DNS actifs, corrigez NetworkManager/VPN ou réglez correctement les DNS routing domains.

Task 14: Watch real DNS traffic (prove packets leave and replies return)

cr0x@server:~$ sudo tcpdump -ni eth0 '(udp port 53 or tcp port 53)' -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.122334 IP 10.20.10.44.41321 > 10.20.30.53.53: 47924+ A? example.com. (29)
10:25:11.136702 IP 10.20.30.53.53 > 10.20.10.44.41321: 47924 1/0/1 A 93.184.216.34 (45)

Signification : Vous avez du trafic bidirectionnel. Si vous ne voyez que des requêtes sortantes et pas de réponses, le problème est en amont (résolveur down) ou sur le chemin (ACL/sécurité).

Décision : Utilisez ceci pour clore les débats. Les paquets ne mentent pas ; les gens, parfois.

Task 15: Check NSS order (it can make DNS look broken)

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

Signification : Si mDNS est consulté en premier, certains noms peuvent stagner ou être court-circuités de manière inattendue.

Décision : Pour les serveurs, restez ennuyeux : typiquement files dns (plus ce dont votre environnement a réellement besoin).

Task 16: Spot “ndots” and resolver options that change behavior

cr0x@server:~$ grep '^options' /etc/resolv.conf
options edns0 trust-ad

Signification : Les options modifient la taille des paquets, le comportement trust, et les patterns de retry.

Décision : Si Kubernetes est impliqué, vérifiez son ndots (souvent 5). Un ndots élevé + beaucoup de domaines de recherche peut créer des tempêtes de requêtes et des « échecs temporaires ».

Blague #2 : La seule chose plus temporaire que « Échec temporaire de la résolution de noms » est la promesse « on fixera le DNS plus tard ».

Trois mini-récits tirés de la vie en entreprise (anonymisés)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne exécutait une paire de résolveurs récursifs internes dans deux centres de données. Les environnements de dev pointaient aussi vers eux.
Un vendredi, une équipe a déployé un nouveau profil client VPN « pour simplifier l’accès distant ». Ça a été testé. Ça marchait. Les gens pouvaient atteindre les applis internes.
Puis les builds ont commencé à échouer, puis les déploiements de production ont commencé à timeout lors de la récupération des paquets, puis la supervision s’est allumée avec le message classique.

La mauvaise hypothèse : « le DNS est interne, donc envoyer le DNS via le VPN est toujours correct. »
Le profil poussait un serveur DNS joignable seulement depuis l’intérieur du VPN — parfait pour les laptops — puis le même profil a été appliqué par erreur à un ensemble de runners CI.
Ces runners n’avaient pas l’interface VPN active. Ils ont simplement reçu un nouveau /etc/resolv.conf pointant vers une IP qu’ils ne pouvaient jamais joindre.

Les ingénieurs ont passé les 45 premières minutes à regarder des fichiers de zone autoritatifs, parce que quelqu’un a vu « name resolution » et a immédiatement blâmé les enregistrements.
La percée est venue quand une personne a lancé ip route get vers l’IP du résolveur et a remarqué qu’il essayait de router via une interface qui n’existait pas sur cet hôte.

La correction était ennuyeuse : séparer la configuration DHCP/VPN des DNS de l’infrastructure serveur, verrouiller qui peut changer les paramètres de résolveur sur les CI,
et ajouter un job canari qui lance getent hosts contre quelques noms critiques depuis le pool de runners.
Le DNS n’était pas « en panne ». Il était simplement inatteignable depuis les machines qui comptaient.

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

Une grande entreprise avait des problèmes de performance : les résolveurs internes traitaient un énorme volume de requêtes depuis des clusters Kubernetes.
Quelqu’un a fait la chose qui semblait sensée : tuner le caching agressivement et augmenter la taille du buffer EDNS UDP « pour réduire les fallback TCP ».
Ils ont aussi activé la validation DNSSEC « parce que la sécurité le voulait », sans faire un inventaire soigné des zones internes.

Pendant une semaine tout semblait correct. Puis des échecs de résolution intermittents ont commencé. Pas partout. Seulement pour un ensemble d’applis dépendant d’un domaine partenaire.
L’erreur était « échec temporaire ». Les métriques du résolveur montraient une hausse de SERVFAIL pour ce domaine partenaire, mais la latence était bonne par ailleurs.

Le retour de bâton : les serveurs autoritatifs du partenaire géraient mal les réponses EDNS larges et envoyaient parfois des réponses malformées.
Avant, les résolveurs tombaient plus souvent en fallback TCP et réussissaient. Maintenant, avec des UDP plus grands et la validation DNSSEC, le taux d’échec a augmenté et est devenu SERVFAIL.
Entre-temps, les retries Kubernetes amplifiaient la charge et faisaient paraître le résolveur « instable ».

La correction : réduire la taille EDNS à une valeur plus sûre, garder TCP 53 ouvert partout, et implémenter des exceptions de forwarding par zone pour le domaine problématique.
La leçon n’était pas « ne pas optimiser ». La leçon était « traitez le DNS comme un système distribué avec beaucoup de bords cassés ».
Si votre optimisation dépend de la perfection des autres, ce n’est pas une optimisation ; c’est un nouveau mode de panne.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une organisation de services financiers exécutait des résolveurs internes sur trois sites. Rien de sophistiqué. Deux instances par site. Des health checks simples.
La partie peu glamoureuse : ils maintenaient un petit tableau de bord « sanity DNS » qui testait la résolution depuis chaque sous-réseau majeur contre chaque résolveur, chaque minute,
en utilisant UDP et TCP. C’était le genre de chose que personne ne célébrait, ce qui est la preuve que c’était une bonne pratique.

Un après-midi, un changement de politique pare-feu a bloqué TCP 53 depuis un sous-ensemble de sous-réseaux applicatifs « parce qu’on n’utilise que l’UDP pour le DNS ».
La plupart des noms se résolvaient encore. Puis quelques noms critiques ont commencé à échouer — précisément ceux avec des réponses plus larges et signées DNSSEC.
Les applis rapportaient « échec temporaire ». Les équipes ont commencé à paniquer parce que les échecs étaient sporadiques et dépendants du nom.

Le tableau de bord sanity DNS s’est allumé immédiatement : UDP OK, TCP KO, localisé à un ensemble de sous-réseaux.
Cela a réduit l’espace du problème de « peut-être le résolveur meurt » à « une règle de pare-feu spécifique a cassé TCP 53 ».

Ils ont rollbacké la politique rapidement. Pas de héros. Pas de captures de paquets pendant une salle de crise.
La pratique ennuyeuse — tester les deux protocoles et plusieurs points de vue — a transformé un incident d’après-midi en une simple gêne.

Erreurs courantes : symptôme → cause racine → correctif

1) « Ça marche sur un serveur mais pas sur un autre »

Symptôme : Même appli, même sous-réseau, résultat différent. Un hôte résout ; un autre renvoie « échec temporaire ».

Cause racine : Sources de configuration DNS différentes (systemd-resolved vs resolv.conf statique, écrasement par VPN, DNS par lien).

Fix : Comparez ls -l /etc/resolv.conf et resolvectl status entre les hôtes ; standardisez la propriété et empêchez les agents aléatoires d’écraser la config du résolveur.

2) « dig fonctionne, l’appli échoue »

Symptôme : dig renvoie des réponses, mais les logs applicatifs montrent des échecs temporaires.

Cause racine : L’appli utilise le chemin libc/NSS ; dig non. L’ordre NSS, nscd, ou l’expansion search/ndots peuvent casser ou ralentir les choses.

Fix : Testez avec getent ahosts ; vérifiez /etc/nsswitch.conf ; reproduisez avec FQDN ; réduisez les domaines de recherche ; auditez ndots dans les environnements conteneurisés.

3) « Échecs intermittents, surtout pour certains domaines »

Symptôme : Certains noms se résolvent, d’autres timeout ; les échecs varient par domaine.

Cause racine : Fallback TCP bloqué, problèmes EDNS/fragmentation, ou instabilité autoritative pour certaines zones.

Fix : Vérifiez TCP 53 de bout en bout ; lancez dig +trace ; envisagez de baisser la taille EDNS sur les résolveurs ; confirmez que le pare-feu autorise les fragments UDP ou autorisez TCP.

4) « Tout échoue juste après un reboot / déploiement »

Symptôme : Après un redémarrage, beaucoup de timeouts ; ça se stabilise plus tard.

Cause racine : Tempête de cache miss contre un petit pool de résolveurs ; exhaustion CPU/socket du résolveur.

Fix : Ajoutez de la capacité aux résolveurs, activez le caching au bon niveau, étalez les redémarrages, et surveillez qps/latence. Ne redémarrez pas tous les résolveurs en même temps à moins d’aimer le chaos.

5) « Seulement dans les conteneurs / seulement dans les pods Kubernetes »

Symptôme : Le nœud résout ; le pod échoue avec échec temporaire.

Cause racine : DNS du cluster (CoreDNS) down, forwarding upstream cassé, ndots + domaines de recherche générant des tempêtes de requêtes, ou network policies bloquant le DNS.

Fix : Interrogez l’IP du service CoreDNS directement depuis un pod ; vérifiez la network policy pour UDP/TCP 53 ; réduisez ndots si pertinent ; assurez-vous que le caching node-local (si utilisé) est sain.

6) « Utilisateurs VPN OK, utilisateurs bureau KO (ou vice versa) »

Symptôme : La résolution dépend du fait d’être sur VPN.

Cause racine : Split-horizon DNS ou mauvaise configuration de split tunneling ; mauvais résolveur pour le contexte réseau.

Fix : Utilisez du routage par domaine (DNS routing domains) plutôt qu’un seul résolveur global ; assurez-vous que les résolveurs sont joignables depuis chaque segment réseau.

7) « SERVFAIL pour des domaines internes après activation de DNSSEC »

Symptôme : Les noms internes renvoient SERVFAIL ; les clients voient des échecs temporaires.

Cause racine : Chaîne DNSSEC cassée (DS erroné, signatures expirées, clés non appairées), ou zones internes non appropriées à la validation.

Fix : Corrigez la signature correctement ou désactivez la validation uniquement pour les zones internes spécifiques via la politique du résolveur. Une désactivation globale est un piège pour la sécurité et la fiabilité.

Checklists / plan pas à pas

Checklist A: Hôte unique « échec temporaire »

Identifier le résolveur en usage : ls -l /etc/resolv.conf et cat /etc/resolv.conf.
Si vous utilisez systemd-resolved : resolvectl status et ss -ulpn | grep ':53 '.
Tester le chemin libc : getent ahosts example.com.
Tester la joignabilité directe du résolveur : dig @<resolver-ip> example.com +time=2 +tries=1.
Distinguer le type d’échec : est-ce un timeout, un SERVFAIL, ou un NXDOMAIN ?
Valider le chemin réseau : ip route get <resolver-ip>, puis vérifiez UDP et TCP 53.
Preuve au niveau paquet si nécessaire : tcpdump pour voir requêtes et réponses.
Ce n’est qu’ensuite que vous regardez le DNS upstream ou autoritatif avec dig +trace.

Checklist B: Mode incident multi-hôtes

Choisir trois points de vue : un hôte en échec, un hôte sain, un hôte dans un autre sous-réseau.
Comparer la configuration des résolveurs entre eux.
Choisir deux noms de test : un nom interne critique, un nom externe stable.
Interroger via le résolveur configuré et via un résolveur de contrôle.
Chercher des motifs : seulement AAAA échoue ? seulement les réponses larges échouent ? seulement certains domaines ?
Vérifier les métriques/logs du résolveur si vous le possédez (qps, latence, taux de SERVFAIL, mémoire, descripteurs de fichiers).
Confirmer les changements de pare-feu pour UDP/TCP 53 et les problèmes MTU/fragmentation.
Communiquer clairement : « Timeouts vers l’IP du résolveur depuis le sous-réseau X » vaut mieux que « le DNS est instable ».

Résumé de l’ordre de correction (imprimez-le mentalement)

Propriété et exactitude de la config client (quel résolveur j’utilise ?)
Chemin vers le résolveur (routage + pare-feu, UDP et TCP)
Santé du résolveur et comportement récursion/forwarding
Comportement côté client : search/ndots/NSS provoquant retries et délais
DNS autoritatif et délégation / correction DNSSEC

Faits intéressants & contexte historique (DNS a sa lore)

Le DNS a remplacé la douleur du HOSTS.TXT : les réseaux initiaux utilisaient un unique fichier hosts distribué à tous ; ça ne scaleait plus quand les réseaux ont grandi.
Paul Mockapetris a conçu le DNS en 1983, introduisant le système de nommage hiérarchique et distribué toujours utilisé aujourd’hui.
UDP a été choisi pour la vitesse, mais TCP a toujours fait partie du protocole pour les réponses volumineuses et les transferts de zone.
Les résolveurs mettent aussi en cache le « non » : le caching négatif existe pour réduire la charge des échecs répétés, ce qui rend les fautes de frappe collantes.
Le TTL est indicatif mais puissant : des changements agressifs de TTL peuvent amplifier les patterns de trafic et provoquer des tempêtes de cache lors d’une panne ou d’un déploiement.
EDNS (Extension mechanisms for DNS) est arrivé pour étendre DNS sans le remplacer, incluant des payloads UDP plus larges — aussi source de problèmes de fragmentation.
DNSSEC ajoute de l’authenticité mais aussi de la taille et de la complexité ; les échecs de validation se manifestent souvent par des SERVFAIL plutôt que par une explication claire.
« Lame delegation » est un vrai terme : cela signifie qu’un nameserver est listé pour une zone mais ne peut pas répondre de manière authoritative pour elle.
Les domaines de recherche ont été conçus pour la commodité en entreprise, mais à l’échelle ils peuvent multiplier le volume de requêtes et la latence de façon dramatique.

FAQ

1) « Échec temporaire de la résolution de noms » est-ce toujours une panne du serveur DNS ?

Non. C’est souvent local : mauvais résolveur configuré, systemd-resolved arrêté, ou problème de chemin réseau/pare-feu.
Traitez-le comme un « échec de tentative de résolution », pas comme « les enregistrements DNS sont faux ».

2) Pourquoi le redémarrage du service le répare parfois ?

Parce que vous pouvez vider un cache, rouvrir des sockets, ou changer le timing. Ce n’est pas une cause racine ; c’est une pièce qui a 50/50 de chances avec un meilleur marketing.
Utilisez les redémarrages uniquement comme mesure provisoire pendant que vous collectez des preuves (dig/getent/tcpdump).

3) Quelle est la différence entre NXDOMAIN et cette erreur ?

NXDOMAIN signifie que le nom n’existe pas dans le DNS (réponse négative authoritative). « Échec temporaire » signifie généralement des timeouts ou SERVFAIL pendant la récursion.
Elles entraînent des actions différentes : NXDOMAIN c’est souvent une configuration/typo ; échec temporaire c’est connectivité/santé/délégation.

4) Pourquoi ça marche avec `dig` mais pas avec `curl` ou mon appli ?

dig interroge directement le DNS. Beaucoup d’applis utilisent le résolveur libc via NSS, qui peut consulter files, mDNS, LDAP ou d’autres sources d’abord,
et peut appliquer des domaines de recherche et des politiques de retry. Testez avec getent ahosts pour imiter le comportement applicatif.

5) Comment savoir si c’est UDP ou TCP le problème ?

Testez les deux. Utilisez nc -u -vz <resolver> 53 et nc -vz <resolver> 53, puis confirmez avec tcpdump.
Si TCP 53 est bloqué, les réponses DNS volumineuses échoueront de manière imprévisible.

6) Le MTU ou la fragmentation peuvent-ils causer un « échec temporaire » ?

Oui. Les grandes réponses UDP DNS peuvent être fragmentées. Si les fragments sont perdus (commun sur certains tunnels et pare-feu), vous obtenez des timeouts.
Cela ressemble à un comportement « temporaire » parce que les petites réponses réussissent encore. Autorisez TCP 53 et considérez des tailles EDNS UDP plus sûres sur les résolveurs.

7) Quelle est la manière la plus rapide pour vérifier si c’est mon résolveur ou le DNS autoritatif en amont ?

Interrogez un résolveur de contrôle. Si votre résolveur configuré échoue mais que le contrôle fonctionne, suspectez votre résolveur ou le chemin vers lui.
Si les deux échouent, lancez dig +trace pour voir où la délégation casse.

8) En quoi Kubernetes aggrave-t-il ça ?

Kubernetes utilise souvent plusieurs domaines de recherche et une valeur ndots élevée, ce qui peut multiplier les requêtes DNS par lookup.
Lors d’incidents DNS partiels, cette multiplication devient un amplificateur de charge. Corrigez en assurant la santé de CoreDNS, en autorisant UDP/TCP 53,
et en configurant ndots/search de façon intentionnelle.

9) Ne vaudrait-il pas mieux coder en dur des IPs pour éviter les pannes DNS ?

Coder en dur rend un système dynamique fragile. Vous évitez un mode de panne et vous en achetez trois nouveaux : endpoints périmés, failover cassé, rotations pénibles.
Si le DNS est peu fiable, corrigez la couche résolveur et la supervision. Ne gravez pas le problème dans la pierre.

10) Quel monitoring détecte réellement ça tôt ?

Des contrôles DNS multi-points contre chaque résolveur, pour UDP et TCP, pour un petit ensemble de noms critiques (internes et externes).
Suivez les percentiles de latence et les taux SERVFAIL/timeout. Alertez sur la tendance, pas seulement sur la panne totale.

Conclusion : étapes pratiques suivantes

« Échec temporaire de la résolution de noms » est rarement mystérieux. C’est simplement superposé.
La solution est d’arrêter de deviner et de travailler la pile dans le bon ordre : configuration client, chemin réseau, santé du résolveur, comportement client, DNS autoritatif.

Étapes que vous pouvez faire aujourd’hui :

Standardisez la propriété du DNS sur les hôtes (décidez : systemd-resolved, NetworkManager, ou statique ; pas « tous à la fois »).
Assurez-vous que UDP et TCP 53 sont permis entre clients et résolveurs, et entre résolveurs et upstreams.
Ajoutez un simple contrôle de sanity DNS depuis les sous-réseaux clés (UDP + TCP) et considérez une hausse des SERVFAIL/timeouts comme un avertissement précoce.
Auditez les domaines de recherche et ndots dans les plates-formes conteneurisées ; réduisez la multiplication des requêtes avant qu’elle ne réduise votre sommeil.
Lors du prochain incident, utilisez le playbook : prouvez où les paquets s’arrêtent, puis corrigez cette couche — pas de séances de DNS requises.