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

[Bug] Tailscale Client Fails to Resolve DNS #839

New Issue
Closed
opened 2025-12-29 02:24:41 +01:00 by adam · 8 comments
adam commented 2025-12-29 02:24:41 +01:00
Owner
Copy Link

Originally created by @W1BTR on GitHub (Oct 23, 2024).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Seems more like a Tailscale bug, but the Tailscale client on Windows often fails to connect on startup. It's stuck on "connecting..." despite my machine having an active Ethernet connection.

In the logs, it says it's failing to resolve my headscale server's domain, but my dns servers (8.8.8.8 and 8.8.4.4) passed to me from my router work fine, and I can properly ping all common dns servers from cmd. I can also browse the internet just fine. I can also visit the domain for my headscale server just fine, and ping it properly.

2024-10-23T09:26:25.779-04:00: [v1] v1.76.3-t02acaa00e-g551df6588 peers: 37569296/7424000 1080/248 2128/4636 109014776/59720396
2024-10-23T09:26:26.190-04:00: control: trying bootstrapDNS("derp16d.tailscale.com", "2607:f740:17::475") for "headscale.mydomain.com" ...
2024-10-23T09:26:26.225-04:00: control: bootstrapDNS("derp16d.tailscale.com", "2607:f740:17::475") for "headscale.mydomain.com" error: Get "https://derp16d.tailscale.com/bootstrap-dns?q=headscale.mydomain.com": dial tcp [2607:f740:17::475]:443: connectex: A socket operation was attempted to an unreachable network.
2024-10-23T09:26:26.226-04:00: control: [v1] TryLogin: fetch control key: Get "https://headscale.mydomain.com/key?v=106": failed to resolve "headscale.mydomain.com": no DNS fallback candidates remain for "headscale.mydomain.com"
2024-10-23T09:26:26.226-04:00: control: [v1] sendStatus: authRoutine-report: state:authenticating
2024-10-23T09:26:26.226-04:00: control: authRoutine: [v1] backoff: 25712 msec
2024-10-23T09:26:26.226-04:00: Received error: fetch control key: Get "https://headscale.mydomain.com/key?v=106": failed to resolve "headscale.mydomain.com": no DNS fallback candidates remain for "headscale.mydomain.com"

Note that I changed to domain for privacy.

I can sometimes get it going by disconnecting and reconnecting my internet after restarting the Tailscale service.

Expected Behavior

I'd expect it to connect right away using the DNS from my host machine. It almost looks like it's trying to use the tailscale magic dns, but that wont work since it's not running yet.

Steps To Reproduce

Not sure what's unique about my environment, but all I can think of:

  1. Using ethernet with another secondary ethernet adapter and wifi enabled but not in use
  2. Start Windows

Environment

- OS: Windows 10
- Headscale version: 0.23.0
- Tailscale version: 1.76.3

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Anything else?

More logs: https://paste.yunohost.org/onebulayar.log

Originally created by @W1BTR on GitHub (Oct 23, 2024). ### Is this a support request? - [X] This is not a support request ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior Seems more like a Tailscale bug, but the Tailscale client on Windows often fails to connect on startup. It's stuck on "connecting..." despite my machine having an active Ethernet connection. In the logs, it says it's failing to resolve my headscale server's domain, but my dns servers (8.8.8.8 and 8.8.4.4) passed to me from my router work fine, and I can properly ping all common dns servers from cmd. I can also browse the internet just fine. I can also visit the domain for my headscale server just fine, and ping it properly. ``` 2024-10-23T09:26:25.779-04:00: [v1] v1.76.3-t02acaa00e-g551df6588 peers: 37569296/7424000 1080/248 2128/4636 109014776/59720396 2024-10-23T09:26:26.190-04:00: control: trying bootstrapDNS("derp16d.tailscale.com", "2607:f740:17::475") for "headscale.mydomain.com" ... 2024-10-23T09:26:26.225-04:00: control: bootstrapDNS("derp16d.tailscale.com", "2607:f740:17::475") for "headscale.mydomain.com" error: Get "https://derp16d.tailscale.com/bootstrap-dns?q=headscale.mydomain.com": dial tcp [2607:f740:17::475]:443: connectex: A socket operation was attempted to an unreachable network. 2024-10-23T09:26:26.226-04:00: control: [v1] TryLogin: fetch control key: Get "https://headscale.mydomain.com/key?v=106": failed to resolve "headscale.mydomain.com": no DNS fallback candidates remain for "headscale.mydomain.com" 2024-10-23T09:26:26.226-04:00: control: [v1] sendStatus: authRoutine-report: state:authenticating 2024-10-23T09:26:26.226-04:00: control: authRoutine: [v1] backoff: 25712 msec 2024-10-23T09:26:26.226-04:00: Received error: fetch control key: Get "https://headscale.mydomain.com/key?v=106": failed to resolve "headscale.mydomain.com": no DNS fallback candidates remain for "headscale.mydomain.com" ``` _Note that I changed to domain for privacy._ I can sometimes get it going by disconnecting and reconnecting my internet after restarting the Tailscale service. ### Expected Behavior I'd expect it to connect right away using the DNS from my host machine. It almost looks like it's trying to use the tailscale magic dns, but that wont work since it's not running yet. ### Steps To Reproduce Not sure what's unique about my environment, but all I can think of: 1. Using ethernet with another secondary ethernet adapter and wifi enabled but not in use 2. Start Windows ### Environment ```markdown - OS: Windows 10 - Headscale version: 0.23.0 - Tailscale version: 1.76.3 ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [X] Headscale runs in a container ### Anything else? More logs: https://paste.yunohost.org/onebulayar.log
adam added the stalebug labels 2025-12-29 02:24:41 +01:00
adam closed this issue 2025-12-29 02:24:41 +01:00
adam commented 2025-12-29 02:24:41 +01:00
Author
Owner
Copy Link

@hopleus commented on GitHub (Oct 25, 2024):

  1. What does HeadScale have to do with this if you say the problem is DNS resolution on your machine?
  2. Have you tried changing the configuration and connecting to HeadScale without using a domain, but directly by IP?
@hopleus commented on GitHub (Oct 25, 2024): 1. What does HeadScale have to do with this if you say the problem is DNS resolution on your machine? 2. Have you tried changing the configuration and connecting to HeadScale without using a domain, but directly by IP?
adam commented 2025-12-29 02:24:42 +01:00
Author
Owner
Copy Link

@W1BTR commented on GitHub (Oct 25, 2024):

For clarification, DNS does work fine for everything other than the Tailscale app, even with the headscale server's domain.

I do believe it is a bug with the Tailscale app, but the docs for Headscale say to make sure and send all issues, even those with the Tailscale app to the Headscale Github, so I was following that. Every time I restart the Tailscale service, it proceeds to work.

Ill have to try using an IP, I didnt think of that. Will report back.

@W1BTR commented on GitHub (Oct 25, 2024): For clarification, DNS does work fine for everything other than the Tailscale app, even with the headscale server's domain. I do believe it is a bug with the Tailscale app, but the docs for Headscale say to make sure and send all issues, even those with the Tailscale app to the Headscale Github, so I was following that. Every time I restart the Tailscale service, it proceeds to work. Ill have to try using an IP, I didnt think of that. Will report back.
adam commented 2025-12-29 02:24:42 +01:00
Author
Owner
Copy Link

@nblock commented on GitHub (Oct 26, 2024):

[…] but the docs for Headscale say to make sure and send all issues, even those with the Tailscale app to the Headscale Github, so I was following that.

That should probably be fixed in the docs. Do you have a pointer to the specific section?

@nblock commented on GitHub (Oct 26, 2024): > […] but the docs for Headscale say to make sure and send all issues, even those with the Tailscale app to the Headscale Github, so I was following that. That should probably be fixed in the docs. Do you have a pointer to the specific section?
adam commented 2025-12-29 02:24:42 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 25, 2025):

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

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

@github-actions[bot] commented on GitHub (Feb 1, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Feb 1, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:24:43 +01:00
Author
Owner
Copy Link

@mastier commented on GitHub (Feb 21, 2025):

EDIT: I saw this
# This domain must be different from the server_url domain.
So that answers the question. Yet that's new behaviour since 0.23.2 I used last time....

I encounter the same issue, I got nginx in front of headscale 0.25 and it's passing request to the docker container via let's say mydomain.example.com

When I am connected tailscale to my headscale instance in mydomain.example.com the DNS is 100.100.100.100

$ dig mydomain.example.com @100.100.100.100

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> mydomain.example.com @100.100.100.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19081
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.example.com.			IN	A

;; Query time: 0 msec
;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP)
;; WHEN: Fri Feb 21 18:31:24 CET 2025
;; MSG SIZE  rcvd: 32

While normally it resolves it via Google DNS

That domain is also magic dns base_domain

dns:                                                                                                
  # Whether to use [MagicDNS](https://tailscale.com/kb/1081/magicdns/).                             
  magic_dns: true                                                                                   
                                                                                                    
  # Defines the base domain to create the hostnames for MagicDNS.                                   
  # This domain _must_ be different from the server_url domain.                                     
  # `base_domain` must be a FQDN, without the trailing dot.                                         
  # The FQDN of the hosts will be                                                                   
  # `hostname.base_domain` (e.g., _myhost.example.com_).                                            
  base_domain:  mydomain.example.com

That seems to be an issue here
If I switch to other domain like ts.mydomain.example.com everything works as expected

dig mydomain.example.com @100.100.100.100

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> mydomain.example.com @100.100.100.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46541
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mydomain.example.com.			IN	A

;; ANSWER SECTION:
mydomain.example.com		3600	IN	A	83.X.X.X

;; Query time: 92 msec
;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP)
;; WHEN: Fri Feb 21 18:38:12 CET 2025
;; MSG SIZE  rcvd: 73
@mastier commented on GitHub (Feb 21, 2025): EDIT: I saw this **# This domain _must_ be different from the server_url domain.** So that answers the question. Yet that's new behaviour since 0.23.2 I used last time.... I encounter the same issue, I got nginx in front of headscale 0.25 and it's passing request to the docker container via let's say mydomain.example.com When I am connected tailscale to my headscale instance in mydomain.example.com the DNS is 100.100.100.100 ``` $ dig mydomain.example.com @100.100.100.100 ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> mydomain.example.com @100.100.100.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19081 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mydomain.example.com. IN A ;; Query time: 0 msec ;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP) ;; WHEN: Fri Feb 21 18:31:24 CET 2025 ;; MSG SIZE rcvd: 32 ``` While normally it resolves it via Google DNS That domain is also magic dns base_domain ``` dns: # Whether to use [MagicDNS](https://tailscale.com/kb/1081/magicdns/). magic_dns: true # Defines the base domain to create the hostnames for MagicDNS. # This domain _must_ be different from the server_url domain. # `base_domain` must be a FQDN, without the trailing dot. # The FQDN of the hosts will be # `hostname.base_domain` (e.g., _myhost.example.com_). base_domain: mydomain.example.com ``` That seems to be an issue here If I switch to other domain like ts.mydomain.example.com everything works as expected dig mydomain.example.com @100.100.100.100 ``` ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> mydomain.example.com @100.100.100.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46541 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mydomain.example.com. IN A ;; ANSWER SECTION: mydomain.example.com 3600 IN A 83.X.X.X ;; Query time: 92 msec ;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP) ;; WHEN: Fri Feb 21 18:38:12 CET 2025 ;; MSG SIZE rcvd: 73 ```
adam commented 2025-12-29 02:24:43 +01:00
Author
Owner
Copy Link

@W1BTR commented on GitHub (Feb 21, 2025):

Not sure I understand what you're saying.

# This domain must be different from the server_url domain.

What is "This domain?" Where was this message found?

I have headscale hosted at a different domain than the one Im trying to resolve DNS to, if thats what you mean

@W1BTR commented on GitHub (Feb 21, 2025): Not sure I understand what you're saying. > `# This domain must be different from the server_url domain.` What is "This domain?" Where was this message found? I have headscale hosted at a different domain than the one Im trying to resolve DNS to, if thats what you mean
adam commented 2025-12-29 02:24:43 +01:00
Author
Owner
Copy Link

@davidsmith91 commented on GitHub (Feb 23, 2025):

I have same issue.

I don't want to have tailscale making any other connection than the one between my devices and headscale.
But, the tailscale client on macos wants to use "Bootstrap dns" and connect to "derp servers" and doesn't allow me to login (with tailscale up --login-server) if I don't let it connect with that unwanted telemetry.

I have a domain that's not public. I use dns01 challenge with traefik. I simply put the ip of the domain in the /etc/hosts file. It works for everything: browsers, command line, etc.

But tailscale wants to ignore that he can already know the ip of the domain. So he decides to try to use their derp servers to get the domain ip. And the real reason? So they can get telemetry data. So they can do analytics even if I put the --no-logs-no-support flag.

Help?

@davidsmith91 commented on GitHub (Feb 23, 2025): I have same issue. I don't want to have tailscale making any other connection than the one between my devices and headscale. But, the tailscale client on macos wants to use "Bootstrap dns" and connect to "derp servers" and doesn't allow me to login (with tailscale up --login-server) if I don't let it connect with that unwanted telemetry. I have a domain that's not public. I use dns01 challenge with traefik. I simply put the ip of the domain in the /etc/hosts file. It works for everything: browsers, command line, etc. But tailscale wants to ignore that he can already know the ip of the domain. So he decides to try to use their derp servers to get the domain ip. And the real reason? So they can get telemetry data. So they can do analytics even if I put the --no-logs-no-support flag. Help?
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 stale
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#839
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?