DNS : diagnostiquer une panne « internet » en 15 minutes

Tu connais la scène.
« Internet ne marche plus ». Point. Pas plus de détails. Ça peut être le Wi-Fi, le DHCP, la box, un câble, un proxy, une route cassée, un souci de navigateur… ou juste le DNS.

Et le DNS, c’est traître, parce que quand il tombe (ou quand il répond mal), tu as l’impression que tout est mort. Alors qu’en vrai, souvent, tu as encore de l’IP, du routage, parfois même du ping. Juste… plus de noms.

L’objectif ici : en 15 minutes, tu veux être capable de dire, calmement :
« C’est DNS », ou « ce n’est pas DNS », et prouver pourquoi.

Petit clin d’œil au passage : ce genre de diagnostic, on le fait souvent en TP, en support, en stage. Et sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), on essaye justement de documenter ces réflexes terrain, pas seulement la théorie.

---

Ce que « DNS en panne » veut dire, concrètement

DNS = résolution de noms.

• Tu tapes https://sio1blog.blogspot.com/
• Ton PC doit obtenir une IP (via un résolveur DNS)
• Ensuite seulement, connexion TCP/HTTPS, etc.

Quand DNS est cassé, tu vois des symptômes du style :

• les sites « ne s’ouvrent plus »
• certaines applis fonctionnent encore (souvent celles qui gardent un cache)
• ping d’une IP OK, ping d’un nom KO
• erreurs navigateur du type « DNS_PROBE_FINISHED_NXDOMAIN », « server DNS address could not be found »

---

Le plan de bataille en 15 minutes (simple, reproductible)

Je te donne le déroulé standard. Tu peux littéralement le suivre comme une checklist.

1. vérifier l’IP locale et la passerelle
2. vérifier l’accès réseau sans DNS (ping IP publique)
3. vérifier la résolution DNS (nom vs IP)
4. identifier quel DNS est utilisé
5. tester le DNS lui-même (requêtes directes)
6. basculer temporairement sur un DNS public pour confirmer
7. corriger proprement (DHCP, routeur, serveur DNS, pare-feu, etc.)

On y va.

---

Minute 0 à 3 : vérifier que tu as une config IP normale

Sous Windows

Ouvre un terminal :

bat ipconfig /all

Tu veux voir :

• une IPv4 cohérente (pas 169.254.x.x)
• une passerelle par défaut
• un ou plusieurs serveurs DNS

Exemple de points à repérer :

• IPv4 : 192.168.1.25
• Passerelle : 192.168.1.1
• DNS : 192.168.1.1 (box) ou DNS interne (10.0.0.10) ou public (1.1.1.1)

Si tu es en 169.254.x.x : ce n’est pas DNS. C’est DHCP ou lien réseau.

Sous Linux

bash ip a ip r resolvectl status

• ip r doit montrer une route par défaut, typiquement default via 192.168.1.1
• resolvectl status te dit quels DNS sont utilisés (utile avec systemd-resolved)

---

Minute 3 à 6 : tester l’accès internet sans passer par DNS

L’idée : vérifier le chemin IP vers l’extérieur.

Teste un ping vers une IP publique connue. Exemples :

• Cloudflare : 1.1.1.1
• Google DNS : 8.8.8.8

Windows / Linux

bash ping 1.1.1.1

Si ping 1.1.1.1 répond mais que « les sites » ne s’ouvrent pas : ça sent très fort le DNS.

Si ping 1.1.1.1 ne répond pas, nuance :

• le ping peut être filtré
• mais souvent, c’est un souci plus bas niveau (route, firewall, box, lien)

Tu peux compléter avec un traceroute.

Windows :

bat tracert 1.1.1.1

Linux :

bash traceroute 1.1.1.1

---

Minute 6 à 8 : comparer ping IP vs ping nom de domaine

Test le nom :

bash ping sio1blog.blogspot.com

Cas typique DNS cassé :

• ping 1.1.1.1 OK
• ping sio1blog.blogspot.com -> « impossible de trouver l’hôte »

À ce stade, tu as déjà une conclusion probable : le réseau sort, mais la résolution de noms non.

---

Minute 8 à 11 : tester la résolution DNS proprement (nslookup, dig)

Sous Windows : nslookup

bat nslookup sio1blog.blogspot.com

Tu vas obtenir soit une réponse, soit une erreur.

Exemples d’erreurs utiles :

• DNS request timed out : serveur DNS injoignable (réseau, firewall, DNS down)
• Non-existent domain : le DNS répond mais dit NXDOMAIN (mauvais suffixe, domaine mal tapé, split-DNS, filtrage parental qui répond n’importe comment)
• il te montre aussi le serveur interrogé : très important

Tu peux aussi forcer un DNS public :

bat nslookup sio1blog.blogspot.com 1.1.1.1

Si ça marche avec 1.1.1.1 mais pas avec ton DNS habituel : verdict.

Sous Linux : dig

bash dig sio1blog.blogspot.com

Forcer un serveur :

bash dig @1.1.1.1 sio1blog.blogspot.com

Regarde :

• status: NOERROR et une section ANSWER = OK
• status: SERVFAIL = serveur DNS en difficulté (DNSSEC cassé, upstream HS, surcharge)
• status: NXDOMAIN = le nom n’existe pas (ou ton DNS ment)

---

Minute 11 à 13 : savoir quel DNS tu utilises vraiment (et éviter les pièges)

Piège classique : tu crois utiliser 8.8.8.8 mais en réalité…

• un VPN pousse son DNS
• un proxy/agent sécurité intercepte
• la box redirige tout le port 53 vers son propre DNS
• sur Windows, plusieurs interfaces (Ethernet + Wi-Fi + VM) se mélangent

Windows

bat ipconfig /all

Et aussi :

bat netsh interface ip show dns

Linux

Avec systemd :

bash resolvectl status

Sans systemd :

bash cat /etc/resolv.conf

Et si tu es en environnement entreprise : regarde aussi s’il y a un DNS interne (AD DS). Un poste joint à un domaine ne doit généralement pas pointer sur 8.8.8.8 directement, sinon bonjour les GPO, le LDAP, le Kerberos.

---

Minute 13 à 15 : confirmer avec un contournement rapide (sans tout casser)

Le test le plus rapide pour confirmer un diagnostic DNS, c’est de basculer temporairement sur un DNS public. Juste pour prouver l’hypothèse.

DNS publics courants :

• Cloudflare : 1.1.1.1 et 1.0.0.1
• Google : 8.8.8.8 et 8.8.4.4
• Quad9 : 9.9.9.9

Windows (test rapide)

Dans les propriétés IPv4 de ta carte réseau, mets 1.1.1.1. Teste un navigateur.

Ou via PowerShell (exemple) :

powershell Get-DnsClientServerAddress

Puis modifier (à adapter à l’interface) :

powershell Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,1.0.0.1

Linux (test rapide)

Avec systemd :

bash sudo resolvectl dns eth0 1.1.1.1 1.0.0.1

Puis :

bash resolvectl query sio1blog.blogspot.com

Si tout remarche immédiatement, tu as ton coupable.

Important : après confirmation, tu remets la config d’origine. Le but n’est pas de « fixer » en mode bricolage, mais d’identifier la cause racine.

---

Images utiles (à insérer dans l’article)

Tu peux intégrer ces visuels dans ton WordPress. Je te mets des sources stables et libres ou issues de projets connus. (Si tu veux, sur BTS SIO2 SISR Tech Lab on peut aussi faire des captures maison en TP, c’est souvent plus parlant.)

Schéma rapide DNS (résolution de nom)

Exemple de commande dig (visuel terminal)

Ports DNS (53 UDP/TCP)

(OK, le dernier est plus générique sur les ports, mais il aide certains à visualiser UDP vs TCP.)

---

Interpréter les résultats : mini tableau de décision

Cas 1 : ping IP publique OK, résolution KO

• cause probable : DNS injoignable, mal configuré, filtré
• action : tester nslookup vers DNS public, vérifier DNS dans ipconfig, vérifier pare-feu, vérifier que le DNS interne est up

Cas 2 : ping IP publique KO, résolution KO

• cause probable : pas de sortie internet (route, box, lien, VLAN, NAT)
• action : résoudre la connectivité d’abord. DNS n’est pas ta priorité

Cas 3 : résolution OK, mais navigation KO

• cause probable : proxy, MTU, TLS, filtrage web, SNI, captive portal
• action : tester curl, tester via IP, vérifier proxy système

---

Les causes DNS les plus fréquentes (celles qu’on voit vraiment)

1) DNS serveur down ou inaccessible

• service arrêté (Bind, Windows DNS, Unbound)
• firewall bloque 53 UDP/TCP
• route vers le DNS cassée

Symptôme : timeout dans nslookup.

2) Mauvaise config DHCP

Le DHCP distribue un mauvais DNS (ex : ancienne IP du serveur).

Symptôme : tous les postes sont touchés d’un coup. Le serveur DNS montré par ipconfig est suspect.

3) Split-DNS / DNS interne mal géré

En entreprise, tu as une zone interne (AD) et de la résolution externe via redirecters.

Symptôme : les noms internes marchent, les externes non. Ou l’inverse.

4) Cache DNS corrompu ou périmé

Plus rare, mais ça arrive.

Windows :

bat ipconfig /flushdns

Linux (systemd) :

bash sudo resolvectl flush-caches

5) DNS menteur (filtrage, contrôle parental, portail captif)

Certains équipements renvoient une IP au lieu de NXDOMAIN. Tu crois que « ça résout », mais vers une page bidon.

Symptôme : dig renvoie une IP bizarre, souvent identique pour plein de domaines.

---

Bonus : deux tests ultra efficaces quand tu doutes encore

Tester une requête DNS en TCP (quand UDP est filtré)

Oui, DNS peut utiliser TCP, notamment pour des réponses longues.

Avec dig :

bash dig +tcp @1.1.1.1 sio1blog.blogspot.com

Si TCP marche et UDP non : filtrage UDP 53 quelque part. On a déjà vu ça en réseau mal configuré.

Tester DoH (DNS over HTTPS) pour contourner le réseau

Ce n’est pas « la solution » en entreprise, mais c’est un test.

Avec curl et un endpoint DoH (ex Cloudflare), c’est possible, mais ça dépasse un peu le 15 minutes. Disons juste : si DoH marche, ton HTTP/HTTPS sort, donc ton réseau est vivant, et ton DNS classique est le suspect numéro 1.

---

Conclusion (et quoi noter dans ton ticket/incidence)

En 15 minutes, tu dois pouvoir écrire un diagnostic clair, pas juste « DNS HS ».

Un bon résumé de ticket, ça ressemble à :

• config IP OK, passerelle OK
• ping 1.1.1.1 OK
• résolution via DNS local 192.168.1.1 en timeout
• résolution via 1.1.1.1 OK
• donc panne DNS sur le résolveur local (box, serveur DNS, ou filtrage port 53)

Et ensuite tu escalades au bon endroit : admin réseau, admin serveur DNS, ou opérateur.

Si tu veux d’autres checklists du même style (DHCP, VLAN, routage, Wi-Fi, pare-feu, supervision), garde BTS SIO2 SISR Tech Lab dans tes favoris : https://sio1blog.blogspot.com/
On y met des labs et retours d’expérience pensés pour le terrain, et franchement, ça aide quand tu te retrouves seul devant « internet ne marche plus » à 8h02.

Questions fréquemment posées

Qu'est-ce que signifie concrètement une panne DNS ?

Une panne DNS signifie que la résolution des noms de domaine ne fonctionne plus. Concrètement, cela se traduit par l'impossibilité d'ouvrir des sites web via leurs noms, alors que la connexion IP peut encore être active. Par exemple, le ping sur une adresse IP publique fonctionne, mais le ping sur un nom de domaine échoue avec des erreurs comme "DNS_PROBE_FINISHED_NXDOMAIN".

Comment vérifier rapidement si le problème d'accès internet est lié au DNS ?

En suivant une checklist simple en 15 minutes : 1) Vérifier la configuration IP locale et la passerelle, 2) Tester l'accès réseau sans DNS en pingant une IP publique (ex : 1.1.1.1), 3) Comparer le ping entre une IP et un nom de domaine, 4) Tester la résolution DNS avec des outils comme nslookup ou dig, 5) Identifier quel serveur DNS est utilisé, 6) Essayer un DNS public temporairement pour confirmer, 7) Corriger la configuration si nécessaire.

Quels sont les symptômes typiques d'une panne DNS ?

Les symptômes incluent : les sites web qui ne s'ouvrent plus malgré un accès réseau actif, certaines applications fonctionnant encore grâce à leur cache DNS, le ping vers une adresse IP publique qui répond tandis que le ping vers un nom de domaine échoue, et des messages d'erreur dans le navigateur tels que "DNS_PROBE_FINISHED_NXDOMAIN" ou "server DNS address could not be found".

Comment vérifier la configuration IP locale sous Windows et Linux ?

Sous Windows, ouvrez un terminal et tapez 'ipconfig /all' pour vérifier que vous avez une IPv4 cohérente (pas en 169.254.x.x), une passerelle par défaut et au moins un serveur DNS. Sous Linux, utilisez les commandes 'ip a', 'ip r' pour voir l'adresse IP et les routes, puis 'resolvectl status' pour connaître les serveurs DNS utilisés.

Comment tester la résolution DNS proprement ?

Utilisez des outils comme 'nslookup' sous Windows ou 'dig' sous Linux pour interroger directement un serveur DNS. Par exemple, 'nslookup sio1blog.blogspot.com' vous donnera soit l'adresse IP correspondante soit une erreur indiquant un problème avec le serveur DNS (ex: timeout ou NXDOMAIN).

Que faire si le ping vers une IP publique fonctionne mais pas vers un nom de domaine ?

Cela indique généralement un problème de résolution DNS. Vous pouvez alors identifier quel serveur DNS est configuré sur votre machine et tester sa disponibilité. Ensuite, essayez de basculer temporairement vers un serveur DNS public fiable (comme 8.8.8.8 ou 1.1.1.1) pour confirmer si le problème vient du serveur DNS initial avant de corriger la configuration DHCP, routeur ou pare-feu.