Does that bypass my DNS server when the client is connected to the tailnet?

Yes. A search path is installed so that the OS queries MagicDNS. MagicDNS is a DNS resolver within Headscale and nodes that are on the tailnet will use it to get the tailnet IP of the names being queried under your MagicDNS domain. You MagicDNS path can be a subdomain of your domain (hs or ts.mydomain.com) or anything (.magic). photos -> check with MagicDNS does it have photos.magic? Return the photos node IP 100.x.x.x.).

It doesn’t need to go to your AdGuard DNS server because every node will query the search path that is added to the OS when joining the tailnet. It’s the reason why your MagicDNS domain name needs to be unique, and why it doesn’t technically need to be a subdomain of your internet routed domain.

Should I still leave it on for local traffic?

Depends on what you want. Is your local traffic expected to go over the tailnet? If every device isn’t on the tailnet then you probably still want the local network setup you have.

And if I’m connected to the tailnet from outside, how do I propagate all the addresses?

Every tailnet node has a node name. You can spin up extra nodes so that they resolve a node name to the service it’s managing. You can do this pretty easily with containers. The alternative is to configure MagicDNS with extra_records so that multiple A records resolve to the same tailnet IP. Then you either need the services to be on different ports or have a reverse proxy split out based on the connection header (e.g. to route photos to Immich and music to Navidrome).

This is ignoring all “exit node” scenarios. Exit nodes can help bridge your local traffic to the tailnet, or bridge your services to the public.