DNS : 15 tests rapides avant d’accuser « internet »

On a tous vécu ce moment. Tout le monde râle, Teams ne charge pas, le site client est « mort », et quelqu’un lâche un très sûr de lui : « C’est internet. »

Sauf que… dans la vraie vie, « internet » est rarement le coupable. Souvent c’est DNS, parfois c’est le Wi-Fi, parfois c’est un proxy, parfois c’est juste un cache qui a décidé de te faire perdre 40 minutes.

Du coup, voilà une checklist simple, rapide, plutôt terrain, avec 15 tests DNS à faire avant d’accuser « internet ». Tu peux les faire en 5 à 15 minutes si tu enchaînes bien.

Petit contexte : l’article est écrit pour les pratiques SISR, support, diag réseau. Et si tu aimes ce genre de fiches action, garde un œil sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) parce qu’on y empile ce type de procédures et de mini labs.

---

1) vérifier si le problème est vraiment DNS (test IP direct)

Avant tout, tu dois savoir si tu as un souci de résolution de noms ou un souci de connectivité.

• Ouvre un navigateur et tente une IP connue : https://1.1.1.1 ou https://8.8.8.8 (ça ne répondra pas toujours en HTTPS propre, mais tu vois si ça parle).
• Ou plus propre : ping vers une IP publique.

Windows : bat ping 1.1.1.1

Linux : bash ping -c 3 1.1.1.1

Si l’IP répond mais pas les noms de domaine, tu tiens déjà ton suspect.

2) ping un nom de domaine simple (et observe le message)

Windows : bat ping www.google.com

• Si tu vois un truc du style « impossible de trouver l’hôte », c’est DNS ou suffixes DNS.
• Si tu vois une IP mais que ça time out, ce n’est plus DNS, c’est du réseau, firewall, ICMP filtré, etc.

Oui, ping n’est pas la vérité absolue. Mais pour un tri rapide, il est parfait.

3) lire la configuration DNS du poste (sans interpréter trop vite)

Windows : bat ipconfig /all

Linux (selon distro) : bash resolvectl status

ou : bash cat /etc/resolv.conf

Ce que tu cherches :

• quels serveurs DNS sont configurés
• est ce que ça vient de DHCP, d’une statique, d’un VPN
• présence d’un suffixe DNS chelou
• plusieurs interfaces actives (Ethernet + Wi-Fi + VPN) qui se battent

Si tu vois un DNS du type 192.168.1.1 dans un environnement pro qui a un AD, ça peut être normal (box en relais) ou totalement foireux. À creuser.

4) tester la résolution via le DNS configuré (nslookup simple)

Windows et Linux : bash nslookup www.google.com

Tu notes :

• le serveur interrogé (tout en haut)
• si la réponse arrive vite
• si tu as des timeouts

Si nslookup te répond instantanément mais le navigateur rame, tu n’es peut être pas sur DNS. Ou alors tu as un souci DoH, proxy, inspection TLS. On y revient plus bas.

5) tester en forçant un DNS public (pour isoler le résolveur)

Toujours nslookup, mais en forçant le serveur :

bash nslookup www.google.com 1.1.1.1

Puis : bash nslookup www.google.com 8.8.8.8

• Si ça marche avec 1.1.1.1 mais pas avec ton DNS interne, ton résolveur interne est en cause (ou sa sortie vers internet, ou ses forwarders).
• Si ça ne marche avec aucun, c’est plutôt réseau sortant, filtrage UDP 53, ou un portail captif, ou un proxy obligatoire.

6) vérifier la résolution du domaine qui pose problème (pas juste google)

Les utilisateurs ne se plaignent pas de google, ils se plaignent de intranet.entreprise.local, vpn.client.tld, m365 ou d’un SaaS précis.

bash nslookup le-service-qui-plante.tld

Puis, pour voir plus de détails :

bash nslookup -type=any le-service-qui-plante.tld

-type=any n’est plus aussi magique qu’avant (beaucoup de serveurs limitent), donc teste aussi en ciblant :

bash nslookup -type=a le-service-qui-plante.tld nslookup -type=aaaa le-service-qui-plante.tld nslookup -type=cname le-service-qui-plante.tld

Le classique : un CNAME en chaîne qui renvoie vers un domaine mal résolu.

7) comparer A vs AAAA (le piège IPv6)

Parfois tout « marche » en IPv4, mais l’IPv6 est partiellement cassé. Résultat : le poste préfère IPv6, tente, échoue, retente en IPv4. Sensation utilisateur : « internet est lent ».

Teste :

bash nslookup -type=aaaa www.google.com nslookup -type=a www.google.com

Si tu as des AAAA mais que ton réseau IPv6 ne route pas correctement, c’est suspect. Même chose si l’IPv6 sort via un chemin filtré.

Sur un poste, tu peux aussi tester la connectivité IPv6 :

Windows : bat ping -6 ipv6.google.com

Linux : bash ping -6 -c 3 ipv6.google.com

8) vérifier le cache DNS local (et le purger quand il faut)

Windows : bat ipconfig /displaydns

Purger : bat ipconfig /flushdns

Sur Linux avec systemd-resolved : bash sudo resolvectl flush-caches

Attention : purger le cache règle parfois un souci temporaire, mais ça ne t’explique pas pourquoi. Donc note le symptôme, l’heure, et si ça revient.

9) vérifier le fichier hosts (le sabotage discret)

Ça paraît bête. Mais c’est un vrai classique, surtout en TP, en malware, en blocage maison.

Windows : C:\Windows\System32\drivers\etc\hosts

Linux : /etc/hosts

Cherche une entrée du domaine concerné. Une redirection vers 127.0.0.1, ou vers une IP ancienne.

10) vérifier le suffixe DNS et la résolution « courte »

Exemple : l’utilisateur tape intranet au lieu de intranet.domaine.local.

Windows :

• regarde dans ipconfig /all les « suffixes DNS spécifiques à la connexion »
• ou dans la config DHCP

Test rapide : bash nslookup intranet nslookup intranet.domaine.local

Si le FQDN marche mais pas le court, c’est suffix search list, GPO, DHCP option 015, etc.

11) tester la résolution d’un enregistrement SRV (spécial AD)

Si tu es en environnement Active Directory, DNS n’est pas « juste pour internet ». Il est vital pour les SRV.

Test typique :

bash nslookup -type=srv _ldap._tcp.dc._msdcs.domaine.local

• Si ça ne répond pas, tu peux avoir des soucis d’ouverture de session, de GPO, de scripts, de découverte DC.
• Si ça répond mais avec de vieux DC, tu as peut être des zones pas répliquées, ou des enregistrements dynamiques cassés.

Pour résoudre ces problèmes de DNS non résolus sur Windows 11, il existe plusieurs étapes que tu peux suivre. Pour plus de détails sur cette procédure, je te recommande de consulter ce guide détaillé.

12) tester directement l’autorité (dig +trace, ou nslookup avancé)

Sur Linux, dig est ton meilleur ami.

bash dig le-service-qui-plante.tld

Et surtout :

bash dig +trace le-service-qui-plante.tld

Ça te montre où ça casse dans la chaîne (racines, TLD, autoritatif). Si tu n’as pas dig sous Windows, installe les outils RSAT, BIND tools, ou fais le test depuis une VM d’admin.

Tu peux aussi questionner les NS déclarés :

bash dig ns le-service-qui-plante.tld dig @ns1.exemple.tld le-service-qui-plante.tld

Quand ça répond chez l’autoritatif mais pas chez ton résolveur, tu as un problème de récursion, de cache, de DNSSEC, ou de forwarders.

13) vérifier DNSSEC (quand « ça marche ailleurs »)

DNSSEC peut provoquer des pannes bizarres : chez certains résolveurs ça passe, chez d’autres non.

Indices :

• erreurs « SERVFAIL » sur un domaine précis
• le domaine fonctionne avec un DNS mais pas un autre

Test rapide (Linux) : bash dig +dnssec le-domaine.tld

Si tu vois des erreurs de validation côté résolveur, ou des chaînes DS/DNSKEY incohérentes, c’est un sujet DNSSEC.

En entreprise, certains résolveurs filtrants valident DNSSEC, d’autres non. Et parfois… c’est le firewall qui manipule.

14) vérifier le proxy, l’interception, et le DoH du navigateur

Là, on sort un peu du « pur DNS », mais c’est exactement le genre de truc qui te fait accuser DNS à tort.

Points rapides :

• le navigateur utilise peut être DNS over HTTPS et contourne le DNS système
• un proxy ou une inspection TLS peut renvoyer des pages d’erreur qui ressemblent à un problème de nom
• un agent de sécurité peut forcer un résolveur interne

Tests utiles :

• compare nslookup (DNS système) vs résolution dans le navigateur
• désactive temporairement DoH dans Firefox / Chrome (en test, pas en prod à l’arrache)
• vérifie la présence d’un PAC, d’un proxy explicite, ou d’un WPAD

Si nslookup marche mais le navigateur dit « DNS_PROBE_FINISHED_NXDOMAIN », tu as une piste.

15) mesurer la latence DNS (quand « c’est lent » plus que « c’est cassé »)

Souvent le ticket dit : « Ça met 20 secondes à ouvrir le site. »

Fais un test de temps de requête.

Linux : bash dig www.google.com +stats

Tu regardes [Query time](https://dnsrobot.net/fr/blog/verizon-dns-servers).

Sur Windows, tu peux chronométrer à la main, ou utiliser PowerShell :

powershell Measure-Command { Resolve-DnsName www.google.com | Out-Null }

Si tu vois des temps énormes :

• DNS qui time out avant de basculer sur un second serveur
• serveur DNS saturé
• forwarder qui ne répond pas
• MTU, fragmentation UDP, filtrage, ou EDNS0 mal supporté

---

petite méthode pour aller vite (et ne pas te perdre)

Quand tu es en diag, garde une logique simple :

1. IP marche ? si non, ce n’est pas DNS.
2. Nom marche via DNS public ? si oui, ton DNS interne ou ses règles.
3. Nom marche sur un autre poste ? si oui, cache local, interface, GPO, sécurité.
4. Le domaine est interne AD ? teste SRV, réplication, dynamique, scavenging.
5. Ça dépend du navigateur ? pense DoH, proxy, agent.

Et note tout. Heure, réseau, interface active, serveur DNS interrogé. Ça te sauve quand tu dois escalader.

mini checklist imprimable (version courte)

• ping 1.1.1.1
• ping nomdedomaine.tld
• ipconfig /all ou resolvectl status
• nslookup nomdedomaine.tld
• nslookup nomdedomaine.tld 1.1.1.1
• nslookup -type=a ... et -type=aaaa ...
• purge cache DNS
• vérifier hosts
• vérifier suffixes DNS
• test SRV AD
• dig +trace si possible
• suspicion DNSSEC si SERVFAIL
• vérifier DoH / proxy si décalage navigateur vs système
• mesurer latence

Tu peux littéralement en faire une fiche mémo pour ton classeur E4, ou ton wiki interne.

pour aller plus loin (et se faire la main)

Si tu veux t’entraîner, le plus formateur c’est de monter un petit lab :

• un Windows Server avec DNS
• un client Windows
• un routeur virtuel ou un pfSense
• et tu casses volontairement : forwarders, DNSSEC, IPv6, suffixes, cache, etc

Sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), l’idée du site c’est justement ça : des labs simples, des procédures, et du retour d’expérience orienté SISR. Donc si tu veux plus de contenu du même style, tu peux le garder en favori. Ça évite de réinventer la roue en pleine astreinte.

conclusion

Avant d’accuser « internet », fais ces 15 tests. Pas parce que c’est fun, mais parce que ça évite de partir dans tous les sens.

DNS, c’est souvent invisible quand tout va bien. Et quand ça va mal… ça ressemble à tout et n’importe quoi. Donc on teste, on isole, et on accuse ensuite, calmement.

Questions fréquemment posées

Comment savoir si un problème de connexion vient vraiment du DNS ?

Pour vérifier si le souci vient du DNS, essayez d'abord d'accéder à une adresse IP directe comme https://1.1.1.1 ou https://8.8.8.8. Si l'IP répond mais pas les noms de domaine, le problème est probablement lié à la résolution DNS.

Que signifie un message "impossible de trouver l’hôte" lors d'un ping sur un nom de domaine ?

Ce message indique généralement un problème de résolution DNS ou un souci avec les suffixes DNS configurés sur la machine.

Comment vérifier la configuration DNS actuelle de mon poste ?

Sur Windows, utilisez la commande 'ipconfig /all'. Sur Linux, vous pouvez utiliser 'resolvectl status' ou consulter le fichier '/etc/resolv.conf'. Cela permet d'identifier les serveurs DNS configurés, la source (DHCP, statique, VPN) et détecter des configurations anormales.

Comment tester rapidement la résolution DNS via le serveur configuré ?

Utilisez la commande 'nslookup www.google.com' pour interroger directement le serveur DNS configuré. Notez le serveur interrogé, la rapidité de réponse et la présence éventuelle de timeouts.

Pourquoi forcer l'utilisation d'un DNS public comme 1.1.1.1 ou 8.8.8.8 lors des tests ?

Forcer un DNS public permet d'isoler si le problème vient du résolveur interne ou du réseau sortant. Si la résolution fonctionne avec un DNS public mais pas avec celui interne, le résolveur interne est suspect.

Comment diagnostiquer la résolution d'un domaine spécifique qui pose problème ?

Utilisez 'nslookup' sur le domaine en question (ex: nslookup intranet.entreprise.local). Pour plus de détails, testez différents types d'enregistrements comme A, AAAA ou CNAME avec des commandes comme 'nslookup -type=a domaine.tld'. Cela aide à comprendre si le problème est spécifique au domaine concerné.