MacのmDNSResponderとは何か？Bonjour、DNS、そして高いネットワーク使用量の解説

mDNSResponderは、macOSに組み込まれたシステムデーモンで、Appleによってコード署名されています。これはマルウェアでも、アドオンでも、あなたがインストールしたものでもありません — オペレーティングシステムとともに出荷され、自動的に起動します。

それは二つの異なる役割を果たしており、それらを混同することが多くの混乱の原因です。最初はマルチキャストDNSとサービス検出 — これはAppleのBonjourで、あなたのMacがプリンター、AirPlayレシーバー、Chromecast、共有ドライブ、HomeKitアクセサリー、その他のMacを手動設定なしで見つけることを可能にする技術です。このトラフィックはUDPポート5353のマルチキャストアドレスに送信され、これが標準のmDNSポートです。

二つ目の役割は、多くの説明が省略しがちなものです：macOSでは、mDNSResponderはシステム全体のDNSリゾルバーでもあります。あなたのMac上のどのアプリケーションもホスト名をIPアドレスに変換する必要があるとき、そのリクエストは通常、そのアプリ自身ではなく、mDNSResponderによって処理されます。

両方の役割は同じプロセス内で動作しています。だから、mDNSResponderが忙しいときは、ローカルネットワークの検出とあなたのMacが行うすべての名前解決の結果を見ていることになります。

これが人々を驚かせる部分であり、平凡な説明があります。mDNSResponderは他のプロセスの代わりに名前を解決しているため、実質的にあなたのMacのすべてのDNSルックアップは、実際にアドレスを必要としたアプリではなく、mDNSResponderから発信されているように見えます。

あなたのブラウザが複数のサードパーティリソースを含むページを読み込むとき、メールクライアントがアカウントを確認するとき、バックグラウンドのアップデーター、チャットアプリが再接続するとき — これらはすべて、DNSビューに自分自身として表示されません。mDNSResponderが設定されたDNSサーバーと通信しているように見えます。外から見ると、一つのプロセスが膨大で絶えず変化するドメインのリストに関心を持っているように見えます。

この単一の事実が、多くの疑念のほとんどに答えます。mDNSResponderが多くのホストに連絡しているのは、何か怪しいことをしているからではありません。 それはプロキシです。その活動は、ルックアップを求めたソフトウェアに属します。mDNSResponderはそれを実行するコンポーネントに過ぎません。

また、なぜこのプロセスがめったに静かにならないのかも説明します。現代のMacには、ソフトウェアの定期的なチェック、同期サービス、プッシュ通知、アップデートの確認、インストールしたアプリからのテレメトリーなどの、一定のバックグラウンドのハム音があります。これらすべてが名前解決を必要とし、そのすべてが同じデーモンを通じて行われています。

mDNSResponderはmacOSの正当な一部です。悪意のあるものの偽装であるという有意義な履歴はなく、正常に動作しているMacでは、正確に1つのインスタンスが実行されているのを見るはずです。

それを信じる必要はありません。Activity Monitorでプロセスを選択し、インスペクタを開いて詳細を確認してください。実行ファイルのパスも含まれます。Appleのシステムデーモンは保護されたシステムディレクトリ内にあり、ホームフォルダ、Downloads、Applicationsにはありません。mDNSResponderという名前を使っていても、異常な場所から実行されている場合は調査の価値があります — 名前自体は何かの証拠ではありません。

より確実な確認はコード署名です。macOSにはcodesignツールが付属しており、実行中のバイナリのパスに対して検証を行うと、署名の権威がわかります。Apple自身のシステムコンポーネントはAppleによって署名されています。最近のmacOSバージョンでは、システムファイルは封印された読み取り専用のシステムボリュームにあり、実際のバイナリを改ざんするのは以前よりもはるかに難しくなっています。

もう一つの正当性チェックは、mDNSResponderの高いアクティビティは正常ですが、数時間にわたる持続的な高CPU使用率は異常です。これは通常、ネットワークやMac上の何か他の問題の兆候です。次のセクションで詳しく説明します。

mDNSResponderが本当に誤動作している場合、その原因はほとんど常に外部にあります。一般的な原因は次の通りです：重いBonjourチャットを伴うローカルネットワーク、積極的に自己を広告するプリンターやNAS、システムリゾルバと競合するVPNやサードパーティのDNSソフトウェア、ホテルやカフェのネットワークでのキャプティブポータルのプロービング、またはMac上のアプリがループ内でルックアップを発行している場合です。

まずは努力の順に対処してください。最初にWi-Fiをオフにして再度オン、またはネットワークから一時的に切断します — これだけで多くの一時的な状態が解消されます。それでも解決しない場合は再起動してください。再起動はデーモンとそれに供給されるすべてをリセットします。特定のネットワークだけで問題が起きる場合、そのネットワークが変数です。別のネットワークを試して確認し、そこに何が広告されているかを調べてください。VPNクライアントやDNSフィルタリングツール、またはネットワーク拡張機能をインストールした場合、一時的に無効にすると、トリガーが何かをすぐに確認できます。ネットワークをまたいで問題が続き、再起動後も解決しない場合は、特定のアプリケーションを疑い、最近インストールまたは更新したアプリを一つずつ終了してください。

やってはいけないのは、それをブロックすることです。絶対にファイアウォールでmDNSResponderをブロックしないでください。 それはシステム全体のリゾルバであり、ブロックするとMac全体の名前解決が停止します — ブラウザ、メール、App Store、ソフトウェアアップデート、そしてネットワークに関わる他のすべてが失敗します。混乱を招くエラーが出ることもありますが、それはファイアウォールルールに起因しません。これは、ブロックによってダメージがトラフィックを止める以上に大きくなる数少ないプロセスの一つです。

もしローカルネットワークのチャットを減らしたいだけなら、リゾルバではなく機能をターゲットにしてください。AirPlayレシーバー、プリンター共有、ファイル共有、その他Bonjourに依存するサービスをオフにすると、Macが広告し、リッスンしている内容を減らせます。これによりDNSは壊れません。これが正しい操作です。

中央集権的な解決の結果は、帰属問題です。システムレベルで接続を監視している場合、興味深いDNS活動の大部分はmDNSResponderとラベル付けされており、そのラベルだけでは、そのドメインがブラウザ、バックグラウンドのアップデーター、または静かにホームに電話しているアプリによって要求されたのかを判断できません。

それに答えるには、接続をプロセスごとに監視し、ルックアップを行ったデーモンではなく、活動を発信元のアプリにマッピングするツールが必要です。それがNetMuteが埋めるべきギャップです：リアルタイムのトラフィックをアプリごと、プロセスごとに表示し、アプリごとにドメインレベルのログを保持します — どのドメインにアプリケーションが接触し、いつ、どれだけのデータが移動したかを示します。忙しいデーモンの代わりに、Macが実際に通信している内容のアプリごとの画像を得ることができます。

そこから応答はターゲットを絞ったものになります。NetMuteのアプリごとのファイアウォールは、ワンクリックで特定のアプリをブロックしたり、一時的なルールを自己期限切れに設定して一時的に何かを沈黙させたりできます。ネットワークプロファイルは、ホーム、オフィス、信頼できないネットワーク間でルールを異ならせることができ、Tracker Shieldは1,100以上の既知のトラッカー・ドメインのリストをカバーします。これらはすべて、mDNSResponder自体に干渉することなく行われます — リゾルバーを放置し、リクエストを生成したアプリに対して行動します。これが、あなたのMacの他の部分を壊さずに済む唯一の修正です。