# Why Is mDNSResponder Using So Much CPU on My Mac

> mDNSResponder handles DNS and Bonjour for every app on a Mac. How to find what keeps it busy, flush its cache safely and check it is genuine.

Published: 2026-11-09

mDNSResponder is the macOS process that answers DNS lookups for every app and finds devices on your local network through Bonjour. It is a normal part of the system, it runs from `/usr/sbin/mDNSResponder` under its own `_mdnsresponder` account, and on a healthy Mac it sits near 0% CPU. When it stays busy, it is usually doing work for something else, such as a browser, a VPN or a noisy network, so the fix is to find that source rather than stop the process.

## What it does

Its manual page (`man mDNSResponder`) describes a daemon that implements Multicast DNS and DNS Service Discovery, performs DNS queries on behalf of other processes and keeps a cache of the answers. That is why the name turns up so often in Activity Monitor and network tools: when an app asks for an address, this process does the asking.

A second process, `mDNSResponderHelper`, runs as root beside it. On the Mac used for this page, the two looked like this while idle:

```text
_mdnsresponder  0.0% CPU  /usr/sbin/mDNSResponder
root            0.0% CPU  /usr/sbin/mDNSResponderHelper
```

## Find what is driving it

Open Activity Monitor, go to the **CPU** tab and watch `mDNSResponder` for a minute. A short spike is normal. If it stays high, change one thing at a time:

1. Quit browsers and apps that open many connections, and check whether the figure falls within a minute.
2. Turn off any VPN, proxy or DNS filter, since these change how every lookup is routed.
3. Join a different network, such as a phone hotspot. If the load disappears, the cause is on the old network.
4. To see what your network advertises, run this for a few seconds and press `Ctrl + C` to stop it:

```bash
dns-sd -B _services._dns-sd._udp local
```

A long, constantly changing list points to a network with many Bonjour devices.

| You see | Likely cause | Try |
| --- | --- | --- |
| A spike when you open a browser or an app | Normal lookups | Nothing |
| High CPU only with a VPN or proxy on | Its DNS settings or filter | Update it, or check its DNS settings |
| High CPU only on one network | Many or misbehaving Bonjour devices | Test another network, then restart the router or the suspect device |
| Sites fail or show old addresses | A stale or wrong DNS answer | [Flush the DNS cache](https://mole.fit/blog/how-to-flush-dns-cache-mac) |
| High data usage under its name | Lookups and local discovery | See [what app is using my network](https://mole.fit/blog/what-app-is-using-my-network-mac) |

## Is it safe to restart

Flushing the DNS cache sends the process a signal, and that is the supported way to clear it:

```bash
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
```

This takes a moment and needs your password. A restart of the Mac does the same job. Flushing only helps with wrong or stale answers, so if the process is busy because an app keeps asking, the load returns.

## Is it malware

The real file is at `/usr/sbin/mDNSResponder`, on the system volume, and macOS starts it from `/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist`. To check what is running, look at the path in Activity Monitor's inspector or run:

```bash
ps -axo user,pid,args | grep '[m]DNSResponder'
```

Be suspicious of a process with this name that runs from another folder, such as your home folder or `/tmp`. A correct path is good evidence, and it does not tell you which app is causing the lookups.

## What not to do

- Do not try to disable it. System Integrity Protection guards that launch daemon, and without this process name lookups across the Mac stop working.
- Do not use `kill -9` in place of `-HUP`. The `-HUP` form is what Apple's archived support article lists.
- Do not treat high data usage as a download. The traffic is lookups and discovery, and other apps' activity is what causes it.
- Do not install a "network booster" or a DNS cleaner because of it. Neither tells you what is asking.

## Where Mole fits

[Mole](https://mole.fit/) lists `mDNSResponder` in **Status** with its CPU and memory when it is busy, and the table's search finds it when it is not. **Why is this running?** in its menu shows the executable and what started it. macOS does not let Mole read this system account's ports, so no port list appears. Because it is a system network service, Mole offers no way to stop it. Mole Mac does not flush the DNS cache, and it does not change DNS or network settings, so use the Terminal command above for that. The per-app **Network** list, opened by clicking the network rates in the menu bar, can show it too, which helps you tell lookups from an app's real traffic.

## FAQ

### What is mDNSResponder on Mac?

It is the system process that performs DNS lookups for apps and finds devices on the local network through Bonjour. It runs from `/usr/sbin/mDNSResponder`.

### Why is mDNSResponder using so much CPU?

Usually something is making it do a lot of lookups or discovery: an app, a VPN or DNS filter, or a busy network. Change those one at a time and watch the figure.

### Can I quit or disable mDNSResponder?

Do not disable it. Name lookups for the whole Mac depend on it. To clear wrong answers, flush the DNS cache with the `-HUP` command.

### Is mDNSResponder a virus?

The real one runs from `/usr/sbin` and starts from a system launch daemon. A copy that runs from any other folder deserves a closer look.

### Why does mDNSResponder ask for network access or use data?

Its job is network lookups and local discovery, so it uses the network all the time. Its data figure reflects what other apps ask for and is normally small.

---

Canonical HTML page: https://mole.fit/blog/mdnsresponder-high-cpu-mac
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt