Apple - How to stop mDNSResponder from using 90-100% CPU continuously forever on Catalina?

Here's my recommendation:

1. Let's see what mDNSResponder is actually doing. Here's a utility to turn off/on censorship behind the <private>label. Make sure to turn it back on once you're done. You may find something like the process is hung up on something and just loops continually, or something like that. https://georgegarside.com/blog/macos/sierra-console-private/

2. Get a packet capture of your network as you make a DNS request. Grab Wireshark, start a capture on the interface you're using (be it ethernet or WiFi; but make sure the one(s) you're not using are off/unplugged). I would do this first in the environment where it takes 20-30s, and then again after a reboot when the conditions are such that it only takes 2-3s. The less you can have using the network the better as you run these packet captures, as they'll get big fast. This should show us the DNS request as well as requests to and from the websites themselves, so we can see where the delays are. If there aren't delays in the network, then we'd look at processes instead.

3. Upload relevant parts of the logs and/or the packet capture(s) somewhere for us to look at. Make sure you censor or remove any private data.

4. And, finally, note that this may be solved faster by doing an in-place OS reinstall. That may oppose your views on being able to fix your equipment, knowing what goes on with your equipment, etc., but if the goal is to get mDNSResolver back to sanity as quickly as possible, an in-place OS reinstall may be the quickest way there.

EDIT: I was able to re-create the issue and capture the related network traffic. Many section of RFC 6762 (Multicast DNS) seem relevant - I won't post excerpts here, but specifically I found parts of sections 3, 5, 5.2 and 10.2, to be highly relevant.

Here's what I think is happening.

Upon creating these lo0 aliases, traffic is constantly generated with a "cache flush" flag. The RFC doesn't get into enough detail about it for me to be sure, but it seems like each of the loopback addresses are advertising themselves as being the address that can respond to queries made to the hostname of the machine, and therefore listening devices should flush their internal caches and update them with the new IP address.

Think about it, if the network thinks you're hostname.local at 192.168.44.111 and your IP address changes, mDNS will blast out a "flush your caches, hostname.local is now 192.168.44.123!" message on 224.0.0.251. This is one circumstance where mDNS will proactively advertise a new IP, and it's the reason network browsing works so well - i.e., networked printers as per the RFC.

What doesn't make a ton of sense to me, is there are parts of the RFC that have me think multiple active loopback addresses on the same machine wouldn't be spamming the way they are - but then I may not be understanding the RFC well. Either way, it seems clear to me that the mDNSResponder process is looping through each loopback interface and telling everyone on 224.0.0.251 to disregard the last guy who took charge, this is the new IP address assigned to my hostname!

I'm not exactly clear on why this slows down regular DNS queries, except if mDNSResponder is responsible for sending out and receiving the regular DNS queries, well, it's tied up in all this nonsense with the other interfaces. And/or, perhaps the DNS queries would go out and come back in on whichever interface has most recently taken charge of the hostname. That, I could see really causing delays, because in the time a DNS request over WAN comes back, the responding loopback interface would be different than the one it went out from. But I'm just spitballing wildly at this point.

Further, instead of having to restart, you can change your script slightly. If ifconfig lo0 alias "$ADDR" up was used to bring up a new interface alias, then ifconfig lo0 -alias "$ADDR" can be used to bring it down.