En 25 ans à dépanner des infrastructures de PME bretonnes, j’ai vu revenir le même scénario une bonne dizaine de fois : un client change d’hébergeur, et personne ne comprend pourquoi le domain name server protocol ne se comporte pas comme prévu ensuite. J’arrive alors avec mon carnet de commandes habituel pour démêler ce qui relève de la propagation normale et ce qui relève d’une vraie erreur.
Un ticket d’apparence anodine
Le mail est arrivé un lundi matin : « Nos boîtes mail ne reçoivent plus rien depuis vendredi, et le site tombe parfois en erreur. » Chez cette PME de vingt-deux salariés dans la logistique, rien de spectaculaire au départ — juste un domain name server protocol mal configuré après un changement d’hébergeur, et une propagation qui n’allait pas se passer comme prévu. Ce genre d’incident revient régulièrement sur le terrain, et il illustre mieux qu’un cours théorique comment fonctionne réellement la résolution DNS quand elle est mise sous tension.
Le contexte : l’entreprise venait de migrer son site vitrine et sa messagerie professionnelle vers un nouvel hébergeur. Le prestataire précédent avait fourni les nouveaux enregistrements DNS à mettre à jour chez le registrar, et l’équipe interne — sans compétence réseau dédiée — avait fait le changement elle-même un vendredi après-midi. Trois jours ouvrés plus tard, plus rien ne fonctionnait correctement pour une partie des utilisateurs, alors que d’autres ne voyaient aucun problème.
Comprendre le domain name server protocol avant de diagnostiquer
Avant d’aller plus loin, il faut rappeler ce qu’est réellement le protocole de résolution de noms de domaine. Le DNS traduit un nom lisible par un humain (comme exemple.fr) en une adresse IP compréhensible par les machines. Ce système repose sur une hiérarchie : serveurs racine, serveurs de la zone TLD (.fr, .com…), puis serveurs faisant autorité pour le domaine lui-même. Quand un enregistrement change — un enregistrement A, un MX pour la messagerie, ou un CNAME — cette information doit se propager à travers un réseau de resolvers récursifs disséminés chez les FAI, les opérateurs mobiles et les services DNS publics.
Ce protocole repose largement sur UDP (port 53), avec un repli sur TCP pour les réponses volumineuses ou les transferts de zone. Chaque enregistrement porte une valeur de TTL (Time To Live), exprimée en secondes, qui indique combien de temps un resolver est autorisé à conserver la réponse en cache avant de la revalider auprès du serveur faisant autorité. C’est précisément ce paramètre, souvent ignoré, qui explique une grande partie des incidents comme celui rencontré chez ce client.
Dans ce dossier, l’ancien hébergeur avait configuré un TTL de 86400 secondes (24 heures) sur les enregistrements MX et A. Le changement de DNS effectué le vendredi n’a donc pas pu se propager instantanément : de nombreux resolvers à travers le pays continuaient de servir l’ancienne réponse, mise en cache, jusqu’à expiration de leur propre TTL local. Certains utilisateurs, dont le resolver avait interrogé la zone juste avant le changement, sont restés bloqués sur l’ancienne configuration pendant près de deux jours supplémentaires.
Premières étapes de diagnostic sur site
Sur place, la première chose à faire n’était pas de toucher à la configuration, mais de vérifier objectivement ce que voyait réellement le monde extérieur. Le réflexe du client — « ça ne marche toujours pas, il faut tout reconfigurer » — est l’erreur classique : on modifie une configuration qui est en réalité correcte, uniquement parce que le cache DNS ancien n’a pas encore expiré quelque part.
La commande dig a permis de comparer ce que renvoyaient différents serveurs :
dig MX exemple.fr— pour vérifier les enregistrements de messagerie actuellement annoncés par le serveur faisant autoritédig MX exemple.fr @8.8.8.8— pour interroger directement le resolver public de Google et comparer avec la réponse localedig +trace exemple.fr— pour suivre toute la chaîne de résolution, du serveur racine jusqu’au serveur faisant autorité, et repérer une éventuelle rupture dans la délégation
Le résultat a confirmé l’hypothèse : le serveur faisant autorité renvoyait bien la nouvelle configuration, correcte, mais certains resolvers publics interrogés depuis différents points du réseau renvoyaient encore l’ancienne réponse, cohérente avec un TTL de 24h qui n’était pas encore arrivé à expiration au moment du changement.
Un second point, plus inquiétant, est apparu en croisant les résultats de nslookup depuis plusieurs postes du réseau interne de l’entreprise. Certains postes utilisaient un serveur DNS interne, hébergé sur un ancien serveur Windows resté allumé « au cas où », que personne n’utilisait officiellement mais que le DHCP continuait de distribuer à une poignée de machines mal reconfigurées. Ce serveur DNS interne avait lui-même mis en cache l’ancienne résolution et la resservait indéfiniment à ces quelques postes, indépendamment de toute propagation externe — ce qui expliquait pourquoi certains employés voyaient le problème disparaître, et d’autres non, sans lien apparent avec le TTL des enregistrements publics.
Deux causes distinctes, un seul symptôme
C’est là le point le plus instructif de ce cas : le symptôme rapporté par le client (« ça ne marche pas ») recouvrait en réalité deux causes indépendantes.
La première était une propagation DNS lente, tout à fait normale compte tenu du TTL configuré, et qui allait se résorber d’elle-même en moins de 24 heures sans aucune intervention. Aucune action corrective n’était nécessaire sur ce point — seulement de la pédagogie auprès du client pour expliquer pourquoi patienter était la bonne réponse, et non reconfigurer une seconde fois dans la précipitation.
La seconde était plus structurelle : ce serveur DNS interne fantôme, jamais désinstallé après une précédente migration d’infrastructure trois ans auparavant, continuait de répondre aux requêtes DHCP et de distribuer une configuration DNS obsolète à certains postes. Ce type de résidu technique est fréquent dans les PME qui changent de prestataire sans documentation de passation complète : personne ne sait plus exactement ce que fait chaque machine sur le réseau, et un serveur oublié continue de rendre un service qu’on croyait avoir supprimé.
La solution mise en œuvre
Deux actions ont été menées en parallèle. D’abord, la baisse volontaire du TTL sur les enregistrements DNS critiques, ramené à 3600 secondes (1h) le temps de fiabiliser la nouvelle infrastructure, avant de le remonter progressivement à une valeur plus stable une fois la migration validée sur plusieurs jours. C’est une pratique recommandée avant tout changement DNS planifié : abaisser le TTL en amont, plusieurs jours avant le changement, pour que la fenêtre de propagation soit la plus courte possible le jour J.
Ensuite, et c’était le point le plus délicat, il a fallu localiser et arrêter ce serveur DNS interne orphelin. L’opération n’a pas été simple : ce serveur hébergeait également, sans que personne ne s’en souvienne clairement, une ancienne base de résolution de noms utilisée par un logiciel métier tournant encore sur deux postes de l’atelier. Éteindre le serveur du jour au lendemain aurait cassé ce logiciel sans préavis.
Un compromis, pas une victoire nette
Faute de budget immédiat pour migrer proprement ce logiciel métier vers une résolution DNS standard, la décision prise avec le client n’a pas été la solution idéale. Le serveur DNS interne a été conservé, mais reconfiguré pour ne plus faire de résolution récursive externe et pour ne plus être distribué par le DHCP à aucun poste sauf les deux machines de l’atelier qui en avaient encore besoin. Une règle de pare-feu a été ajoutée pour limiter son exposition. Ce n’est pas une solution propre — c’est un pansement qui documente une dette technique clairement identifiée, avec une recommandation écrite de migrer le logiciel métier dans les douze mois.
Ce choix illustre une réalité fréquente sur le terrain : la solution techniquement correcte (supprimer purement et simplement l’ancien serveur) se heurte parfois à des dépendances héritées qu’on découvre seulement en creusant, et il faut alors arbitrer entre le risque immédiat de casser un outil de production et le risque à moyen terme de laisser perdurer une configuration bancale.
Ce qu’il faut retenir de ce protocole DNS en situation réelle
Ce cas rappelle plusieurs points essentiels sur le fonctionnement du protocole DNS en environnement de production :
- Le TTL n’est pas un détail technique secondaire : il détermine directement la durée d’une panne perçue après tout changement, et doit être anticipé avant toute migration.
digetnslookuprestent les outils de premier niveau indispensables pour distinguer un problème de propagation normal d’un dysfonctionnement réel de configuration.- Un symptôme unique peut masquer plusieurs causes indépendantes ; diagnostiquer trop vite, sans isoler chaque source de requête, mène à des corrections inutiles voire dangereuses.
- L’infrastructure réseau des PME accumule souvent des éléments hérités, non documentés, qui continuent à interagir avec le DNS sans que personne n’en ait une vue d’ensemble.
Six mois plus tard, le serveur interne fantôme tourne toujours, sous surveillance, en attendant l’arbitrage budgétaire pour migrer le dernier logiciel qui en dépend. Ce n’est pas la fin d’histoire qu’on aimerait raconter, mais c’est fidèle à ce que rencontre régulièrement un technicien indépendant sur le terrain : des systèmes vivants, imparfaits, où chaque intervention doit composer avec l’existant plutôt qu’avec une infrastructure idéale sur le papier.
Ça fait écho à un autre billet, l'activation du client Telnet, et un autre point utile est couvert dans mes retours webmarketing.
Pour approfondir, consultez les ressources de l’AFNIC ainsi que ses explications sur le DNS.