mDNSResponder on Mac: what it is and why it uses CPU

What mDNSResponder does

Two jobs, one process. The first is ordinary DNS. When any app on your Mac wants to reach a server by name, it asks mDNSResponder, which asks your router or the DNS servers you configured, caches the answer, and hands it back. Every website, every app update, every sync request begins with one of these lookups.

The second job is Bonjour, Apple's zero-configuration networking. Bonjour is how your Mac finds printers without a driver disc, sees AirPlay TVs and HomePods, shows nearby Macs in the Finder sidebar, and lets AirDrop, Handoff and Continuity find your other devices. It works by multicast: devices on the local network announce themselves and answer questions on their own, and mDNSResponder is the part of macOS that listens, asks and answers. The code is open source and shared with iOS, and the same engine is used on Windows through Bonjour for Windows.

What normal looks like

Why mDNSResponder is using CPU right now

1. A crowded network. On a home network there might be ten Bonjour devices. In an office, a school or an apartment building with shared Wi-Fi there can be hundreds, all announcing. mDNSResponder processes every announcement. Nothing on your Mac is wrong; the network is loud.
2. A VPN, DNS filter or security tool in the path. VPN clients, ad blockers that run as a local DNS, parental controls and corporate security agents all insert themselves between mDNSResponder and the real DNS servers. When one of them is slow or looping, mDNSResponder retries, and the retries show up as CPU and outbound data.
3. An app opening a huge number of connections. Torrent clients, crawlers, some developer tools, and browsers with hundreds of tabs each make lookups constantly. The lookups are mDNSResponder's work even though the app caused them.
4. AirPlay, screen mirroring or a printer search in progress. Searching for devices is a burst of Bonjour traffic. It ends when the search does.
5. A device on the network that will not stop announcing. A misbehaving printer, smart TV or IoT gadget can flood the network with multicast. Every Mac on the network pays for it.
6. Wake for network access. mDNSResponder is part of why a sleeping Mac answers on the network. It also shows up in sleep logs as a wake source for DHCP lease renewal, which is normal.

Is it safe to quit mDNSResponder?

Do not quit it from Activity Monitor. It runs as a system daemon and launchd restarts it at once, but for the second or two it is down every app loses name lookups: pages fail to load, syncs error, AirPlay devices vanish and reappear. You gain nothing because the cause (the network, the VPN, the app) is still there. The widely shared sudo killall -HUP mDNSResponder command is a different thing: it tells the daemon to flush its DNS cache without stopping, and it is a legitimate step when a website's address has changed. It will not fix high CPU, and this page does not ask you to run anything with sudo.

Networking on a Mac spreads across several processes. Type networkd, configd, sharingd or rapportd above if they are rising alongside mDNSResponder; they usually move together on a busy network.

What to do, in order

1. Change networks for a minute

   Join your phone's hotspot or a different Wi-Fi. If mDNSResponder drops to zero, the original network is the cause, not the Mac. On a shared or office network that is simply what it costs to be there.

2. Disconnect the VPN or DNS filter

   Turn off any VPN, ad-blocking DNS, parental control or security agent that handles DNS. Watch Activity Monitor for thirty seconds. If the number falls, that tool is looping; update it or change its DNS setting.

3. Quit the heavy app

   Browser with hundreds of tabs, torrent client, crawler, a developer tool polling a server. Quit them one at a time and watch mDNSResponder. The app that makes it drop is making the lookups.

4. Finish or cancel device searches

   Close the AirPlay picker, the Add Printer window, and the Finder Network view. Each one keeps a Bonjour search open while it is on screen.

5. Restart the router, then the Mac

   A router that has lost track of multicast groups, or a device on the network flooding announcements, is cleared by a router restart. A Mac restart resets mDNSResponder's own state and cache without any Terminal commands.

6. Switch off Wake for network access if sleep is the problem

   System Settings, Battery (laptops) or Energy (desktops), Options. If your Mac wakes at night and the sleep log names mDNSResponder, this is the setting that stops it answering while asleep.

When to worry

Worry when mDNSResponder stays above 30 percent on a quiet home network with no VPN, no filter and every heavy app closed, and a restart of both router and Mac does not change it. That is rare, and the usual explanation is a security product or a leftover DNS profile from an old app; System Settings, General, Device Management and VPN & Filters show those. Do not worry about constant small outbound traffic: multicast DNS is chatty by design, and a few kilobytes a minute is normal. Do not worry that mDNSResponder is spying on you; it answers the questions other devices ask about yours, and it only announces services you have turned on, such as file sharing or AirPlay receiver. Turn those off in System Settings, General, Sharing and the announcements stop.

Safe to Quit, the Mac app behind this site, shows this verdict next to mDNSResponder and every other process, so the name stops being a mystery. If your Mac wakes at night, our battery drain guide covers the wake sources in order.