Interface-specific DNS not set if not overriding local nameserver

[handsomexdd1024]

Bug description

When connecting to headscale server, I configured dns_config.override_local_dns to false, and observed that systemd-resolved's interface-specific for tailscale0 is not set to 100.100.100.100. In general, I tested several configurations, and the results are here:

I expect that 100.100.100.100 be set as interface-specific nameserver even when override_local_dns is not enabled, otherwise FQDNs internal to my tailnet (hostname.username.base_domain) will not be resolved by 100.100.100.100, and thus is not giving back correct responses.
Everything else works as expected.

Environment

• OS:
  • Headscale host: Debian 12.1 with linux-6.1.0
  • Tailscale client: Arch Linux Rolling with linux-6.5.3
• Headscale version: 0.22.3
• Tailscale version: 1.48.2

I'll post logs later

resolvectl status tailscale0 outputs when connected to headscale:

Link 8 (tailscale0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
        DNS Domain: my.tailnet.domain ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa (and etc)

when connected to tailscale official server:

Link 8 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100
        DNS Domain: my.tailnet.domain ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa (and etc)

To Reproduce

• Turn off override_local_dns
• Connect to headscale with --accept-dns=true
• Run resolvectl status tailscale0 on the client to check results

[hrtkpf]

I can confirm this issue.

Related: #660 (comment), #905

[purefns]

I'm also experiencing the same issue on Linux Mint unfortunately. The system is using systemd-resolved in stub mode and tailscaled is setting the correct search domain, but not the control nameserver... It's too late for me to mess around with it right now but setting the DNS manually with resolvectl dns tailscale0 100.100.100.100 works fine for now.

My two other nodes - an Android, and a tailscale Docker container - are both working just fine. For reference, I have "Override Local DNS" off, and MagicDNS on. Setting override to on breaks DNS resolution for my LAN services so those settings work the best for me right now. Turning off MagicDNS changes nothing either.

I'll update with logs from journalctl -u tailscaled on the Mint host as soon as I can, and anything else I can think of.

[9Ninety]

Here is a temporary solution to make MagicDNS work without manually running the resolvectl command:

Create a service override configuration file:

sudo mkdir -p /etc/systemd/system/tailscaled.service.d
sudo nano /etc/systemd/system/tailscaled.service.d/fix-headscale-magicdns.conf

Write the following content to the file:

[Service]
# This trick allows you don't have to waiting for an extra 15 seconds during system boot-up or service restart.
ExecStartPost=/bin/sh -c "/bin/sh -c 'sleep 15s && /usr/bin/resolvectl dns tailscale0 100.100.100.100' &"

Caution: Try the command /bin/sh -c "sleep 15s && /usr/bin/resolvectl dns tailscale0 100.100.100.100 and make sure it works on your machine before continuing.

Reload the systemd configuration and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart tailscaled

[handsomexdd1024]

@9Ninety Brilliant solution! Thank you so much.

[github-actions]

This issue is stale because it has been open for 90 days with no activity.

[hrtkpf]

I think this is still relevant.

[almereyda]

I'm not able to reproduce this on Ubuntu 23.10 (systemd 253) with latest Headscale 0.23.0-alpha5 and Tailscale 1.60.1 and override_local_dns: false and --accept-dns enabled.

$ tailscale debug prefs | jq '.CorpDNS'
true

`resolvectl status tailscale0`

Link 4 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100
        DNS Domain: current-user.example.internal ~0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa
                    ~100.100.in-addr.arpa ~101.100.in-addr.arpa
                    ~102.100.in-addr.arpa ~103.100.in-addr.arpa
                    ~104.100.in-addr.arpa ~105.100.in-addr.arpa
                    ~106.100.in-addr.arpa ~107.100.in-addr.arpa
                    ~108.100.in-addr.arpa ~109.100.in-addr.arpa
                    ~110.100.in-addr.arpa ~111.100.in-addr.arpa
                    ~112.100.in-addr.arpa ~113.100.in-addr.arpa
                    ~114.100.in-addr.arpa ~115.100.in-addr.arpa
                    ~116.100.in-addr.arpa ~117.100.in-addr.arpa
                    ~118.100.in-addr.arpa ~119.100.in-addr.arpa
                    ~120.100.in-addr.arpa ~121.100.in-addr.arpa
                    ~122.100.in-addr.arpa ~123.100.in-addr.arpa
                    ~124.100.in-addr.arpa ~125.100.in-addr.arpa
                    ~126.100.in-addr.arpa ~127.100.in-addr.arpa
                    ~64.100.in-addr.arpa ~65.100.in-addr.arpa
                    ~66.100.in-addr.arpa ~67.100.in-addr.arpa
                    ~68.100.in-addr.arpa ~69.100.in-addr.arpa
                    ~70.100.in-addr.arpa ~71.100.in-addr.arpa
                    ~72.100.in-addr.arpa ~73.100.in-addr.arpa
                    ~74.100.in-addr.arpa ~75.100.in-addr.arpa
                    ~76.100.in-addr.arpa ~77.100.in-addr.arpa
                    ~78.100.in-addr.arpa ~79.100.in-addr.arpa
                    ~80.100.in-addr.arpa ~81.100.in-addr.arpa
                    ~82.100.in-addr.arpa ~83.100.in-addr.arpa
                    ~84.100.in-addr.arpa ~85.100.in-addr.arpa
                    ~86.100.in-addr.arpa ~87.100.in-addr.arpa
                    ~88.100.in-addr.arpa ~89.100.in-addr.arpa
                    ~90.100.in-addr.arpa ~91.100.in-addr.arpa
                    ~92.100.in-addr.arpa ~93.100.in-addr.arpa
                    ~94.100.in-addr.arpa ~95.100.in-addr.arpa
                    ~96.100.in-addr.arpa ~97.100.in-addr.arpa
                    ~98.100.in-addr.arpa ~99.100.in-addr.arpa ~other-user.example.internal
                    ~data.example.internal ~third_user.example.internal ~road.example.internal

Is this maybe an upstream condition, eventually related to distribution-specific packaging/configuration?

[mimnix]

Same issue here with the following setup:

Headscale host: docker image headscale/headscale:0.23.0-alpha8
Tailscale client: v1.64.0 on Arch Linux Rolling with linux-6.8.5

[handsomexdd1024]

Recent tests showed that this bug has been fixed somehow, so I'm closing this issue.