Corriger le DNS sous Windows : Arrêtez d’utiliser « ipconfig /flushdns » comme un rituel

février 25, 2026 • février 25, 2026 • Lecture : 25 min • Views: 0

Cet article vous a aidé ?

Si vous lisez ceci, vous avez probablement vu quelqu’un taper ipconfig /flushdns avec l’assurance d’un magicien lançant un sort. Parfois cela « marche », parfois rien ne change, et parfois cela aggrave la situation en effaçant la seule piste utile que vous aviez : ce que la machine pensait être vrai cinq secondes plus tôt.

Les pannes DNS sous Windows se règlent rarement avec une seule commande. Elles se règlent en comprenant quel résolveur est en jeu, quel cache ment et quel composant réseau vous « aide » à creuser un trou. Arrêtons les exorcismes DNS et faisons du diagnostic.

Ce que `flushdns` fait réellement (et ce qu’il ne fait pas)

ipconfig /flushdns vide le cache du résolveur DNS Client de Windows. C’est tout. Cela ne :

Change pas les serveurs DNS que vous utilisez.
Ne corrige pas une stratégie DNS cassée d’un VPN.
Ne rétablit pas une mauvaise liste de suffixes de recherche.
Ne supprime pas un enregistrement obsolète sur le serveur DNS de votre entreprise.
Ne réinitialise pas Winsock, les règles de pare-feu ou les paramètres de proxy.
Ne corrige pas une application qui effectue son propre DNS (beaucoup le font).

Il peut aider lorsque le cache contient une mauvaise réponse ou une entrée négative (NXDOMAIN) que vous souhaitez re-vérifier immédiatement. Il peut aussi masquer les preuves lorsqu’on cherche à savoir si l’échec est « cache local » ou « DNS en amont ». Vous ne voulez pas effacer les preuves avant de savoir ce que vous regardez.

Deux réalités importantes :

Les problèmes DNS sont souvent des problèmes de politique. La machine fait exactement ce qu’on lui a dit, et ce qu’on lui a dit est faux.
Windows n’est pas votre seul résolveur. Les navigateurs, clients VPN, agents de sécurité et outils de gestion des postes peuvent introduire leurs propres caches et comportements DNS.

Voici l’état d’esprit opérationnel : traitez flushdns comme le redémarrage d’un service. Parfois c’est une étape utile en dernier recours. Ce n’est pas une première étape. Si votre premier geste est de supprimer l’état, vous avez choisi la cécité.

Playbook de diagnostic rapide

Ceci est la séquence « vous êtes en appel, quelqu’un hurle, et vous avez besoin d’information en 90 secondes ». Exécutez-la dans l’ordre. Ne faites pas de freestyle avant d’avoir identifié la catégorie de panne.

1) Est-ce du DNS ou pas du DNS ?

Pouvez-vous atteindre une adresse IP mais pas un nom ?
Est-ce qu’un seul nom d’hôte échoue ou tous les noms ?
Est-ce seulement à l’intérieur des domaines d’entreprise (par ex., corp.example) ?

2) Identifier le chemin DNS actif

Quelle interface est utilisée (Wi‑Fi, Ethernet, VPN, adaptateur virtuel) ?
Quels serveurs DNS sont configurés sur cette interface maintenant ?
Un VPN impose-t-il un DNS ou un split tunneling ?

3) Comparer les résolveurs

nslookup réussit-il pendant que le navigateur échoue ?
PowerShell Resolve-DnsName donne-t-il des résultats différents de nslookup ?

4) Vérifier le cache et le cache négatif

Le cache local contient-il NXDOMAIN ?
Êtes-vous en train de courir contre des TTL (réponses qui changent pendant l’incident) ?

5) Seulement ensuite : réinitialiser/vider comme expérience contrôlée

Videz le cache et requêtez à nouveau le même nom.
Consignez ce qui a changé. Si rien n’a changé, arrêtez de vider le cache.

Idée paraphrasée de David J. Wheeler : Tous les problèmes en informatique peuvent être résolus en ajoutant une couche d’indirection de plus — sauf les problèmes causés par l’indirection. Le DNS, c’est de l’indirection avec des sentiments.

Comment Windows résout les noms : l’ordre réel des opérations

Quand quelqu’un dit « le DNS est cassé », il veut généralement dire « la résolution de noms est cassée ». Sous Windows, la résolution de noms peut impliquer :

Fichier hosts (C:\Windows\System32\drivers\etc\hosts)
Service DNS Client (cache + interrogation des serveurs DNS configurés)
Liste de suffixes de recherche DNS (transformer app en app.corp.example)
LLMNR (Link-Local Multicast Name Resolution) et NetBIOS dans certains environnements
mDNS pour les scénarios .local (dépend des composants installés)
Proxy et scripts PAC (pas du DNS, mais donne l’impression d’un « impossible d’atteindre par nom »)
Résolveurs applicatifs (navigateurs et runtimes peuvent mettre en cache ou utiliser DoH)

Certains de ces éléments sont « utiles » jusqu’à ce qu’ils ne le soient plus. Par exemple :

Si hosts remplace un nom, vider le DNS ne le modifiera pas. Cet override l’emporte.
Si votre navigateur utilise DNS sur HTTPS (DoH), vider le DNS de Windows peut ne pas toucher le chemin de résolution du navigateur.
Si le serveur DNS est correct mais que vous interrogez le mauvais (l’adaptateur VPN a pris la priorité), vider ne corrige pas la priorité.

Une nuance de plus : nslookup n’est pas « le résolveur Windows ». C’est un outil de diagnostic qui parle à un serveur DNS. Il peut contourner des parties de la pile de résolution et du comportement de mise en cache de Windows. Quand nslookup fonctionne mais qu’une application ne fonctionne pas, ce n’est pas une contradiction — c’est votre indice.

Blague #1 : Vider le DNS pour tout corriger, c’est comme redémarrer une imprimante pour régler votre déclaration d’impôts. Ça change votre humeur, pas les faits.

Faits intéressants et contexte historique (parce que c’est devenu étrange avec le temps)

Le DNS est plus ancien que le web. Le DNS a été conçu au début des années 1980 pour remplacer les fichiers HOSTS.TXT manuels qui ne montaient pas en charge.
Le cache négatif est volontaire. Mettre en cache NXDOMAIN évite de marteler les serveurs faisant autorité avec des requêtes répétées pour des noms inexistants.
Le cache du client DNS Windows a été conçu pour être « collant ». Le cache existe pour réduire la latence et la charge, ce qui en fait un suspect lors d’incidents à évolution rapide.
Les suffixes de recherche ont été conçus pour les humains. Les entreprises voulaient que mail ou intranet fonctionne sans taper un domaine complet à chaque fois.
Le split DNS précède la mode moderne du VPN. Les grandes organisations ont longtemps eu besoin de réponses internes pour des zones internes, et d’autres réponses quand elles sont hors réseau.
LLMNR existe parce que les gens détestent taper. C’est un protocole de commodité pour les réseaux locaux, mais c’est aussi un risque de sécurité et souvent désactivé dans les environnements durcis.
DoH est en partie une réaction aux réseaux hostiles. Chiffrer les requêtes DNS réduit l’espionnage et la falsification sur le trajet, mais peut compliquer la politique d’entreprise et la réponse aux incidents.
EDNS0 et des réponses plus grandes ont changé les modes de défaillance. Les réponses DNS ont grossi (pensez DNSSEC, beaucoup d’enregistrements), et les problèmes de PMTU/fragmentation ont commencé à apparaître comme des « timeouts DNS aléatoires ».
« DNS server not responding » est souvent un mensonge. Le serveur DNS peut être sain ; le client peut être bloqué pour l’atteindre sur UDP/TCP 53, ou il interroge la mauvaise interface.

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

Chaque tâche ci‑dessous inclut une commande, ce que la sortie signifie et la décision à prendre. Utilisez-les comme boîte à outils. Ne les exécutez pas comme un script trouvé sur un forum.

Tâche 1 : Confirmer quels serveurs DNS Windows utilise réellement

cr0x@server:~$ ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . : LPT-0442
   Primary Dns Suffix  . . . . . . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . . : corp.example
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11

Ethernet adapter VPN:

   Connection-specific DNS Suffix  . . : vpn.corp.example
   DNS Servers . . . . . . . . . . . : 172.16.50.53

Sens : Vous pouvez avoir plusieurs adaptateurs, chacun avec des serveurs DNS différents. Windows choisira en fonction des métriques d’interface et des politiques.

Décision : Si l’adaptateur VPN est actif et possède un serveur DNS, validez s’il doit être autoritaire pour les noms en échec. Sinon, vous regardez un problème de priorité/métrique ou de politique VPN, pas un problème de cache.

Tâche 2 : Identifier quelle interface est préférée (métriques)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 | Format-Table -AutoSize"

ifIndex InterfaceAlias     AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp   ConnectionState
------- --------------     ------------- ------------ --------------- ----   ---------------
24      VPN               IPv4          1400         5               Enabled Connected
12      Ethernet          IPv4          1500         25              Enabled Connected
9       Wi-Fi             IPv4          1500         55              Enabled Connected

Sens : La métrique la plus basse gagne. Ici, le VPN est préféré pour le trafic IPv4 et souvent pour le comportement DNS.

Décision : Si les échecs DNS surviennent uniquement quand le VPN est connecté, concentrez-vous sur les serveurs DNS du VPN, la configuration du split DNS et les NRPT/politiques. Ne perdez pas de temps à flushdns pour l’instant.

Tâche 3 : Interroger en utilisant le résolveur Windows (pas nslookup)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName app.corp.example -Type A"

Name           Type TTL Section IPAddress
----           ---- --- ------- ---------
app.corp.example A   30 Answer  10.30.40.25

Sens : Cela montre ce que le résolveur Windows renvoie et le TTL qu’il voit.

Décision : Si Resolve-DnsName échoue mais que nslookup fonctionne, vous avez probablement une politique locale/de cache ou un problème d’ordre de résolution. Si les deux échouent, suspectez le DNS en amont ou l’atteignabilité réseau.

Tâche 4 : Interroger un serveur DNS spécifique pour contourner « ce que Windows a choisi »

cr0x@server:~$ nslookup app.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    app.corp.example
Address: 10.30.40.25

Sens : Cela confirme si le serveur DNS ciblé peut répondre correctement.

Décision : Si interroger un serveur connu bon fonctionne mais que les requêtes par défaut échouent, focalisez-vous sur quel serveur DNS le client utilise réellement (ordre des adaptateurs, VPN, options DHCP, DNS statique, agent de sécurité).

Tâche 5 : Vérifier le cache négatif et ce qui est dans le cache

cr0x@server:~$ ipconfig /displaydns

    app.corp.example
    ----------------------------------------
    Record Name . . . . . : app.corp.example
    Record Type . . . . : 1
    Time To Live  . . . . : 18
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . . : 10.30.40.25

Sens : Vous pouvez voir ce que Windows a mis en cache et combien de temps il compte le garder.

Décision : Si le cache contient NXDOMAIN ou une ancienne IP qui ne route plus, vider peut être justifié. Mais demandez-vous : pourquoi est‑ce faux ? Serveur en amont erroné ? Split brain ? Enregistrements obsolètes ? Corrigez la source.

Tâche 6 : Vider le cache DNS (comme test contrôlé)

cr0x@server:~$ ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Sens : Cache effacé. Aucune garantie que la réponse suivante sera meilleure.

Décision : Re-lancez immédiatement la même requête et comparez. Si la réponse ne change pas, le cache n’était pas le problème.

Tâche 7 : Vérifier que le service DNS Client est en cours d’exécution

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache | Format-List Status,Name,StartType"

Status    : Running
Name      : Dnscache
StartType : Automatic

Sens : Le service DNS Client fournit la mise en cache et une partie de la logique de résolution.

Décision : S’il est arrêté/désactivé (parfois à cause de guides de « tuning »), attendez‑vous à des comportements étranges et à une faible performance. Remettez‑le en marche sauf si vous avez un environnement contrôlé et testé.

Tâche 8 : Vérifier le comportement des suffixes de recherche (pourquoi les noms courts échouent)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientGlobalSetting | Format-List SuffixSearchList"

SuffixSearchList : {corp.example, prod.corp.example}

Sens : Quand vous tapez app, Windows peut essayer app.corp.example et d’autres suffixes.

Décision : Si des utilisateurs indiquent que « les noms courts fonctionnaient avant », validez la distribution de la liste de suffixes (GPO, option DHCP 15/119, politique VPN). Corrigez la liste de suffixes, pas le cache.

Tâche 9 : Confirmer quels serveurs DNS sont définis par interface (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias ServerAddresses
-------------- ---------------
Ethernet       {10.20.0.10, 10.20.0.11}
VPN            {172.16.50.53}
Wi-Fi          {192.168.1.1}

Sens : Cela rend évident quand le DNS du Wi‑Fi domestique ou d’un portail captif d’hôtel entre dans le jeu.

Décision : Si vous voyez un DNS public ou grand public sur une interface qui ne devrait pas être autoritaire pour des zones internes, utilisez correctement le split DNS (VPN) ou ajustez la priorité des interfaces.

Tâche 10 : Tester l’atteignabilité des serveurs DNS (ne présumez pas « répond »)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.0.10 -Port 53"

ComputerName     : 10.20.0.10
RemoteAddress    : 10.20.0.10
RemotePort       : 53
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Sens : Le DNS utilise principalement UDP, mais TCP 53 compte pour les réponses volumineuses et les reprises. Cela prouve au moins un chemin jusqu’au TCP 53.

Décision : Si le TCP 53 échoue, vous avez peut‑être des règles de pare‑feu, des ACL VPN ou un logiciel de sécurité qui bloque le DNS. C’est une correction réseau/sécurité, pas une correction par vidage de cache.

Tâche 11 : Détecter si un proxy/PAC fait croire à un problème DNS

cr0x@server:~$ netsh winhttp show proxy

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy.corp.example:8080
    Bypass List     :  (none)

Sens : Certaines applications utilisent les paramètres WinHTTP proxy. Un proxy cassé peut ressembler à un « problème DNS » car l’application ne peut rien récupérer par nom.

Décision : Si le nom se résout mais que HTTP échoue, inspectez le proxy/PAC et l’authentification. Ne continuez pas à titiller le DNS.

Tâche 12 : Vérifier le fichier hosts pour des mines

cr0x@server:~$ type C:\Windows\System32\drivers\etc\hosts

# Copyright (c) Microsoft Corp.
# ...
10.30.40.99   app.corp.example

Sens : Cette unique ligne remplace DNS. Pour toujours. Jusqu’à ce que quelqu’un se rappelle qu’il existe.

Décision : Si le fichier hosts fixe une ancienne adresse, retirez‑la et documentez pourquoi elle était là. Si elle est requise (rare), gérez‑la de façon centrale, pas par connaissance tribale.

Tâche 13 : Réinitialiser Winsock (seulement quand les symptômes correspondent)

cr0x@server:~$ netsh winsock reset

Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Sens : Cela répare certains problèmes au niveau des sockets causés par des LSPs ou des logiciels réseau, pas les « enregistrements DNS ».

Décision : Utilisez‑le quand plusieurs opérations réseau échouent de manière étrange (pas seulement un nom d’hôte). Préparez‑vous à un redémarrage. Si seul le DNS est affecté, c’est probablement excessif.

Tâche 14 : Réinitialiser la pile IP (quand le comportement d’interface est corrompu)

cr0x@server:~$ netsh int ip reset

Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting , OK!
Restart the computer to complete this action.

Sens : Réinitialise la configuration TCP/IP aux valeurs par défaut.

Décision : Utilisez‑la quand vous suspectez que la pile est empoisonnée par des pilotes, clients VPN ou ajustements manuels. Si le problème est clairement en amont DNS, cela n’aidera pas.

Tâche 15 : Release/renew DHCP (quand les serveurs DNS viennent du DHCP)

cr0x@server:~$ ipconfig /release

Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Sens : Ici l’Ethernet n’est pas connecté, donc release ne s’applique pas. C’est en soi un indice.

Décision : Exécutez‑le sur l’interface active. Si les serveurs DNS sont faux à cause des options DHCP, renew peut récupérer les bons paramètres—si le DHCP est configuré correctement. Si le DHCP est erroné, corrigez le DHCP, pas les postes.

Tâche 16 : Valider si le nom en échec retourne plusieurs adresses (et si l’une est morte)

cr0x@server:~$ nslookup api.corp.example 10.20.0.10

Server:  dc01.corp.example
Address:  10.20.0.10

Name:    api.corp.example
Addresses: 10.30.40.10
          10.30.40.11
          10.30.40.12

Sens : Le round-robin ou les enregistrements multi‑A peuvent rendre les pannes « intermittentes » si un backend est en panne.

Décision : Si une IP est morte, ne videz pas les caches des clients. Supprimez / contrôlez cet enregistrement, corrigez la stratégie d’équilibrage, ou réparez le backend en panne.

Erreurs courantes : symptôme → cause racine → correction

C’est là que la plupart des équipes perdent du temps : elles traitent un symptôme comme un diagnostic. Voici les récidivistes.

1) « Le DNS est cassé » mais un seul site échoue

Symptôme : Seul app.corp.example échoue ; tout le reste se résout et fonctionne.

Cause racine : Enregistrement DNS obsolète, attentes TTL erronées, ou nom multi‑enregistrement où une IP est morte.

Correction : Interrogez les serveurs faisant autorité directement et inspectez les enregistrements. Supprimez les mauvais enregistrements, abaissez le TTL pour les migrations, assurez-vous que la surveillance retire les endpoints morts du DNS ou qu’un load balancer protège cela.

2) `nslookup` fonctionne, le navigateur non

Symptôme : nslookup montre une IP correcte, mais Chrome/Edge dit que le nom ne peut pas être résolu ou que la connexion échoue.

Cause racine : DoH activé dans le navigateur, cache DNS du navigateur obsolète, problème de proxy/PAC, ou le navigateur tente IPv6 en premier et échoue.

Correction : Vérifiez les paramètres DNS du navigateur (y compris DNS sécurisé/DoH), videz le cache DNS du navigateur si nécessaire, validez la configuration du proxy, comparez la résolution IPv4 vs IPv6 et la connectivité.

3) Fonctionne sur VPN, échoue hors VPN (ou inverse)

Symptôme : Les noms internes se résolvent uniquement quand le VPN est connecté, ou le VPN casse la résolution publique.

Cause racine : Split DNS mal configuré ; le VPN pousse le serveur DNS pour tout ; les métriques d’interface font préférer le mauvais adaptateur.

Correction : Corrigez le split tunnel et les politiques DNS dans le client/profil VPN. Assurez‑vous que les zones internes vont vers le DNS d’entreprise, les zones publiques vers le résolveur local (ou un résolveur sanctionné), et que les métriques se comportent comme prévu.

4) Timeouts aléatoires après « durcissement de sécurité »

Symptôme : Le DNS timeoute parfois ; les reprises réussissent ; les réponses volumineuses échouent plus souvent.

Cause racine : Pare‑feu qui bloque TCP 53 ou fragments ; réponses DNS dépassant le MTU ; logiciel de sécurité interceptant le DNS.

Correction : Autorisez UDP et TCP 53 quand approprié, validez le MTU (surtout avec VPN), et assurez‑vous que les produits d’inspection DNS sont compatibles et correctement configurés.

5) Les noms courts ont cessé de fonctionner

Symptôme : intranet fonctionnait avant ; maintenant seul intranet.corp.example fonctionne.

Cause racine : La liste de suffixes de recherche a changé (GPO, option DHCP, politique VPN), ou vous avez changé de réseau avec des politiques de suffixes différentes.

Correction : Restaurez la liste de suffixes correcte et rendez‑la déterministe (GPO pour les appareils joint au domaine, options DHCP bien définies, paramètres VPN cohérents).

6) « Flushdns a corrigé hier » devient le processus de l’équipe

Symptôme : Les gens vident les caches quotidiennement ; les notes d’incident indiquent « résolu par flushdns ».

Cause racine : Churn d’enregistrements DNS sous‑jacent, migrations avec TTL bas, ou pannes intermittentes en amont — vider force simplement une nouvelle requête qui parfois touche un serveur bon.

Correction : Ajoutez de l’observabilité : journalisez la santé des serveurs DNS, mesurez les taux NXDOMAIN, vérifiez la réplication/les transferts de zone, et arrêtez d’utiliser les postes comme canaris.

Trois mini-récits en entreprise (comment ça échoue en vrai)

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

Dans une entreprise de taille moyenne, une équipe a migré un service interne d’un sous‑réseau à un autre. Ils ont mis à jour l’enregistrement A, ont vu la nouvelle IP se résoudre sur leurs propres portables, et ont déclaré victoire. Quelques heures plus tard, la moitié des tickets du helpdesk étaient « impossible de se connecter », et l’autre moitié « ça marche pour moi ». Le pire genre de panne : l’ outage Schrödinger.

L’hypothèse erronée était simple : « Une fois qu’on met à jour le DNS, tout le monde le verra rapidement. » Le TTL n’était pas bas, et certains clients gardaient d’anciennes réponses. Pire, une poignée de serveurs applicatifs utilisaient un cache DNS local dans le runtime, avec un TTL par défaut qui ignorait le TTL de l’enregistrement. Ce sont eux qui échouaient le plus, et ce sont eux que personne n’a vérifiés en premier.

L’équipe de réponse a commencé par des conseils sur les postes. Vider le DNS. Redémarrer les navigateurs. Rebooter. Prévisible, cela a « réparé » certaines machines et n’a rien touché aux serveurs importants. Chaque vidage rendait le dépannage plus bruyant parce que l’état mis en cache était constamment détruit et recréé.

La correction fut ennuyeuse : ils ont validé le TTL, identifié les serveurs faisant autorité, confirmé la réplication, puis déroulé la migration avec une fenêtre de chevauchement planifiée. Ils ont aussi documenté les paramètres de cache DNS au niveau runtime et les ont ajustés pour respecter les TTL ou utiliser une bibliothèque de résolveur avec un comportement de cache sensé.

Après le postmortem, l’équipe a banni la note « flushdns fixed it ». Si vous ne pouvez pas dire ce qui était cassé, vous ne l’avez pas réparé — vous avez juste arrêté d’y regarder.

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

Une équipe de sécurité a déployé une baseline « amélioration de la vie privée » : privilégier le DNS chiffré. Sur le papier, cela réduisait l’exposition aux Wi‑Fi hostiles. En production, cela a cassé le split DNS pour les zones internes parce que ces résolveurs externes approuvés ne savaient rien des noms internes.

Au début, les symptômes étaient subtils. Les sites publics fonctionnaient. Les applications internes échouaient de façon intermittente, surtout hors réseau. Les gens ont d’abord blâmé l’instabilité du VPN. Le helpdesk a blâmé les portables. L’équipe VPN a blâmé le DNS. Chacun avait raison de la pire manière possible.

Pendant ce temps, certaines applications utilisaient le résolveur OS ; d’autres utilisaient des résolveurs embarqués. Ainsi la même machine pouvait résoudre git.corp.example dans un outil mais pas dans un autre. Les ingénieurs ont commencé à écrire un one‑liner « fix DNS » qui vidait les caches, redémarrait des services et togglait des adaptateurs. Ça réduisait les tickets tout en rendant l’analyse racine plus difficile.

La correction finale n’était pas « désactiver DoH à jamais ». C’était implémenter une politique qui respectait le split DNS : les zones internes vers le DNS corporate (souvent via VPN), tandis que les zones publiques pouvaient utiliser le DNS chiffré si autorisé. Ils ont aussi amélioré la télémétrie : « quel résolveur a réellement utilisé cette requête ? » était le graphe manquant.

Blague #2 : DNS over HTTPS, c’est génial jusqu’au moment où il faut du DNS over « Pourquoi rien ne se résout ? »

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

Une société financière avait un processus de changement DNS rigide. Les ingénieurs le détestaient car il exigeait un ticket, une revue par les pairs et un champ obligatoire « TTL et plan de rollback ». Ça ressemblait à de la bureaucratie jusqu’au jour où une zone interne a été mise à jour par erreur avec une faute de frappe pointant un service critique vers une IP inexistante.

L’incident a commencé par une pluie d’alertes : échecs de connexion, tentatives répétées, pannes partielles. Quelqu’un a proposé de vider les caches en appel. Le commandant d’incident a dit non — gardez l’état, rassemblez les preuves. C’est ce moment où la discipline a payé.

Ils ont récupéré l’ensemble des enregistrements actuels des serveurs faisant autorité, les ont comparés à la demande de changement approuvée, et ont vu l’écart immédiatement. Parce que le processus de changement exigeait d’enregistrer les valeurs précédentes, le rollback a été propre. Parce qu’ils exigeaient un plan TTL, l’étendue de la casse était prévisible. Et parce qu’ils avaient un runbook commençant par « vérifier les faisant autorité », ils n’ont pas perdu 45 minutes à débattre sur quel portable avait quel cache.

La correction a pris quelques minutes, pas parce qu’ils étaient brillants, mais parce qu’ils étaient consistants. « Ennuyeux » est un compliment en exploitation.

Checklists / plan pas à pas

Voici le plan que vous pouvez remettre à une équipe et attendre des résultats à peu près cohérents. Il évite la superstition et vous force à décider sur la base des preuves.

Checklist A : Quand un utilisateur dit « le DNS est en panne »

Obtenez le(s) nom(s) exact(s) en échec et le(s) message(s) d’erreur. Un nom ou plusieurs ?
Demandez si ça échoue sur VPN, hors VPN, ou les deux.
Exécutez ipconfig /all et capturez serveurs DNS et suffixes.
Exécutez Resolve-DnsName the.name et sauvegardez la sortie.
Exécutez nslookup the.name configured-dns-server pour valider l’amont.
Si les résultats diffèrent, identifiez quel chemin de résolveur l’application utilise (DoH du navigateur, proxy).
Seulement après cela : considérez ipconfig /displaydns et /flushdns comme test contrôlé.

Checklist B : Quand seuls les noms internes échouent

Confirmez que l’utilisateur utilise les serveurs DNS corporate (pas le DNS du routeur domestique).
Vérifiez les métriques de l’adaptateur VPN et ses serveurs DNS.
Validez que la liste de suffixes de recherche inclut le domaine interne.
Interrogez directement le serveur faisant autorité pour la zone interne.
Inspectez si le nom interne existe accidentellement dans le DNS public (risque de split‑brain).

Checklist C : Quand les pannes sont intermittentes

Interrogez plusieurs fois et enregistrez les réponses et TTL. Cherchez des adresses en rotation.
Testez la connectivité vers chaque IP retournée (ping ne suffit pas ; testez le port/protocole réel).
Cherchez un backend mort dans un ensemble multi‑A.
Validez l’atteignabilité UDP et TCP 53 vers les serveurs DNS (surtout via VPN).
Vérifiez si un produit de sécurité intercepte les requêtes DNS ou réécrit les réponses.

Plan pas à pas « arrêter l’hémorragie » pour le helpdesk

Collectez : nom d’hôte en échec, si le VPN est connecté, et un horodatage.
Exécutez et collez : ipconfig /all.
Exécutez et collez : nslookup failing.name et nslookup failing.name <dns server from ipconfig>.
Si le serveur DNS dans ipconfig est erroné (par ex., routeur domestique alors que VPN actif), escaladez vers VPN/réseau avec cette preuve.
Si le serveur DNS est correct mais que les réponses sont erronées, escaladez vers les opérations DNS avec les preuves des enregistrements.
Seulement si le cache contient clairement une mauvaise réponse : exécutez ipconfig /flushdns et retestez. Documentez avant/après.

FAQ

1) Pourquoi `ipconfig /flushdns` « règle » parfois le problème ?

Parce que vous forcez une nouvelle requête, et la requête suivante a pu toucher un autre serveur DNS, un chemin différent (le VPN s’est établi), ou l’enregistrement venait d’être corrigé en amont. C’est de la corrélation, pas une correction durable.

2) Si vider n’est pas le premier geste, que faire en premier ?

Identifiez les serveurs DNS et l’interface en usage (ipconfig /all plus métriques d’interface), puis comparez les résultats du résolveur OS (Resolve-DnsName) avec des requêtes directes aux serveurs (nslookup name server).

3) Pourquoi `nslookup` n’est pas d’accord avec ce que font les applications ?

nslookup interroge un serveur DNS directement et ne reflète pas toujours le comportement complet du résolveur Windows, le comportement des suffixes de recherche, ou le DNS spécifique aux applications (comme DoH). C’est utile, mais pas nécessairement représentatif de « ce que fera l’app ».

4) Quelle est la différence entre vider le cache DNS et réinitialiser Winsock ?

Vider le cache DNS supprime des réponses nom→IP mises en cache. Réinitialiser Winsock répare la configuration de la couche socket et le catalogue des fournisseurs. Le reset Winsock s’applique à des symptômes réseau plus larges, pas à un seul enregistrement DNS obsolète.

5) Le fait que le service DNS Client soit désactivé peut-il causer des problèmes ?

Oui. Le désactiver peut casser le comportement de cache et les performances, et affecter la façon dont le système gère la résolution de noms. Sauf raison stricte et testée, gardez‑le activé.

6) Pourquoi les noms internes échouent quand je suis hors VPN ?

Parce que vos serveurs DNS actuels (routeur domestique, FAI, résolveur public) ne connaissent pas les zones internes. La correction est un split DNS correct et le routage via VPN, pas des vidages de cache répétés.

7) Comment savoir si le DNS over HTTPS est impliqué ?

Si les navigateurs résolvent différemment des outils OS, suspectez DoH. Vérifiez les paramètres « DNS sécurisé » du navigateur et vos politiques d’entreprise. Vous pouvez aussi comparer Resolve-DnsName et le comportement du navigateur.

8) Et si le DNS se résout, mais que les connexions échouent toujours ?

Alors ce n’est probablement pas du DNS. Ça peut être du routage, un pare‑feu, un proxy, une inspection TLS, ou le service lui‑même. Validez la connectivité vers l’IP et le port résolus et inspectez la configuration du proxy.

9) Devons‑nous abaisser les TTL pour que les changements DNS se propagent plus vite ?

Parfois oui — avant une migration planifiée, abaissez le TTL, puis remontez‑le après. Mais ne considérez pas un TTL bas comme une « propagation instantanée », et n’oubliez pas que le cache au niveau applicatif peut ignorer les TTL.

10) Modifier le fichier hosts est‑il une solution valable ?

Comme solution de contournement d’urgence pour une seule machine, parfois. Comme solution générale, non. Cela contourne le contrôle central, complique les incidents, et tend à survivre à la raison qui l’a motivé.

Conclusion : étapes suivantes qui tiennent réellement

Cessez de laisser ipconfig /flushdns être le mécanisme d’adaptation de votre équipe. C’est un outil, pas un remède. Le remède est de comprendre quel chemin de résolveur échoue et pourquoi.

Étapes pratiques :

Adoptez le playbook de diagnostic rapide. Utilisez‑le sur chaque ticket « DNS en panne » jusqu’à ce que cela devienne un automatisme.
Standardisez les preuves que vous collectez : ipconfig /all, Resolve-DnsName, et un nslookup name server direct.
Renforcez votre processus de changement DNS : exigez plan TTL et valeurs de rollback. Rendez‑le volontairement ennuyeux.
Auditez ensemble le split DNS et les politiques DoH. Si sécurité et réseau ne coordonnent pas, les utilisateurs deviendront vos cobayes d’intégration.
Quand vous videz des caches, documentez le résultat avant/après et l’hypothèse testée. Sinon vous n’appuyez que sur des boutons.