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

restricted_nameservers resolution fails when --accept-routes is false #530

New Issue
Closed
opened 2025-12-29 02:19:35 +01:00 by adam · 5 comments
adam commented 2025-12-29 02:19:35 +01:00
Owner
Copy Link

Originally created by @RUzOfuz5m on GitHub (Jul 11, 2023).

Why

This request is for when --accept-routes is false the restricted_nameservers: should not be used.

To me, it's reasonable that restricted_nameservers are DNS servers that are hosted on a private network. When using --accept-routes it makes sense that you can expect that you're on the private network and should have access to the restricted DNS hosts.

If --accept-routes is false, you want to be on the "raw" Internet, either from an exit node or from your current connection. using restricted_nameservers here doesn't make sense as it fails in my example below.

Description

I have Split DNS setup:

dns_config:
  nameservers:
    - 208.67.222.222
    - 208.67.220.220
  restricted_nameservers:
    example.ca:
      - 192.168.0.1

Internal to the 192.168.0.0/24 network, example.ca will resolve to 192.168.0.200
external to the 192.168.0.0/24 network, example.ca will resolve to $Public_IP

When I connect to an exit node and I'm away from the 192.168.0.0/24 network, I use tailscale up --login-server=https://headscale.example.ca --exit-node=100.64.0.1 --reset This does not include a route to 192.168.0.1 so any DNS resolution for example.ca will fail. I'm looking for a solution that will allow me to continue to resolve example.ca. My suggestion is above but anything that works would be fine.

Originally created by @RUzOfuz5m on GitHub (Jul 11, 2023). ## Why This request is for when `--accept-routes is false` the `restricted_nameservers:` should not be used. To me, it's reasonable that restricted_nameservers are DNS servers that are hosted on a private network. When using --accept-routes it makes sense that you can expect that you're on the private network and should have access to the restricted DNS hosts. If --accept-routes is false, you want to be on the "raw" Internet, either from an exit node or from your current connection. using restricted_nameservers here doesn't make sense as it fails in my example below. ## Description I have Split DNS setup: ``` dns_config: nameservers: - 208.67.222.222 - 208.67.220.220 restricted_nameservers: example.ca: - 192.168.0.1 ``` Internal to the 192.168.0.0/24 network, example.ca will resolve to 192.168.0.200 external to the 192.168.0.0/24 network, example.ca will resolve to $Public_IP When I connect to an exit node and I'm away from the 192.168.0.0/24 network, I use `tailscale up --login-server=https://headscale.example.ca --exit-node=100.64.0.1 --reset` This does not include a route to 192.168.0.1 so any DNS resolution for example.ca will fail. I'm looking for a solution that will allow me to continue to resolve example.ca. My suggestion is above but anything that works would be fine.
adam added the enhancementstale labels 2025-12-29 02:19:35 +01:00
adam closed this issue 2025-12-29 02:19:35 +01:00
adam commented 2025-12-29 02:19:35 +01:00
Author
Owner
Copy Link

@sjansen1 commented on GitHub (Jul 18, 2023):

I am not so sure if this is good idea, what if you never use subnet gateways but want another tailscale node to be your nameserver?

@sjansen1 commented on GitHub (Jul 18, 2023): I am not so sure if this is good idea, what if you never use subnet gateways but want another tailscale node to be your nameserver?
adam commented 2025-12-29 02:19:36 +01:00
Author
Owner
Copy Link

@RUzOfuz5m commented on GitHub (Jul 19, 2023):

Why not put the tailscale node as a nameserver instead of a restricted_nameserver in that case @sjansen1?

When you connect to the tailscale network all of the tailscale nodes will be available (assuming no ACLs) so putting one as the nameserver shouldn't be a problem as far as I understand it.

Do you have any suggestions for the problem I'm having? if --accept-routes is false DNS fails for my restricted_nameservers because they're on a private IP and reslove private addresses. I'd like the option to resolve the public IPs.

@RUzOfuz5m commented on GitHub (Jul 19, 2023): Why not put the tailscale node as a nameserver instead of a restricted_nameserver in that case @sjansen1? When you connect to the tailscale network all of the tailscale nodes will be available (assuming no ACLs) so putting one as the nameserver shouldn't be a problem as far as I understand it. Do you have any suggestions for the problem I'm having? if `--accept-routes` is false DNS fails for my restricted_nameservers because they're on a private IP and reslove private addresses. I'd like the option to resolve the public IPs.
adam commented 2025-12-29 02:19:36 +01:00
Author
Owner
Copy Link

@sjansen1 commented on GitHub (Jul 19, 2023):

Sorry i have no idea for a solution because i use subnet routers for reaching out to our nameservers. I have different problems like tailscale is unable to bootstrap (start) if required nameserver are in a network that is provided over tailscale and the person is present at the location where the subnets are, but thats something different i am struggle with.

@sjansen1 commented on GitHub (Jul 19, 2023): Sorry i have no idea for a solution because i use subnet routers for reaching out to our nameservers. I have different problems like tailscale is unable to bootstrap (start) if required nameserver are in a network that is provided over tailscale and the person is present at the location where the subnets are, but thats something different i am struggle with.
adam commented 2025-12-29 02:19:36 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 12, 2023):

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

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

@github-actions[bot] commented on GitHub (Dec 20, 2023):

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

@github-actions[bot] commented on GitHub (Dec 20, 2023): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 enhancement 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#530
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?