FR: granular options for accepting the DNS settings

### What is the issue?

Here's my situation. I have a tailnet node that has a DNS server running on it. Think PiHole, AdGuardHome, dnsmasq or an equivalent. This server is listening on `0.0.0.0#53`. This DNS server is intended to serve users on the LAN and also users on the tailnet. To that effect this node also runs tailscale.

Now, in order to set up all the other tailnet nodes to use this DNS server, I configured the following two options (or rather their equivalent in headscale):

* "Override Local DNS" = true
* Nameservers = 100.64.0.8 (the tailnet address of the DNS server node)

Unfortunately in this scenario the DNS server does not appear to be used any longer, whether from the machine on which this server is running or from the tailnet nodes.

I have troubleshooted this down to the fact that `tailscale` sets up systemd-resolved with `Domains = mytailnet ~.` (more specifically the `~.` part is the culprit.) I imagine this causes `tailscale` on this server to try recursively querying itself until it gives up.

In order to rectify this issue I did the following (on the server in question):

1. `tailscale set --accept-dns=false`
2. ```
#cat /etc/systemd/network/01-tailscale-dns.network
[Match]
Name=tailscale*

[Network]
DNS=100.100.100.100
Description=Manually set up tailscale DNS settings
Domains=mytailnet
```

effectively setting up tailscale’s DNS settings sans the `~.` manually.

This actually achieves the intended functionality, except that upon a startup of `tailscaled` I am seeing the following log messages:

```
...
Jan 03 00:22:52 tailscaled[1680774]: pm: using backend prefs for "profile-4b44": Prefs{ra=false dns=false want=true routes=[0.0.0.0/0 ::/0] snat=true nf=on url="local-headscale" op="nagisa" update=check Persist{lm=, o=[dUREI], n=[LdZfj] u="nagisa"}}

Jan 03 00:22:52 tailscaled[1680774]: active login: nagisa
Jan 03 00:22:52 tailscaled[1680774]: Switching ipn state NoState -> Starting (WantRunning=true, nm=true)
Jan 03 00:22:52 tailscaled[1680774]: magicsock: SetPrivateKey called (init)
Jan 03 00:22:52 tailscaled[1680774]: wgengine: Reconfig: configuring userspace WireGuard config (with 0/7 peers)
Jan 03 00:22:52 tailscaled[1680774]: wgengine: Reconfig: configuring router
Jan 03 00:22:52 tailscaled[1680774]: wgengine: Reconfig: configuring DNS
Jan 03 00:22:52 tailscaled[1680774]: dns: Set: {DefaultResolvers:[] Routes:{} SearchDomains:[] Hosts:8}
Jan 03 00:22:52 tailscaled[1680774]: dns: Resolvercfg: {Routes:{} Hosts:8 LocalDomains:[]}
Jan 03 00:22:52 tailscaled[1680774]: dns: OScfg: {}
Jan 03 00:22:52 tailscaled[1680774]: dns: failed to configure resolved: setLinkDNS: Link tailscale0 is managed.
Jan 03 00:22:52 tailscaled[1680774]: health("dns-os"): error: setLinkDNS: Link tailscale0 is managed.
Jan 03 00:22:52 tailscaled[1680774]: health("dns"): error: setLinkDNS: Link tailscale0 is managed.
```

and then when I run `tailscale status` I see the similar `setLinkDNS` health checks.

In this scenario I think `tailscale` could detect that the interface is manually managed and that the manual settings are roughly what tailscale would set up for itself and avoid showing the healthcheck.

Alternatively, and more simply, if tailscale client’s DNS settings were made more granular, it would be much appreciated. That way manual configuration of `resolved` would not be necessary.

### Steps to reproduce

1. `tailscale set --accept-dns=false`
2. ```
#cat /etc/systemd/network/01-tailscale-dns.network
[Match]
Name=tailscale*

[Network]
DNS=100.100.100.100
Description=Manually set up tailscale DNS settings
Domains=mytailnet
```

### Are there any recent changes that introduced the issue?

Not that I’m aware of. This is me trying to set up a fresh tailnet.

### OS

_No response_

### OS version

NixOS

### Tailscale version

1.56.1

### Other software

systemd 254 (254.6)

### Bug report

BUG-NO-LOGS-NO-SUPPORT-this-node-has-had-its-logging-disabled >.<