Qu'est-ce que mDNSResponder sur Mac ? Bonjour, DNS et utilisation élevée du réseau expliqués

mDNSResponder est un daemon système intégré à macOS et signé par Apple. Ce n’est ni un malware, ni un ajout, ni quelque chose que vous avez installé. Il est fourni avec le système d’exploitation et démarre automatiquement.

Il remplit deux tâches distinctes, et les confondre est la source de la plupart des incompréhensions à son sujet. La première est la découverte de services et DNS multicast : c’est Bonjour d’Apple, la technologie qui permet à votre Mac de trouver des imprimantes, des récepteurs AirPlay, des Chromecasts, des disques partagés, des accessoires HomeKit et d’autres Macs sur votre réseau local sans aucune configuration manuelle. Ce trafic est envoyé vers une adresse multicast sur le port UDP 5353, qui est le port standard de mDNS.

La seconde tâche est celle que la plupart des explications sautent : sur macOS, mDNSResponder est aussi le résolveur DNS global du système. Lorsqu’une app sur votre Mac doit convertir un nom d’hôte en adresse IP, la requête est généralement traitée par mDNSResponder pour son compte plutôt que par l’app elle-même.

Les deux tâches s’exécutent dans le même processus. Donc, lorsque vous voyez mDNSResponder occupé, vous voyez le résultat combiné de la découverte sur le réseau local et de chaque recherche de nom effectuée par votre Mac.

C'est la partie qui alarme les gens, et elle a une explication banale. Parce que mDNSResponder résout les noms pour le compte d'autres processus, presque toutes les recherches DNS de votre Mac semblent provenir de mDNSResponder plutôt que de l'application qui voulait réellement l'adresse.

Votre navigateur chargeant une page avec une douzaine de ressources tierces, votre client mail vérifiant ses comptes, une mise à jour en arrière-plan, une application de chat se reconnectant : aucun de ces éléments n'apparaît comme tel dans une vue DNS. Ils apparaissent comme mDNSResponder communiquant avec vos serveurs DNS configurés. De l'extérieur, un processus semble s'intéresser à une liste énorme et en constante évolution de domaines.

Ce simple fait répond à la plupart des soupçons. Voir mDNSResponder contacter de nombreux hôtes ne signifie pas que mDNSResponder fait quelque chose de suspect. C'est un proxy. L'activité appartient au logiciel qui a demandé la recherche, mDNSResponder n'est que le composant qui l'exécute.

Cela explique aussi pourquoi le processus est rarement silencieux. Un Mac moderne a un bourdonnement de fond constant de logiciels qui vérifient, services de synchronisation, notifications push, vérifications de mise à jour, télémétrie des applications installées. Chacun de ces éléments nécessite une résolution de nom en premier lieu, et tout passe par le même démon.

mDNSResponder est une partie légitime de macOS. Il n’y a pas d’historique significatif indiquant qu’il soit un déguisement pour quelque chose de malveillant, et sur un Mac fonctionnant normalement, vous devriez voir exactement une instance en cours d’exécution.

Vous n’avez pas besoin de le croire sur parole. Dans Activity Monitor, sélectionnez le processus et ouvrez l’inspecteur pour voir ses détails, y compris le chemin vers l’exécutable à partir duquel il a été lancé. Les démons système d’Apple vivent dans des répertoires système protégés, pas dans votre dossier personnel, Downloads ou Applications. Un processus utilisant le nom mDNSResponder mais s’exécutant depuis un emplacement inhabituel serait la chose à examiner, le nom lui-même n’est pas une preuve de quoi que ce soit.

La vérification la plus fiable est la signature du code. macOS est livré avec l’outil codesign, et effectuer une vérification du chemin du binaire en cours d’exécution vous montrera l’autorité de signature. Les composants système d’Apple sont signés par Apple. Sur les versions récentes de macOS, les fichiers système résident également sur un volume système scellé et en lecture seule, ce qui rend la manipulation du vrai binaire beaucoup plus difficile qu’auparavant.

Une autre vérification de bon sens : une activité élevée de mDNSResponder est normale, mais une utilisation soutenue et élevée du CPU sur plusieurs heures ne l’est pas. Cela indique généralement quelque chose d’autre sur votre réseau ou sur votre Mac, ce que la section suivante explique.

Lorsque mDNSResponder se comporte vraiment mal, la cause est presque toujours externe. Les suspects habituels : un réseau local occupé avec beaucoup de trafic Bonjour, une imprimante ou un NAS qui se fait de la publicité de façon agressive, un VPN ou un logiciel DNS tiers en conflit avec le résolveur système, une vérification de portail captif sur un réseau d’hôtel ou de café, ou une seule application sur votre Mac effectuant des recherches en boucle.

Traitez cela dans l’ordre d’effort. D’abord, désactivez puis réactivez le Wi-Fi, ou déconnectez-vous brièvement du réseau, cela efface un nombre surprenant d’états transitoires. Si cela ne suffit pas, redémarrez, un redémarrage réinitialise le démon ainsi que tout ce qui le nourrit. Si le problème ne se produit que sur un seul réseau, c’est le réseau qui est en cause, pas votre Mac : essayez un autre réseau pour confirmer, puis regardez ce qui s’y fait de la publicité. Si vous avez récemment installé un client VPN, un outil de filtrage DNS, ou autre extension réseau, le désactiver temporairement vous dira rapidement si c’est lui le déclencheur. Si le problème vous suit d’un réseau à l’autre et survit à un redémarrage, suspectez une application spécifique et commencez par quitter les applications récemment installées ou récemment mises à jour, une par une.

Ce qu’il ne faut pas faire, c’est le bloquer. Ne bloquez jamais mDNSResponder dans un pare-feu. Parce qu’il est le résolveur système, le bloquer empêche la résolution de noms pour tout le Mac, navigateurs, Mail, l'App Store, mises à jour logicielles, et tout ce qui touche au réseau échouera, généralement avec des erreurs confuses qui ne pointent pas vers la règle du pare-feu que vous avez ajoutée. C’est l’un des rares processus où le blocage cause beaucoup plus de dégâts que le trafic qu’il était censé arrêter.

Si votre objectif réel est de réduire le trafic local, ciblez plutôt les fonctionnalités que le résolveur. Désactiver le récepteur AirPlay, le partage d’imprimantes, le partage de fichiers, et d’autres services dépendants de Bonjour que vous n’utilisez pas réduit ce que votre Mac annonce et écoute, sans casser DNS. C’est le levier correct.

La conséquence d’une résolution centralisée est un problème d’attribution. Si vous surveillez les connexions au niveau du système, une grande partie de l’activité DNS intéressante est étiquetée mDNSResponder, et vous ne pouvez pas dire simplement d’après cette étiquette si le domaine a été demandé par votre navigateur, une mise à jour en arrière-plan, ou une application qui téléphone discrètement à la maison.

Pour répondre à cela, il faut un outil qui surveille les connexions par processus et relie l’activité à l’application d’origine plutôt qu’au démon qui a effectué la recherche. C’est précisément ce que NetMute est conçu pour faire : il affiche le trafic en temps réel par application et par processus, et conserve des journaux au niveau des domaines par application : quels domaines une application a contactés, quand, et combien de données ont été transférées. Au lieu d’un seul démon occupé, vous avez une image par application de ce à quoi votre Mac parle réellement.

De là, la réponse est ciblée. Le pare-feu par application de NetMute vous permet de bloquer une application spécifique en un clic, ou d’appliquer une règle temporaire à expiration automatique lorsque vous voulez simplement faire silence pendant un moment. Les profils réseau permettent de différencier les règles entre maison, bureau, et réseaux non fiables, et Tracker Shield couvre une liste de plus de 1 100 domaines de trackers connus. Rien de tout cela n’interfère avec mDNSResponder lui-même, vous laissez le résolveur tranquille et agissez sur l’application qui a généré les requêtes, ce qui est la seule solution qui ne casse pas le reste de votre Mac.