What is mDNSResponder on Mac, and why is it busy?

What mDNSResponder does

The primary source is the manual page supplied with macOS: man mDNSResponder. It describes both multicast DNS for local-network discovery and the system-wide unicast DNS resolver. It also says apps ask the daemon to perform queries and that it keeps a cache of replies.

DNS translates a name into information an app can use to connect. Bonjour adds discovery of services on a local network without requiring you to type every address. Apple’s Bonjour architecture guide describes publishing, discovering and resolving those services. This explains why the process can be busy even when no browser window is visible: many kinds of app use network names.

The name alone does not prove the identity of a process. On the Mac checked for this guide, running macOS 27.0.1 on 23 October 2026, ps showed /usr/sbin/mDNSResponder owned by _mdnsresponder. The separate /usr/sbin/mDNSResponderHelper was owned by root. Those are observations of this installation, not a guarantee about every process using a similar name.

What counts as normal activity?

Apple does not publish a normal CPU percentage or a time limit for this daemon. Short activity while apps connect, the Mac joins a network or services are discovered is consistent with its job. A single Activity Monitor sample cannot establish a fault.

Investigate when activity persists while your usual apps are quiet, when it coincides with failed connections, or when heat and battery drain appeared after a specific network change. Record what was happening instead of treating an unfamiliar daemon name as malware. The Activity Monitor guide explains CPU measurements; the slow Mac guide helps check whether DNS work is actually the bottleneck.

Find the app or network change behind it

1. Close network-heavy work one app at a time. Save first, then quit a browser, sync client or other recently active app. Watch whether the daemon’s activity changes.
2. Review recent network software. A VPN, DNS filter, ad blocker or security extension is a useful diagnostic candidate if the issue started after its installation. That timing is a clue, not proof.
3. Compare networks where permitted. If the behavior only occurs on one Wi-Fi network, record that result for its administrator. Do not change a workplace network configuration just to experiment.
4. Update the suspected app and macOS. Use the app’s own updater and System Settings › General › Software Update.
5. Restart normally if the symptom persists. Save work first, then compare under the same workload.

These are controlled comparisons, not Apple-documented causes of every high-CPU case. Do one at a time. Pausing a personal VPN can expose traffic to the ordinary network, so only compare when that is acceptable and restore the previous state afterwards. For managed network extensions, ask IT instead.

Inspect DNS without rewriting the setup

Apple documents System Settings › Network › your network service › Details › DNS on macOS 15 Sequoia, macOS 26 Tahoe and macOS 27. Inspecting the listed servers and search domains changes nothing. Do not replace them randomly; an organization may require them for internal names.

For a read-only identity check in Terminal:

ps -axo user,pid,comm | grep '[m]DNSResponder'

This prints matching process owners, IDs and executable paths. It needs no sudo, changes nothing and requires no undo. It was run on macOS 27.0.1 for this page. The brackets keep the search command itself out of the matches. If your system restricts process inspection, use Activity Monitor’s All Processes view instead of changing security settings.

When flushing DNS is relevant

A DNS-cache refresh can help a stale name-resolution problem, such as a site pointing at an old address after a change. It is not a general cure for sustained daemon CPU, and it does not repair a bad VPN policy, router or upstream DNS server.

The DNS cache guide owns the commands and their authorization details. This page avoids duplicating them. If names resolve correctly and the only concern is the process’s presence, there is no reason to flush the cache routinely.

Leave the system service intact

The manual says mDNSResponder is started by the system and should not be run manually. Do not delete its binary, disable its launch service, or repeatedly kill it in a loop. That can disrupt name resolution and discovery while leaving the initiating problem untouched.

If persistent activity continues on an updated Mac with no identified app trigger, collect the workload and network details and contact Apple or the network administrator. Distinguish it from nsurlsessiond, which can perform background transfers: network-related names do not all describe the same job.

How Tend helps

mDNSResponder runs under a system account, so Tend does not list it by name in Energy & Apps; its work contributes to the macOS share. Free per-app CPU, memory and estimated watts can help you identify your own network-heavy apps to compare against Activity Monitor.

Pro’s Maintenance › Flush DNS performs a cache refresh and sends a hangup signal to mDNSResponder. It is for a name-resolution issue, not a CPU optimizer. Tend’s 24-hour energy totals are free; Pro adds 7- and 30-day totals, which are not a CPU history graph.

Questions

Related guides

Sources

• macOS 27.0.1, man mDNSResponder; read-only ps and binary-path inspection, 23 October 2026.
• Apple Developer, Bonjour Operations.
• Apple, DNS settings on macOS 15, macOS 26 and macOS 27.

Sources checked 23 October 2026. Spotted something out of date? Tell us and we'll fix it.