Panne DNS : diagnostiquez avant de changer les réglages

Votre application devient introuvable et quelqu’un propose de changer le DNS de tous les postes. Commencez par comparer les réponses : vous saurez quoi corriger sans transformer une panne locale en incident général.

Je demande d’abord le nom exact saisi par l’utilisateur. Pas le nom commercial du logiciel, ni une capture coupée au milieu du message. Il faut une adresse, un poste touché et une action qui échoue. Sans cela, chacun teste autre chose et annonce son propre diagnostic.

Relevez la configuration avant de toucher au poste

Choisissez un poste touché et, si possible, un poste fonctionnel sur le même réseau. Notez l’heure, le site, la présence du VPN et le nom complet demandé. Conservez aussi le message d’erreur. Une page introuvable, un refus de connexion et une erreur de certificat ne racontent pas la même panne.

Sur Windows, commencez par ces commandes de lecture :

ipconfig /all
ipconfig /displaydns

Relevez les serveurs DNS et le suffixe de connexion. La procédure Microsoft de diagnostic du client DNS détaille ces contrôles. Si le nom complet fonctionne mais que le nom court échoue, examinez le suffixe avant de modifier l’enregistrement du serveur.

Copiez les résultats dans le dossier d’incident à accès limité. Ils peuvent révéler des noms internes. Mon conseil : demandez cette collecte au support avant toute consigne de redémarrage. Vous garderez une situation de départ comparable après correction.

Interrogez chaque serveur avec la même question

Un résolveur reçoit la question du poste et cherche la réponse. Testez séparément ceux prévus pour le réseau concerné. Ne supposez pas que les adresses présentes dans la configuration donnent toutes le même résultat.

Exemple fictif à adapter avec votre nom complet et l’adresse d’un serveur DNS autorisé :

Resolve-DnsName -Name "erp.example.com." -Type A -Server "192.0.2.53" -DnsOnly -NoHostsFile

Les valeurs de cet exemple ne désignent pas votre infrastructure. Remplacez-les avant exécution. Rejouez la requête contre chaque serveur configuré et conservez la réponse entière, y compris l’erreur éventuelle.

La documentation de Resolve-DnsName décrit les options : -Server choisit le serveur, -DnsOnly limite la requête au DNS et -NoHostsFile ignore le fichier hosts. A vise une adresse IPv4 ; examinez aussi AAAA si le service utilise IPv6.

Demandez au responsable applicatif quelle réponse est attendue depuis ce réseau. Des réponses différentes peuvent être voulues selon le site. Une adresse qui varie n’est donc pas, à elle seule, la preuve d’un défaut.

Faites préciser l’erreur avant d’accuser le réseau

Demandez au technicien de classer son observation. Le mot DNS ne suffit pas à attribuer une intervention au bon collègue.

Ce tableau oriente le diagnostic ; il ne remplace pas les preuves. NXDOMAIN indique une réponse de nom inexistant, pas un câble débranché. SERVFAIL signale un échec de traitement : demander le détail côté serveur est plus utile que recréer immédiatement l’enregistrement.

Une réponse DNS correcte ne prouve pas qu’une commande peut être saisie dans l’ERP. Faites tester l’action métier après la résolution. Si elle échoue encore, transmettez le résultat DNS au responsable suivant et gardez le même dossier d’incident.

Ne remplacez pas le DNS interne par un résolveur public

Faire fonctionner un site Internet avec un DNS public ne valide pas les accès internes. Les postes peuvent avoir besoin de noms privés que ce serveur ne connaît pas. Le dépannage doit conserver ce besoin, même si le navigateur semble repartir.

Microsoft recommande aux machines membres d’un domaine d’utiliser des serveurs capables de résoudre sa zone Active Directory. Ajouter le DNS du fournisseur Internet dans la liste n’est pas une assurance contre les pannes du DNS interne.

Demandez plutôt : quel serveur interne répond correctement, et depuis quels réseaux ? Si une modification temporaire est nécessaire, limitez-la à un poste pilote. Notez l’ancienne configuration, le responsable du changement et la condition de retour.

Évitez aussi de distribuer un fichier hosts corrigé à tout le parc. Vous créeriez des exceptions locales à retrouver lors du prochain changement d’adresse. Le coût caché est là : chaque dépannage oublié devient une configuration supplémentaire à maintenir.

Videz le cache seulement après avoir conservé la preuve

Le DNS peut mémoriser une absence de réponse utile, notamment un nom inexistant. La RFC 2308 décrit cette mise en cache négative. Créer ensuite l’enregistrement ne fait pas disparaître instantanément les réponses négatives déjà conservées.

Comparez le cache du poste avec une interrogation directe. Microsoft précise que nslookup n’utilise pas le cache DNS du client. Sur le poste pilote, interrogez le même nom et le même serveur :

nslookup erp.example.com. 192.0.2.53

Si le serveur répond correctement et que le cache local contient encore une réponse erronée, conservez-la puis envisagez ipconfig /flushdns. Rejouez l’accès métier. Une amélioration après purge reste un résultat à expliquer, pas une raison de programmer des purges partout.

Astuce : gardez dans votre fiche d’intervention une ligne avant et une ligne après, avec nom demandé, serveur interrogé, réponse et heure. Ce modèle suffit pour éviter une conversation fondée sur les souvenirs. Une purge du poste ne vide pas le cache du résolveur partagé.

Préparez cette semaine un diagnostic utilisable par le support

Choisissez une application indispensable et préparez une fiche courte. Le support doit pouvoir collecter les faits sans attendre l’administrateur habituel.

• Notez le nom complet utilisé et les réponses attendues selon le réseau.
• Listez les résolveurs autorisés, leur responsable et le contact de secours.
• Testez les commandes de lecture sur un poste représentatif.
• Prévoyez où conserver les résultats avant et après intervention.
• Inscrivez les changements exigeant une validation et leur retour arrière.
• Faites confirmer la reprise par une opération métier précise.

Pendant l’investigation, appliquez votre circuit de communication d’incident vers les métiers. Annoncez le périmètre touché et le prochain point, même si la cause reste inconnue.

Terminez la fiche par une question concrète : qui corrige un enregistrement erroné lorsque le prestataire habituel ne répond pas ? Vérifiez le contact et les accès cette semaine. Une adresse de support dans un contrat ne garantit pas qu’un intervenant pourra agir pendant la panne.