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

mDNSResponderは、macOSに組み込まれたシステムデーモンで、Appleのコード署名付きです。マルウェアでも、追加ソフトでも、あなたが入れたものでもありません。OSに付属していて、自動で起動します。

これには2つの明確に異なる仕事があり、それを混同することが、mDNSResponderをめぐる混乱の大半です。1つ目はマルチキャストDNSとサービス検出です。これはAppleのBonjourで、Macがプリンター、AirPlayレシーバー、Chromecast、共有ドライブ、HomeKitアクセサリ、ほかのMacを、手動設定なしでローカルネットワーク上から見つけられるようにする技術です。この通信はUDPポート5353のマルチキャストアドレスに送られ、これが標準のmDNSポートです。

2つ目は、多くの説明が省いてしまう部分です。macOSでは、mDNSResponderはシステム全体のDNSリゾルバーでもあります。Mac上のどのアプリケーションでもホスト名をIPアドレスに変換する必要があるとき、その要求は通常、アプリ自身ではなくmDNSResponderが代わりに処理します。

この2つの仕事は、同じプロセスの中で動いています。なので、mDNSResponderが忙しそうに見えるとき、実際にはローカルネットワークの検出と、Macが行うすべての名前解決が合わさった結果を見ているのです。

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

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

この1点だけで、疑いの大半には答えが出ます。mDNSResponderが多くのホストに接続していても、それだけで怪しい動きをしていることにはなりません。 これはプロキシです。実際の動きは、ルックアップを要求したソフトウェアのものです。mDNSResponderは、それを実行しているだけの部品です。

また、このプロセスがめったに静かにならない理由も説明できます。今のMacは、同期サービス、プッシュ通知、アップデート確認、入れてあるアプリからのテレメトリーなど、バックグラウンドで常に何かが動いています。これらはすべて最初に名前解決が必要で、全部が同じデーモンに流れ込みます。

mDNSResponderはmacOSの正当な一部です。これを悪意ある何かの偽装だとみなすだけの根拠はなく、通常どおり動いているMacなら、実行中のインスタンスはちょうど1つであるはずです。

それを信じる必要はありません。アクティビティモニタでプロセスを選び、インスペクタを開けば、起動元の実行ファイルのパスを含む詳細が見られます。Appleのシステムデーモンは保護されたシステムディレクトリにあり、ホームフォルダ、Downloads、Applicationsにはありません。mDNSResponderという名前でも、異常な場所から動いているなら調べる価値があります。名前だけでは何も証明できません。

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

もう1つの健全性チェックです。mDNSResponderの高いアクティビティは普通ですが、CPU使用率が何時間も高止まりするのは普通ではありません。たいていは、ネットワークかMac上の別の何かが原因です。次のセクションで説明します。

mDNSResponderが本当におかしな動きをする場合、原因はほとんどいつもその外側にあります。よくあるのは、Bonjourの通信が多い混雑したローカルネットワーク、積極的に自分を広告するプリンターやNAS、システムのリゾルバと競合するVPNやサードパーティのDNSソフトウェア、ホテルやカフェのネットワークでのキャプティブポータルの検出、あるいはMac上の単一のアプリがルックアップをひたすら繰り返しているケースです。

対処は手間の少ない順に進めます。まずWi-Fiをオフにしてからオンにするか、少しだけネットワークを切断します。これだけで一時的な状態が驚くほど解消されます。それでもだめなら再起動してください。再起動すると、デーモンと、それに入力しているものすべてがリセットされます。特定のネットワークだけで起きるなら、変数はそのネットワークです。別のネットワークで確認し、そこで何が広告されているかを見てください。最近VPNクライアントやDNSフィルタリングツール、あるいはネットワーク拡張を入れたなら、一時的に無効化すれば、それが引き金かどうかすぐ分かります。ネットワークをまたいで問題が続き、再起動でも直らないなら、特定のアプリを疑ってください。最近インストールした、または最近更新したアプリを1つずつ終了していきます。

やってはいけないのは、これをブロックすることです。mDNSResponderをファイアウォールでブロックしないでください。 これはシステム全体のリゾルバなので、ブロックするとMac全体の名前解決が止まります。ブラウザ、メール、App Store、ソフトウェアアップデート、そしてネットワークに触れるほぼすべてが失敗します。しかも、原因がそのファイアウォールルールだと分かりにくいエラーが出がちです。止めたい通信より、ブロックによる被害のほうがはるかに大きくなる、数少ないプロセスの1つです。

本当に減らしたいのがローカルネットワークの雑音なら、リゾルバではなく機能を止めてください。AirPlayレシーバ、プリンタ共有、ファイル共有、ほかのBonjour依存サービスをオフにすると、Macが広告したり受け付けたりする内容を減らせます。DNSは壊れません。これが正しいやり方です。

集中型の名前解決には、帰属の問題がつきものです。システムレベルで接続を見ていると、面白いDNSアクティビティの大半はmDNSResponderというラベルになります。そしてそのラベルだけでは、ドメインを要求したのがブラウザなのか、バックグラウンドのアップデーターなのか、それとも静かに外部へ通信しているアプリなのかは分かりません。

それに答えるには、接続をプロセスごとに見て、活動をルックアップを行ったデーモンではなく発信元のアプリに結び付けるツールが必要です。そこを埋めるために作られたのがNetMuteです。アプリごと、プロセスごとのリアルタイム通信を表示し、アプリごとのドメインログも保持します。どのドメインに、いつ、どれだけのデータで接触したかが分かります。1つの忙しいデーモンを見る代わりに、Macが実際に何と通信しているのかをアプリ単位で把握できます。

そこから先の対応は的確です。NetMuteのアプリ別ファイアウォールなら、特定のアプリをワンクリックでブロックできますし、しばらく黙らせたいだけなら自動期限切れの一時ルールも使えます。ネットワークプロファイルで、自宅、職場、信頼できないネットワークごとにルールを変えられますし、Tracker Shieldは1,100以上の既知のトラッカードメインをカバーします。どれもmDNSResponder自体には手を出しません。リゾルバはそのままにして、リクエストを出したアプリに対処します。Macの他の部分を壊さない、これだけが正しい修正です。