DNS en panne : checklist de debug côté Linux

Tu connais le moment. Tout marche. Puis d’un coup, plus rien. curl mouline, apt update te renvoie des erreurs, Slack ne se connecte plus, et toi tu te dis « bon… Internet est mort ». Sauf que non. Souvent, c’est juste le DNS.

Et le DNS, c’est vicieux parce que la machine a l’air connectée (ping IP ok), mais tout ce qui dépend des noms de domaine s’écroule. Du coup, je te propose une checklist simple, assez terrain, pour diagnostiquer vite et proprement un souci DNS sur Linux.

Je vais volontairement rester côté Linux, sans partir sur « redémarre la box » (même si… parfois). On va vérifier dans l’ordre, du plus évident au plus sournois.

Le symptôme : est ce vraiment du DNS

Avant de toucher à /etc/resolv.conf, on fait 3 tests. Rapides. Ça évite de partir dans la mauvaise direction.

1) Test connectivité IP brute

bash ping -c 2 1.1.1.1 ping -c 2 8.8.8.8

Si ça répond, tu as de la connectivité réseau IP. Donc potentiellement le problème est bien DNS. Si ça ne répond pas, stop. Tu as peut être un problème de route, de Wi-Fi, de firewall, de VPN, de VLAN, bref autre chose.

Pour résoudre ces problèmes et optimiser ton utilisation de Linux, il existe des ressources précieuses comme ces 25 commandes Linux qui sauvent. De plus, si tu envisages une carrière en tant qu'expert Linux ou freelance dans ce domaine, il serait judicieux d'explorer cette roadmap pour devenir expert Linux ou encore les avantages de maîtriser Linux. Enfin, pour ceux qui envisagent de passer une certification en Linux cette année, voici un guide sur comment obtenir une certification Linux en 2026 qui pourrait être utile.

2) Test DNS simple avec un outil « qui ne ment pas »

Utilisez la commande suivante pour tester la résolution DNS :

bash getent hosts google.com

getent passe par la libc et donc par la stack de résolution « normale » du système. C’est un bon indicateur de ce que voient les applis.

• Si getent renvoie une IP : la résolution marche, le souci est ailleurs.
• Si ça time out ou renvoie rien : ok, on continue.

3) Comparer nom vs IP sur le même service

Pour effectuer une comparaison entre le nom de domaine et l'adresse IP, vous pouvez utiliser les commandes suivantes :

bash curl -I https://1.1.1.1 curl -I https://cloudflare.com

Le premier peut échouer pour des raisons TLS (SNI, certificat) mais tu verras déjà si tu as un début de réponse réseau. Le second te dira si le DNS est utilisé et s’il casse.

Comprendre ce que ton Linux utilise vraiment pour résoudre

Petit rappel important parce que c’est là que beaucoup se perdent.

Selon la distro et la config, tu peux avoir :

• systemd-resolved qui gère un stub local 127.0.0.53
• NetworkManager qui pousse des DNS par interface
• resolvconf ou des scripts DHCP qui écrasent /etc/resolv.conf
• un service local genre dnsmasq, unbound, named
• un DNS d’entreprise via VPN avec des domaines internes

Donc la première étape c’est de savoir quel « chemin » de résolution est en place. Il pourrait être utile d'explorer certaines certifications Linux qui pourraient améliorer votre compréhension et votre maîtrise du système Linux.

En outre, si vous envisagez de changer d'OS, ces compétences pourraient également être bénéfiques dans un environnement Windows.

Enfin, il est crucial de rester vigilant concernant les erreurs de sécurité potentielles lors de l'utilisation du réseau. Une erreur de sécurité peut compromettre vos données et votre système.

Voir le contenu de /etc/resolv.conf

bash ls -l /etc/resolv.conf cat /etc/resolv.conf

Regarde si c’est un fichier normal ou un symlink.

Exemples typiques :

• Symlink vers ../run/systemd/resolve/stub-resolv.conf : tu es derrière systemd-resolved avec stub.
• Symlink vers ../run/NetworkManager/resolv.conf : NetworkManager pilote.
• Fichier statique : potentiellement manuel, ou géré par autre chose.

Si tu vois nameserver 127.0.0.53, ça ne veut pas dire que ton DNS est 127.0.0.53. Ça veut dire que ton résolveur local écoute là, et lui ira interroger des DNS « en amont ».

Voir l’état de systemd-resolved si présent

bash resolvectl status

systemd-resolve --status

Tu veux repérer :

• les DNS par interface (Wi-Fi, Ethernet, tun0)
• le DNS global
• les « search domains »
• le DNSSEC (activé ou non)
• si la liaison est marquée « Current DNS Server »

Si resolvectl te montre des DNS incohérents (ex : DNS du VPN alors que le VPN est down), ça peut expliquer la panne.

Checklist 1 : valider la résolution avec dig et nslookup (sans dépendre de la libc)

On veut tester en direct, en visant un serveur DNS précis. C’est le test qui tranche.

Tester avec dig

bash dig google.com dig @1.1.1.1 google.com dig @8.8.8.8 google.com

Interprétation :

• dig @1.1.1.1 marche mais dig google.com non : ton DNS configuré est cassé, mais Internet va bien.
• Aucun ne marche : soit tu n’as pas de route vers l’extérieur, soit un firewall bloque UDP/TCP 53, soit tu es dans un réseau très filtré.

Astuce : tester TCP 53 si UDP est filtré

bash dig +tcp @1.1.1.1 google.com

Tester avec nslookup (moins riche, mais pratique)

bash nslookup google.com nslookup google.com 1.1.1.1

Si nslookup google.com 1.1.1.1 marche, tu as une piste claire.

Checklist 2 : vérifier qu’aucun service local ne bloque ou ne répond n’importe comment

Le stub 127.0.0.53 répond il

Si ton /etc/resolv.conf pointe sur 127.0.0.53 :

bash dig @127.0.0.53 google.com

Si ça échoue, systemd-resolved a un problème, ou n’a plus de DNS upstream valide.

Vérifie service et logs :

bash systemctl status systemd-resolved journalctl -u systemd-resolved --no-pager -n 200

Un autre service écoute sur 53

bash sudo ss -lntup | grep -E '(:53\s)' sudo ss -lnup | grep -E '(:53\s)'

Tu peux tomber sur dnsmasq, unbound, named. Ce n’est pas « mauvais » en soi, mais si tu ne l’as pas voulu, c’est suspect.

Checklist 3 : vérifier la config réseau côté interface (et pas seulement global)

Le piège classique : tu as plusieurs interfaces, et le DNS part sur la mauvaise.

Voir les interfaces et routes

bash ip a ip r

Si tu es sur un laptop avec Wi-Fi + Ethernet + VPN, tu peux avoir une route par défaut qui change, et des DNS qui restent coincés sur l’autre interface.

Avec NetworkManager

bash nmcli dev status nmcli dev show | sed -n '/IP4.DNS/p;/IP6.DNS/p;/GENERAL.DEVICE/p'

Tu veux voir les DNS attachés à l’interface active.

Si VPN : vérifier split DNS et domains internes

Souvent, le VPN pousse des domaines de recherche (ex : corp.local) et un DNS interne. Si le tunnel est down mais la config reste, tu as une panne « totale » sur les noms, ou partielle (uniquement interne).

Regarde resolvectl status et cherche les DNS Domain.

Checklist 4 : le fichier nsswitch.conf et les priorités de résolution

C’est pas le premier truc auquel on pense, mais ça casse des environnements.

bash cat /etc/nsswitch.conf | grep -E '^hosts:'

Exemple courant :

hosts: files mdns4_minimal [NOTFOUND=return] dns

• files : /etc/hosts
• mdns : mDNS type .local
• dns : résolveur DNS

Si tu as une config exotique ou un [NOTFOUND=return] mal placé, certaines résolutions peuvent être court-circuitées.

Checklist 5 : /etc/hosts, le truc bête qui casse tout

Oui, vraiment. Surtout sur des serveurs clonés, ou des machines de dev.

bash cat /etc/hosts

Cherche un override genre :

127.0.0.1 api.monservice.com

Ou des entrées qui pointent vers des IP mortes. Test direct :

bash getent hosts api.monservice.com

Si ça renvoie l’IP de /etc/hosts alors que tu attends autre chose, tu as trouvé.

Checklist 6 : DNS over HTTPS, proxies et environnements d’entreprise

Sur Linux, certaines apps ne passent pas par la résolution système.

• Navigateurs : peuvent activer DoH (DNS over HTTPS).
• Docker : a son propre DNS interne.
• Proxy d’entreprise : peut filtrer ou intercepter.

Donc si « Firefox marche mais pas curl », ou l’inverse, ce n’est pas forcément incohérent.

Vérifier les variables proxy

bash env | grep -i proxy

Un HTTPS_PROXY mal configuré peut donner l’impression que « le DNS est mort » parce que les requêtes échouent autrement.

Checklist 7 : Docker et la résolution DNS qui part en vrille

Docker peut injecter un nameserver 127.0.0.11 dans les containers. Et si l’hôte a un DNS instable, les containers deviennent pénibles.

Sur l’hôte : voir si Docker est en cause indirecte

Teste la résolution sur l’hôte puis dans un container :

bash getent hosts debian.org

bash docker run --rm alpine:latest sh -c "cat /etc/resolv.conf && nslookup debian.org"

Si l’hôte marche et pas le container, regarde la conf Docker, le DNS upstream, et éventuellement force des DNS dans /etc/docker/daemon.json.

En parlant de configuration et de sécurité, il est crucial de renforcer la sécurité SSH sur vos serveurs pour éviter toute intrusion non désirée. De plus, comprendre la sécurité Linux peut vous aider à mieux protéger votre système contre les menaces potentielles.

Checklist 8 : IPv6, le faux coupable fréquent

Tu peux avoir une résolution AAAA (IPv6) qui renvoie une adresse, mais ta connectivité IPv6 est cassée. Résultat : certaines applis tentent IPv6, échouent, et mettent du temps avant de fallback IPv4. Ça ressemble à un DNS lent.

Teste :

bash dig AAAA google.com ping -c 2 -6 google.com curl -6 -I https://google.com

Si IPv6 est cassé, tu peux temporairement tester en forçant IPv4 :

bash curl -4 -I https://google.com

Ce n’est pas une « solution » long terme, mais ça confirme le diagnostic.

Checklist 9 : latence et timeouts, quand le DNS marche mais trop lentement

Un DNS peut répondre, mais avec 3 secondes de délai. Pour toi, c’est une panne.

Mesure :

bash dig google.com +stats dig @1.1.1.1 google.com +stats dig @8.8.8.8 google.com +stats

Regarde Query time.

Si ton DNS local est lent et Cloudflare rapide, change temporairement de DNS pour confirmer.

Quick fix temporaires (pour dépanner, pas pour « finir »)

Je te laisse des actions rapides pour retrouver un système utilisable, le temps d’investiguer.

Option A : définir un resolv.conf temporaire (si non géré)

Attention : sur beaucoup de systèmes Linux, ce fichier est écrasé. Mais pour un test court, c’est utile. Si tu cherches à te familiariser avec différentes distributions Linux, cette méthode pourrait être un bon point de départ.

bash sudo sh -c 'printf "%s\n"
"nameserver 1.1.1.1"
"nameserver 8.8.8.8" > /etc/resolv.conf'

Puis :

bash getent hosts google.com

Cette approche pourrait également être bénéfique si tu envisages d'obtenir des certifications Linux à l'avenir ou si tu es dans un débat sur Linux vs Windows.

Option B : redémarrer le service resolved

bash sudo systemctl restart systemd-resolved resolvectl flush-caches

Option C : NetworkManager, reconnecter l’interface

bash nmcli networking off nmcli networking on nmcli dev disconnect wlan0 nmcli dev connect wlan0

Adapte l’interface.

Mini checklist « serveur » : quand tu es en prod et que tu dois être sûr

Sur un serveur, je fais souvent cette séquence. Elle est courte, mais elle donne une photo nette.

bash date uptime ip r cat /etc/resolv.conf getent hosts google.com dig google.com +time=2 +tries=1 dig @1.1.1.1 google.com +time=2 +tries=1 resolvectl status 2>/dev/null | head -n 80 journalctl -u systemd-resolved --no-pager -n 50 2>/dev/null

Tu copies colle ça dans un ticket, et tu as déjà 80 % du diagnostic.

Ce que je regarde en premier, honnêtement

Parce que oui, on peut faire tous les tests du monde. Mais en vrai.

1. getent hosts pour voir ce que « voient » les applis.
2. dig @1.1.1.1 pour savoir si c’est ton DNS ou le réseau.
3. /etc/resolv.conf pour comprendre qui pilote.
4. resolvectl status si systemd-resolved est dans la boucle.

Ensuite seulement je commence à accuser le VPN, Docker, IPv6, les proxies, etc.

Pour aller plus loin (et garder la checklist sous la main)

Si tu veux, je peux aussi publier une version « imprimable » en une page, genre mémo, avec les commandes et les interprétations les plus courantes. D’ailleurs c’est typiquement le genre de ressources que je mets sur mon site.

Si tu lis cet article depuis Le Blog Tech Pro de Samyn-Antoy ABASSE ( https://monblog-sa-abasse.blogspot.com ), pense à l’ajouter en favoris, je publie aussi des contenus SysAdmin Linux, mais aussi growth, SEO et productivité. Le mix est volontaire. Parce que dans la vraie vie, on touche à tout.

Conclusion : quand le DNS tombe, garde la tête froide

Le DNS, ce n’est pas magique. C’est juste une chaîne.

• Est ce que l’IP sort ?
• Est ce que le résolveur système marche ?
• Est ce que le serveur DNS upstream répond ?
• Est ce qu’un service local ou une interface détourne la résolution ?

Avec cette checklist, tu ne devrais plus rester bloqué à regarder un Temporary failure in name resolution comme si c’était une malédiction.

Et si tu veux un petit exercice utile : la prochaine fois que tout marche, lance resolvectl status, note ce que tu vois. Comme ça, le jour où ça casse, tu sauras tout de suite ce qui a changé.

Questions fréquemment posées

Quels sont les premiers tests à réaliser pour diagnostiquer un problème DNS sous Linux ?

Pour vérifier si un problème vient bien du DNS, commencez par tester la connectivité IP brute avec des commandes comme 'ping -c 2 1.1.1.1' ou 'ping -c 2 8.8.8.8'. Ensuite, testez la résolution DNS avec 'getent hosts google.com' qui utilise la stack de résolution standard. Enfin, comparez la connexion via nom de domaine et via IP avec 'curl -I https://cloudflare.com' et 'curl -I https://1.1.1.1'.

Comment savoir si mon problème réseau est lié au DNS ou à une autre cause ?

Si les pings vers des adresses IP publiques (comme 1.1.1.1 ou 8.8.8.8) fonctionnent, cela signifie que la connectivité réseau est active et que le problème est probablement lié au DNS. Si ces pings échouent, le souci peut venir d'un problème de routage, Wi-Fi, firewall, VPN ou VLAN.

Quels services et configurations peuvent influencer la résolution DNS sur Linux ?

La résolution DNS sous Linux peut être gérée par plusieurs composants selon la distribution : 'systemd-resolved' avec un stub local (127.0.0.53), NetworkManager qui configure les DNS par interface, 'resolvconf' ou des scripts DHCP qui modifient '/etc/resolv.conf', ainsi que des services locaux comme 'dnsmasq', 'unbound' ou 'named'. Il peut aussi y avoir des DNS spécifiques via VPN pour des domaines internes.

Pourquoi la machine semble connectée mais certaines applications ne fonctionnent pas ?

Cela provient souvent d'un problème DNS : la machine répond aux pings IP car la connectivité réseau est présente, mais les applications qui dépendent de la résolution de noms de domaine échouent car le DNS ne fonctionne pas correctement.

Comment vérifier quel système de résolution DNS est utilisé sur ma machine Linux ?

Vous pouvez inspecter le contenu de '/etc/resolv.conf' pour voir quels serveurs DNS sont configurés et vérifier si 'systemd-resolved' est actif en utilisant 'resolvectl status'. Considérez aussi les configurations NetworkManager et la présence éventuelle de services comme 'dnsmasq'.

Quelles ressources puis-je consulter pour approfondir mes compétences Linux et mieux gérer les problèmes réseau ?

Il existe plusieurs ressources utiles : "25 commandes Linux qui sauvent" pour optimiser l'utilisation quotidienne ; une roadmap pour devenir expert Linux freelance ; un guide sur l'obtention d'une certification Linux en 2026 ; ainsi que des articles comparant différents OS et expliquant l'intérêt de maîtriser Linux dans divers contextes professionnels.