mDNSResponder — your Mac's DNS resolver and Bonjour service

Last updated: 2026-07-30

What it is

mDNSResponder is one of the oldest and most load-bearing services in macOS. It does two separate jobs that happen to share an implementation.

The first is DNS resolution. When any application on your Mac needs to turn a hostname like example.com into an IP address, it does not talk to your DNS server directly — it asks mDNSResponder, which maintains the cache, applies your network's DNS settings, and handles the actual query. Every app on the machine funnels through it.

The second is Bonjour, Apple's zero-configuration networking. This is what lets your Mac find an AirPrint printer, see an Apple TV in the AirPlay menu, or spot another Mac's shared folder without anyone typing an IP address. It works by sending and listening for multicast DNS messages on the local network.

Apple briefly split these responsibilities into a service called discoveryd in OS X Yosemite, then reverted to mDNSResponder after a rocky release. If you remember discoveryd from old troubleshooting posts, this is its replacement — or rather, its predecessor restored.

Why it talks to the network

Two different kinds of traffic, and it helps to keep them apart.

Outbound DNS queries go to whichever resolver your network hands out over DHCP, or to a custom one if you have set it manually. These are small, frequent, and triggered by essentially everything: opening a web page, checking mail, an app phoning home for updates.

Local multicast goes to 224.0.0.251 on port 5353 and never leaves your local network. This is the Bonjour half. Your Mac both announces the services it offers and listens for announcements from others. On a busy office or campus network with a lot of Apple hardware, this chatter can be constant even when you are doing nothing.

That second category is why mDNSResponder can look alarming in a monitoring tool. It shows a lot of activity, to a lot of destinations, all the time — but most of it is a few hundred bytes of local housekeeping.

How much traffic is normal

Small. This is a process with a very high connection count and a very low byte count, and confusing the two is the single most common misreading.

A single DNS query and its response are typically tens to a few hundred bytes. Even a heavy browsing day, with thousands of lookups, generally lands somewhere in the low single-digit megabytes. Multicast discovery adds a steady trickle rather than any real volume.

So the useful rule is: judge mDNSResponder by data, not by connection count. Hundreds of connections is Tuesday. Hundreds of megabytes is not, and is worth looking into — a misconfigured resolver retrying in a loop, an app hammering lookups because it cannot reach a host, or a captive portal fighting with your DNS settings can all inflate it far beyond anything normal.

Can you turn it off

No, and you should not try. This is a keep process in the strongest sense.

macOS treats mDNSResponder as essential infrastructure. If you kill it, launchd restarts it within seconds, and during the gap your Mac cannot resolve hostnames — which to the user looks exactly like the internet has stopped working, even though the connection is fine.

What you *can* reduce is the Bonjour half, if local discovery traffic is what bothers you. Turning off AirDrop, Printer Sharing, File Sharing and Media Sharing in System Settings cuts down what your Mac announces and listens for. Your Mac keeps resolving names normally; it just stops participating in as much local chatter. On a home network there is rarely a reason to bother.

Seeing what it actually used

Because mDNSResponder carries DNS on behalf of every other app, it is a process where "how many connections" and "how much data" tell completely different stories — and most tools only show you the first one.

Bytetally tracks upload and download separately for each process, live and over time, so you can tell the difference between a service that is merely busy and one that is genuinely moving data. If mDNSResponder's numbers ever do look wrong, that distinction is what tells you whether there is a real problem or just a lot of normal lookups.

Related processes

Common questions