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

Only distribute split dns entries when the corresponding route is available #296

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

Originally created by @FStelzer on GitHub (Jul 19, 2022).

As far as i understand the split dns section of the config is unconditionally distributed to all client. However when it references nameservers only reachable by an advertised route then the client might not have access to it.
It is probably too complicated to evaluate the full acl policy to determine if DNS resoultion is possible, but removing entries for routes known to headscale that the client will not get at all should be possible.

I have a couple of environments each with their own subnet and authoritative dns zone. Every environment has a tailscale node advertising the environments network to vpn clients. However not all clients have access to all environments and best should not even know about them. In some situations these names might even result in a different lookup result on a public resolver.
Right now the clients get the split dns entries and every query will time out because the route to the dns is missing.

Originally created by @FStelzer on GitHub (Jul 19, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the feature request in this language. --> As far as i understand the split dns section of the config is unconditionally distributed to all client. However when it references nameservers only reachable by an advertised route then the client might not have access to it. It is probably too complicated to evaluate the full acl policy to determine if DNS resoultion is possible, but removing entries for routes known to headscale that the client will not get at all should be possible. <!-- A clear and precise description of what new or changed feature you want. --> I have a couple of environments each with their own subnet and authoritative dns zone. Every environment has a tailscale node advertising the environments network to vpn clients. However not all clients have access to all environments and best should not even know about them. In some situations these names might even result in a different lookup result on a public resolver. Right now the clients get the split dns entries and every query will time out because the route to the dns is missing.
adam added the enhancementstale labels 2025-12-29 01:26:19 +01:00
adam closed this issue 2025-12-29 01:26:19 +01:00
adam commented 2025-12-29 01:26:20 +01:00
Author
Owner
Copy Link

@FStelzer commented on GitHub (Jul 19, 2022):

If this feature is of interest I could probably provide a patch with some guidance. I've looked into getMapResponse() a bit where valid peers and the dns config is assembled and it doesen't look too big of a change. An additional unfiltered listpeers (or similar filtering for advertised routes for this node) and some manipulation of the resulting dns config.
Even better of course would be to be able for nodes to advertise dns subdomains together with routes. But thats a whole different thing which tailscale would need to add first.

@FStelzer commented on GitHub (Jul 19, 2022): If this feature is of interest I could probably provide a patch with some guidance. I've looked into getMapResponse() a bit where valid peers and the dns config is assembled and it doesen't look too big of a change. An additional unfiltered listpeers (or similar filtering for advertised routes for this node) and some manipulation of the resulting dns config. Even better of course would be to be able for nodes to advertise dns subdomains together with routes. But thats a whole different thing which tailscale would need to add first.
adam commented 2025-12-29 01:26:20 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 8, 2022):

If this feature is of interest I could probably provide a patch with some guidance. I've looked into getMapResponse() a bit where valid peers and the dns config is assembled and it doesen't look too big of a change. An additional unfiltered listpeers (or similar filtering for advertised routes for this node) and some manipulation of the resulting dns config.

I think this sounds like an interesting feature, it sounds like it should work. I am happy for you to take a stab at it. The main requirement for this, and possibly most of the work would be to add integration tests to verify that it works as intended and that it does not break current behaviour.

@kradalby commented on GitHub (Sep 8, 2022): > If this feature is of interest I could probably provide a patch with some guidance. I've looked into getMapResponse() a bit where valid peers and the dns config is assembled and it doesen't look too big of a change. An additional unfiltered listpeers (or similar filtering for advertised routes for this node) and some manipulation of the resulting dns config. I think this sounds like an interesting feature, it sounds like it _should_ work. I am happy for you to take a stab at it. The main requirement for this, and possibly most of the work would be to add integration tests to verify that it works as intended and that it does not break current behaviour.
adam commented 2025-12-29 01:26:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 4, 2023):

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

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

@github-actions[bot] commented on GitHub (Oct 19, 2023):

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

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

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

This is still a valid feature request, that should never go stale.

@davidmehren commented on GitHub (Oct 19, 2023): This is still a valid feature request, that should never go 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#296
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?