You say "the MagicDNS server" like it's a quad-8 thing out on the internet. That server lives in the tailscale process on localhost. In some configurations on some OSes, we do have to route requests through that in order to polyfill missing OS features (usually, implementing split-DNS policies that the OS cannot represent natively, or transparently upgrading to DoH for upstreams that support it). You can inspect the logic that decides how to implement DNS policy depending on the policy and OS in https://github.com/tailscale/tailscale/tree/main/net/dns, as well as inspect what the in-process DNS forwarder does (extremely boring: match query suffix in configuration, forward packet to appropriate upstreams).
If you're on Linux, you want systemd-resolved, as it's the only Linux DNS resolver that's really any good, regardless of your opinions on systemd overall (See https://tailscale.com/blog/sisyphean-dns-client-linux/)
In any case, file a bug with details and we'll fix it up if there are still issues.
I want to be prepared if it happens, spent too much time figuring out weird Docker - DNS/network interactions on hotel wifis and the like...