starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Interface-specific DNS not set if not overriding local nameserver #557

New Issue
Closed
opened 2025-12-29 02:20:17 +01:00 by adam · 11 comments
adam commented 2025-12-29 02:20:17 +01:00
Owner
Copy Link

Originally created by @handsomexdd1024 on GitHub (Sep 18, 2023).

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:
image
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
Originally created by @handsomexdd1024 on GitHub (Sep 18, 2023). ## Bug description <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> 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: ![image](https://github.com/juanfont/headscale/assets/36498278/aae2dcb1-be40-4dde-addf-fcbe3140603a) 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: ```text 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: ```text 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
adam added the bug label 2025-12-29 02:20:17 +01:00
adam closed this issue 2025-12-29 02:20:17 +01:00
adam commented 2025-12-29 02:20:17 +01:00
Author
Owner
Copy Link

@hrtkpf commented on GitHub (Sep 18, 2023):

I can confirm this issue.

Related: https://github.com/juanfont/headscale/issues/660#issuecomment-1712839303, #905

@hrtkpf commented on GitHub (Sep 18, 2023): I can confirm this issue. Related: https://github.com/juanfont/headscale/issues/660#issuecomment-1712839303, #905
adam commented 2025-12-29 02:20:17 +01:00
Author
Owner
Copy Link

@purefns commented on GitHub (Oct 19, 2023):

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.

@purefns commented on GitHub (Oct 19, 2023): 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.
adam commented 2025-12-29 02:20:18 +01:00
Author
Owner
Copy Link

@9Ninety commented on GitHub (Dec 4, 2023):

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
@9Ninety commented on GitHub (Dec 4, 2023): Here is a temporary solution to make MagicDNS work without manually running the resolvectl command: Create a service override configuration file: ```sh 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: ```ini [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: ```sh sudo systemctl daemon-reload sudo systemctl restart tailscaled ```
adam commented 2025-12-29 02:20:18 +01:00
Author
Owner
Copy Link

@handsomexdd1024 commented on GitHub (Dec 4, 2023):

@9Ninety Brilliant solution! Thank you so much.

@handsomexdd1024 commented on GitHub (Dec 4, 2023): @9Ninety Brilliant solution! Thank you so much.
adam commented 2025-12-29 02:20:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 4, 2024):

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

@github-actions[bot] commented on GitHub (Mar 4, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:20:18 +01:00
Author
Owner
Copy Link

@hrtkpf commented on GitHub (Mar 4, 2024):

I think this is still relevant.

@hrtkpf commented on GitHub (Mar 4, 2024): I think this is still relevant.
adam commented 2025-12-29 02:20:18 +01:00
Author
Owner
Copy Link

@almereyda commented on GitHub (Mar 4, 2024):

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?

@almereyda commented on GitHub (Mar 4, 2024): 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](https://github.com/tailscale/tailscale/pull/593#issuecomment-663191423). ```sh $ tailscale debug prefs | jq '.CorpDNS' true ``` <details><summary>`resolvectl status tailscale0`</summary> <p> ``` 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 ``` </p> </details> Is this maybe an upstream condition, eventually related to distribution-specific packaging/configuration?
adam commented 2025-12-29 02:20:19 +01:00
Author
Owner
Copy Link

@mimnix commented on GitHub (Apr 20, 2024):

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

@mimnix commented on GitHub (Apr 20, 2024): 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`
adam commented 2025-12-29 02:20:19 +01:00
Author
Owner
Copy Link

@handsomexdd1024 commented on GitHub (Apr 29, 2024):

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

@handsomexdd1024 commented on GitHub (Apr 29, 2024): Recent tests showed that this bug has been fixed somehow, so I'm closing this issue.
adam commented 2025-12-29 02:20:19 +01:00
Author
Owner
Copy Link

@Matic-M commented on GitHub (Nov 16, 2025):

This issue has not been resolved

@Matic-M commented on GitHub (Nov 16, 2025): This issue has not been resolved
adam commented 2025-12-29 02:20:19 +01:00
Author
Owner
Copy Link

@mastier commented on GitHub (Nov 26, 2025):

Still failed on me on some older system like ubuntu jammy and tailscale 1.88.4 or debian

the problem dissaperared when I upgraded to the newest tailscale client 1.90.
https://pkgs.tailscale.com/stable/#ubuntu-jammy

For me the problem it was overriding the default resolved stub also
not it works correctly

@mastier commented on GitHub (Nov 26, 2025): Still failed on me on some older system like ubuntu jammy and tailscale 1.88.4 or debian the problem dissaperared when I upgraded to the newest tailscale client 1.90. https://pkgs.tailscale.com/stable/#ubuntu-jammy For me the problem it was overriding the default resolved stub also not it works correctly
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#557
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?