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

DNS extra_records don't work with Split DNS and a client capable of natively doing Split DNS #426

New Issue
Closed
opened 2025-12-29 01:28:59 +01:00 by adam · 2 comments
adam commented 2025-12-29 01:28:59 +01:00
Owner
Copy Link

Originally created by @madjam002 on GitHub (Feb 6, 2023).

Bug description

Just following on from the PR #1035 as I believe it was based on my hacky commit, I've only just noticed this was added to Headscale after updating to 0.20! CC'ing in @christian-heusel to give him a heads up of this issue too.

I'm opening this issue to document the fact that this doesn't work if split DNS is enabled, which is also now supported by Headscale but I was sort of running unofficially using a patch. With Split DNS, Tailscale configures the local DNS service (if available, otherwise all queries go through 100.100.100.100) on the machine to query 100.100.100.100 for magic DNS domains and restricted_nameservers. This doesn't yet work for extra_records, presumably because it's not officially supported by Tailscale and they don't have any support for it on their hosted control plane (AFAIK).

As a hacky workaround, one can add a restricted_nameservers entry for each domain they've added to extra_records, and point it to 100.100.100.100.

Unfortunately, this has unintended side effects in 0.20 since #1162 was merged as restricted_nameservers are added to the search domains of the client as well.

To Reproduce

Add domains to extra_records in your Headscale configuration and enable Split DNS, and connect using Tailscale on a client such as:

  • Windows, which uses the Name Resolution Policy Table to determine which resolver is used
  • macOS, DNS configuration can be debugged with scutil --dns
  • Linux, using something like systemd-resolved, use resolvectl to debug

extra_records won't be resolved.

Proposed workaround

Perhaps to configure additional restricted_nameservers based on extra_records behind the scenes? Or perhaps this will be fixed in the Tailscale client itself.

Context info

  • Version of headscale used 0.20.0
  • Version of tailscale client 1.36.0
Originally created by @madjam002 on GitHub (Feb 6, 2023). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the bug report in this language. --> **Bug description** Just following on from the PR #1035 as I believe it was based on my hacky commit, I've only just noticed this was added to Headscale after updating to 0.20! CC'ing in @christian-heusel to give him a heads up of this issue too. I'm opening this issue to document the fact that this doesn't work if split DNS is enabled, which is also now supported by Headscale but I was sort of running unofficially using a patch. With Split DNS, Tailscale configures the local DNS service (if available, otherwise all queries go through 100.100.100.100) on the machine to query 100.100.100.100 for magic DNS domains and restricted_nameservers. This doesn't yet work for extra_records, presumably because it's not officially supported by Tailscale and they don't have any support for it on their hosted control plane (AFAIK). As a hacky workaround, one can add a restricted_nameservers entry for each domain they've added to extra_records, and point it to 100.100.100.100. Unfortunately, this has unintended side effects in 0.20 since #1162 was merged as restricted_nameservers are added to the search domains of the client as well. **To Reproduce** Add domains to extra_records in your Headscale configuration and enable Split DNS, and connect using Tailscale on a client such as: - Windows, which uses the Name Resolution Policy Table to determine which resolver is used - macOS, DNS configuration can be debugged with `scutil --dns` - Linux, using something like systemd-resolved, use `resolvectl` to debug `extra_records` won't be resolved. **Proposed workaround** Perhaps to configure additional restricted_nameservers based on extra_records behind the scenes? Or perhaps this will be fixed in the Tailscale client itself. **Context info** - Version of headscale used 0.20.0 - Version of tailscale client 1.36.0
adam added the stalebug labels 2025-12-29 01:28:59 +01:00
adam closed this issue 2025-12-29 01:28:59 +01:00
adam commented 2025-12-29 01:29:01 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 26, 2023):

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

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

@github-actions[bot] commented on GitHub (Oct 11, 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 11, 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 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#426
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?