If you\u2019ve spotted a process called mDNSResponder<\/strong> pushing surprisingly large amounts of data in Activity Monitor, you\u2019re not alone. In many reports, it shows up as the top talker on Wi-Fi, apparently \u201cusing all the bandwidth\u201d out of the blue.<\/p>\n Most of the time, this isn\u2019t malware. It\u2019s a legitimate macOS service doing its Bonjour \/ multicast DNS routine a bit too enthusiastically \u2013 often stirred up by noisy devices or a quirky network rather than anything on the Mac itself. That said, constant chatter from mDNSResponder can make a laptop feel sluggish, drain the battery, and turn a decent Wi-Fi setup into a laggy mess.<\/p>\n Below is a deep dive into what\u2019s going on and, more importantly, what you can do to bring this daemon back to normal.<\/p>\n mDNSResponder is Apple\u2019s implementation of multicast DNS (mDNS)<\/strong> and Bonjour<\/strong> service discovery. A component of the launchd<\/strong> umbrella process, it lets your Mac do the following:<\/p>\n Instead of asking a central DNS server, mDNSResponder uses a special multicast address 224.0.0.251:5353<\/strong> (or ff02::fb on IPv6) to shout, \u201cWho provides this service?\u201d and to answer the same question from other devices. It also handles some regular unicast DNS lookups, so you may see it active even when nothing particularly \u201clocal\u201d is going on.<\/p>\n Under normal conditions, the traffic footprint is modest. The daemon periodically announces your Mac\u2019s services, responds to queries from other hosts, and performs lookups on demand. You won\u2019t notice anything beyond a few kilobytes here and there.<\/p>\n When something goes wrong, though, this background helper can start chattering incessantly. That\u2019s when it jumps to the top of Activity Monitor\u2019s Network tab and leaves you wondering what exactly it\u2019s doing with your bandwidth.<\/p>\n Let\u2019s look at the usual suspects that push this normally quiet daemon into overkill mode.<\/p>\n Modern home and office networks are packed with small devices that love to advertise themselves non-stop:<\/p>\n Some vendors\u2019 Bonjour implementations are less than elegant. A buggy or misconfigured device may:<\/p>\n mDNSResponder on your Mac has to deal with all of that. If a gadget is spamming multicast packets several times per second, every other Bonjour node on the subnet (including your Mac) gets dragged into the storm.<\/p>\n If AirDrop<\/strong> is set to Everyone<\/strong> and AirPlay Receiver<\/strong> is enabled, your Mac effectively behaves like a beacon and a listener at the same time. On a dense network (think campus Wi-Fi, office floor, or a busy public hotspot), this can be a double-edged sword.<\/p>\n In a home environment this is usually fine. On a network with hundreds of clients, things can spiral into a steady stream of multicast traffic.<\/p>\n mDNS is supposed to be link-local<\/strong>. However, the real world is full of edge cases:<\/p>\n In this scenario, mDNSResponder may keep retrying queries that never get proper answers. From your side, it looks like constant outbound traffic that seemingly leads nowhere.<\/p>\n If you have mesh nodes, range extenders, or multiple switches wired in questionable ways, you can end up with:<\/p>\n Again, the daemon on your Mac is simply participating in the broken conversation. The root cause sits in the infrastructure rather than macOS itself.<\/p>\n Some apps periodically scan the local network for peers, media servers, game sessions, or collaboration endpoints. If their discovery logic is too aggressive, they may trigger a spike in mDNS traffic by:<\/p>\n Occasionally, adware or shady utilities piggyback on Bonjour to locate other devices on the LAN or to expose a local web interface. It\u2019s not the norm, but if high mDNSResponder usage coincides with pop-ups, redirects, or strange background processes, a security angle is worth considering.<\/p>\n Here\u2019s what you\u2019ll usually see when this daemon goes into loud mode:<\/p>\n Activity Monitor \u2192 Network<\/strong> tab shows mDNSResponder at or near the top, with large sent\/received figures that keep climbing.<\/p>\n<\/li>\n The nettop<\/strong> command in Terminal shows rapid counters for mDNSResponder, often to On laptops, Wi-Fi feels saturated<\/strong>: high latency, delayed page loads, choppy video calls, or streaming stutter.<\/p>\n<\/li>\n Battery life tanks<\/strong> because the network stack and CPU keep waking up.<\/p>\n<\/li>\n Fans spin up<\/strong> if the daemon keeps the CPU busy, not just the NIC.<\/p>\n<\/li>\n The issue gets worse when:<\/p>\n If this description rings a bell, let\u2019s move on to the practical part.<\/p>\n If its counters shoot up noticeably faster than everything else, you\u2019re indeed dealing with a Bonjour-related issue rather than a random app eating all the bandwidth.<\/p>\n For a more granular view:<\/p>\n Let\u2019s start with the low-hanging fruit: scaling back Apple\u2019s own discovery features.<\/p>\n Keep AirDrop closed afterward and watch Activity Monitor for a bit. If traffic drops significantly, you\u2019ve just found a major contributor.<\/p>\n On recent macOS versions (Monterey and newer):<\/p>\n Again, keep an eye on mDNSResponder in Activity Monitor after making the change.<\/p>\n Every sharing toggle you enable is another Bonjour service announced over the network. If you don\u2019t use some of them regularly, it makes sense to cut down the noise.<\/p>\n Open System Settings<\/strong> (or System Preferences<\/strong> on older macOS).<\/p>\n<\/li>\n Go to General \u2192 Sharing<\/strong> (or simply Sharing<\/strong> in older layouts).<\/p>\n<\/li>\n Review and temporarily disable items you don\u2019t actually rely on, for example:<\/p>\n After each change, give it a minute and watch the mDNSResponder network stats again.<\/p>\n<\/li>\n<\/ol>\n You don\u2019t necessarily have to keep everything off permanently. The idea is to pinpoint which service, if any, is a big talker on your specific LAN.<\/p>\n This step helps answer a key question: Is the problem your Mac, or the network it\u2019s on?<\/strong><\/p>\n Try the following:<\/p>\n If mDNSResponder calms down on a different network, the root cause is likely:<\/p>\n In that case, your Mac is just the messenger. Fixing the underlying infrastructure, or at least isolating the worst offenders, is the real remedy.<\/p>\n When you\u2019ve narrowed it down to a specific network, the next move is isolating possible offenders. In a home or small office, it\u2019s usually feasible to do a bit of methodical testing:<\/p>\n If you see a dramatic drop in traffic when a particular device is offline, you\u2019ve found a likely troublemaker. Updating its firmware, resetting it to factory defaults, or replacing it with something less chatty may be the long-term fix.<\/p>\n If you only see the mDNSResponder spike when connected through a specific VPN client<\/strong>, or a guest \/ public Wi-Fi<\/strong> that uses a splash login page, then your traffic pattern is probably tied to how that environment deals with multicast.<\/p>\n A few things worth trying are as follows:<\/p>\n If you\u2019re on an enterprise network, you might need to involve the IT team to verify whether they\u2019re blocking or hairpinning mDNS in a way that induces constant retries.<\/p>\n When odd networking issues persist across multiple SSIDs or only affect one Mac in a group, resetting local settings is worth a shot.<\/p>\n Note: This doesn\u2019t erase your user data, but you\u2019ll need to rejoin Wi-Fi networks afterward.<\/em><\/p>\n This effectively forces macOS to rebuild its view of your network interfaces and some related preferences.<\/p>\n As mentioned, mDNSResponder is a legitimate system daemon. However, if high bandwidth usage coincides with browser redirects and pop-ups, suspicious extensions you don\u2019t remember installing, or unknown background processes in Activity Monitor – then you might be dealing with adware or a potentially unwanted application (PUA) that\u2019s causing abnormal network behavior in general. This may indirectly amplify Bonjour traffic or simply add to the confusion.<\/p>\n For most users, I don\u2019t recommend trying to disable mDNSResponder outright. It\u2019s tightly integrated with macOS, and recent systems won\u2019t let you unload it permanently anyway. Plus, breaking Bonjour often means:<\/p>\n That being said, in a lab or troubleshooting environment you can experiment with:<\/p>\n These are infrastructure changes rather than Mac tweaks, but they\u2019re sometimes the only realistic fix when you\u2019re stuck with noisy hardware you can\u2019t replace.<\/p>\n From a broader perspective, keeping this daemon quiet is mostly about keeping the local network tidy and not over-exposing your Mac\u2019s services.<\/p>\n Here are some practical habits that help:<\/p>\n![\"mDNSResponder](\"https:\/\/macsecurity.net\/img\/w5Y0374ZaR-360-01-mdnsresponder-activity-monitor-mac.avif "\\"mDNSResponder")
<\/picture><\/p>\nmDNSResponder – Process profile<\/h2>\n
\n\n
\n \nProperty<\/th>\n Details<\/th>\n<\/tr>\n<\/thead>\n \n Process name<\/strong><\/td>\n mDNSResponder<\/td>\n<\/tr>\n \n Category<\/strong><\/td>\n Resource hog, networking daemon, multicast DNS \/ Bonjour service<\/td>\n<\/tr>\n \n Related Processes \/ Services<\/strong><\/td>\n configd, discoveryd (legacy), nsurlsessiond, sharingd, AirPlay Receiver, AirDrop, Printer Sharing, File Sharing, Home Sharing, various Bonjour-speaking apps and IoT devices<\/td>\n<\/tr>\n \n Distribution Techniques<\/strong><\/td>\n Not malware in itself; amplified by misconfigured LANs, noisy IoT devices, aggressive AirDrop \/ AirPlay discovery, VPN \/ captive portal quirks, and occasionally adware or questionable apps that overuse local discovery<\/td>\n<\/tr>\n \n Symptoms<\/strong><\/td>\n Unusually high Network usage in Activity Monitor attributed to mDNSResponder, heavy multicast traffic on 224.0.0.251:5353, Wi-Fi congestion, battery drain on MacBooks, fans spinning up, lag when AirPlay \/ AirDrop panes are open or when joining busy guest networks<\/td>\n<\/tr>\n \n Damage<\/strong><\/td>\n Network saturation on Wi-Fi, slower browsing and streaming, higher latency in games and calls, faster battery drain, possible throttling by ISP on limited data plans<\/td>\n<\/tr>\n \n Severity Level<\/strong><\/td>\n Low to Medium (performance and bandwidth impact; limited security risk in typical cases)<\/td>\n<\/tr>\n \n Removal<\/strong><\/td>\n Tuning sharing and discovery features, isolating noisy devices, fixing network loops or multicast filtering issues, and scanning the Mac for adware or unwanted software if other symptoms are present<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What is mDNSResponder on Mac?<\/strong><\/h2>\n
\n
![\"mDNSResponder](\"https:\/\/macsecurity.net\/img\/UOwndrdT1R-360-02-mdnsresponder-launchd.avif "\\"mDNSResponder")
<\/picture><\/p>\nWhy mDNSResponder may be using excessive bandwidth<\/strong><\/h2>\n
1. Noisy IoT gear and chatty Bonjour ecosystems<\/strong><\/h3>\n
\n
\n
2. AirDrop and AirPlay discovery in crowded environments<\/strong><\/h3>\n
\n
3. VPNs, captive portals, and restrictive enterprise Wi-Fi<\/strong><\/h3>\n
\n
4. Network loops and broken multicast handling on routers<\/strong><\/h3>\n
\n
5. Apps overusing Bonjour or abusing local discovery<\/strong><\/h3>\n
\n
Typical symptoms of mDNSResponder bandwidth problems<\/strong><\/h2>\n
\n
224.0.0.251:5353<\/code> or the IPv6 equivalent.<\/p>\n<\/li>\n\n
Step-by-step guide to diagnose and fix mDNSResponder high bandwidth on Mac<\/strong><\/h2>\n
Step 1: Confirm mDNSResponder as the top talker<\/strong><\/h3>\n
\n
\n
nettop -m tcp -p mDNSResponder<\/code><\/li>\n224.0.0.251:5353<\/code> or similar multicast targets confirms that this is mDNS chatter rather than pure unicast DNS.<\/li>\n<\/ol>\n![\"Run](\"https:\/\/macsecurity.net\/img\/h_yIY6c5W6-360-03-mdnsresponder-nettop.avif "\\"Run")
<\/picture><\/p>\nStep 2: Temporarily tame AirDrop and AirPlay discovery<\/strong><\/h3>\n
Adjust AirDrop<\/strong><\/h4>\n
\n
![\"Adjust](\"https:\/\/macsecurity.net\/img\/ij9oGMjESI-360-04-mdnsresponder-adjust-airdrop.avif "\\"Adjust")
<\/picture><\/p>\nDisable AirPlay Receiver (if you don\u2019t need it)<\/strong><\/h4>\n
\n
Step 3: Turn off unneeded Sharing features<\/strong><\/h3>\n
\n
\n
![\"Disable](\"https:\/\/macsecurity.net\/img\/O2n5sswQfq-360-05-mdnsresponder-sharing.avif "\\"Disable")
<\/picture><\/p>\nStep 4: Test with a different network or hotspot<\/strong><\/h3>\n
\n
\n
Step 5: Hunt down noisy LAN devices<\/strong><\/h3>\n
\n
\n
\n
Step 6: Check VPN and captive portal behavior<\/strong><\/h3>\n
\n
Step 7: Reset network configuration on the Mac (advanced but safe)<\/strong><\/h3>\n
\n
\n
\/Library\/Preferences\/SystemConfiguration\/<\/code><\/li>\n<\/ul>\n<\/li>\n\n
com.apple.airport.preferences.plist<\/code><\/li>\ncom.apple.network.identification.plist<\/code><\/li>\nNetworkInterfaces.plist<\/code><\/li>\npreferences.plist<\/code><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n![\"SystemConfiguration](\"https:\/\/macsecurity.net\/img\/5-00PFxh8G-360-06-mdnsresponder-systemconfiguration.avif "\\"SystemConfiguration")
<\/picture><\/p>\n\n
Step 8: Scan the Mac for adware or unwanted software<\/strong><\/h3>\n
Step 9: Last resort: Temporarily block or restrict mDNS (expert only)<\/strong><\/h3>\n
\n
\n
How to prevent mDNSResponder issues going forward<\/strong><\/h2>\n
\n