I’ve also run into various capacity issues in each US region I have worked in. East US 2 has been least constrained for me, but I recall that I was still bouncing around between VM instance types to find one that worked last time I deployed fresh.
I’d expect most firewalls to allow DNS traffic to locally configured resolvers without prompts, and I figure this is also extended to mDNS traffic, which doesn’t leave your local LAN by default.
From the mDNS side of things, you could easily block if your firewall allows you to set up port based deny rules (in this case UDP/5353). This should resolve the privacy leak from the OP, though you may find that you lose expected functionality on your host and local network depending on whether you block inbound, outbound, or both.
Unicast DNS gets a bit trickier (even without considering DoH). Depending on browser and OS configuration, you won’t be talking to more than a handful of resolvers directly. Ideally, you allow communication with these resolvers and block all other DNS traffic. You definitely don’t want to set a rule that allows you to accept each and every query, so in that sense, DNS will be bypassing the firewall.
What’s better in this case is resolver with filtering capabilities, e.g., pihole.
I just gave a DOCSIS 3.0 modem to a friend who was paying $7 per month on a DOCSIS 2 modem that couldn't provide the subscribed speed. Comcast had already charged her for a couple of truck rolls to troubleshoot the speeds, so it boggles my mind why the rented modem had not been replaced.
Even more interesting is that Comcast does have infrastructure in place to notify customers of these issues, though I have only seen them use it to convert customers who bought equipment back to renting. When I bumped my modem into the D3.1 threshold last year, the company made a number of calls to let me know that I could improve my experience by going back on a rental plan.