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 pas un logiciel malveillant, pas un module complémentaire, et ce n'est pas quelque chose que tu as installé — il est livré avec le système d'exploitation et démarre automatiquement.

Il remplit deux fonctions distinctes, et les confondre est la principale source de confusion à son sujet. La première est la découverte de services et DNS multicast — c'est l'Apple Bonjour, la technologie qui permet à ton Mac de trouver des imprimantes, des récepteurs AirPlay, des Chromecasts, des disques partagés, des accessoires HomeKit et d'autres Macs sur ton réseau local sans configuration manuelle. Ce trafic est envoyé à une adresse multicast sur le port UDP 5353, qui est le port standard pour mDNS.

La deuxième fonction est celle que la plupart des explications omettent : sur macOS, mDNSResponder est aussi le résolveur DNS global du système. Lorsqu'une application sur ton Mac doit convertir un nom d'hôte en adresse IP, la requête est généralement traitée par mDNSResponder pour le compte de cette application plutôt que par l'application elle-même.

Les deux fonctions s'exécutent dans le même processus. Donc, lorsque tu vois mDNSResponder occupé, tu regardes le résultat combiné de la découverte sur le réseau local et de chaque recherche de nom effectuée par ton 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 ton Mac semblent provenir de mDNSResponder plutôt que de l'application qui voulait réellement l'adresse.

Ton navigateur chargeant une page avec une douzaine de ressources tierces, ton 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 tes 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 daemon.

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, tu devrais voir exactement une instance en cours d’exécution.

Tu n’as pas besoin de le croire sur parole. Dans Activity Monitor, sélectionne le processus et ouvre 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 ton 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 te 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 ton réseau ou sur ton 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 ton Mac effectuant des recherches en boucle.

Traite cela dans l’ordre d’effort. D’abord, désactive puis réactive le Wi-Fi, ou déconnecte-toi brièvement du réseau — cela efface un nombre surprenant d’états transitoires. Si cela ne suffit pas, redémarre ; 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 ton Mac : essaie un autre réseau pour confirmer, puis regarde ce qui s’y fait de la publicité. Si tu as récemment installé un client VPN, un outil de filtrage DNS, ou autre extension réseau, le désactiver temporairement te dira rapidement si c’est lui le déclencheur. Si le problème te suit d’un réseau à l’autre et survit à un redémarrage, suspecte une application spécifique et commence 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 bloque 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 tu as 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 ton objectif réel est de réduire le trafic local, cible plutôt les fonctionnalités plutôt 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 tu n’utilises pas réduit ce que ton 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 tu surveilles les connexions au niveau du système, une grande partie de l’activité DNS intéressante est étiquetée mDNSResponder, et tu ne peux pas dire simplement d’après cette étiquette si le domaine a été demandé par ton 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é, tu as une image par application de ce à quoi ton Mac parle réellement.

De là, la réponse est ciblée. Le pare-feu par application de NetMute te permet de bloquer une application spécifique en un clic, ou d’appliquer une règle temporaire à expiration automatique lorsque tu veux 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 — tu laisses le résolveur tranquille et agis sur l’application qui a généré les requêtes, ce qui est la seule solution qui ne casse pas le reste de ton Mac.