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

Fallback NXDOMAIN MagicDNS records to defined nameservers #534

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

Originally created by @6ixfalls on GitHub (Jul 21, 2023).

Why

Due to the fact that headscale's DNS server is very limited in configuration, I deployed a separate server to handle DNS for both internal and external traffic. However, when you have a record for a domain under the same base domain as headscale, requests don't end up at my separate server and terminate at headscale with NXDOMAIN.

Here's an example:
Your headscale network has a base domain of myheadscalenetwork.com.
You have a user, user1, which would be user1.myheadscalenetwork.com.
If you have a device, like my-pc, that would be my-pc.user1.myheadscalenetwork.com.
However, let's say you want to define a custom record, maybe my-minecraft-server.user1.myheadscalenetwork.com. This won't work with MagicDNS enabled, leading me to believe that DNS isn't forwarded if MagicDNS doesn't pass. This works fine with MagicDNS disabled, but obviously my-pc.user1.myheadscalenetwork.com no longer works unless I define it manually.
Personally, my use case for this is based upon the fact I have a dedicated user for "servers" on my headscale network. Using that, I have a user like internal.myheadscalenetwork.com, which I am able to use both for my headscale connected devices as well as my internal services accessible through tailscale as well.

Description

This can either be a "fix" or a "new feature", as the fix would be just falling back to the defined nameservers if MagicDNS fails. Alternatively, this can also be locked behind another configuration option, like "magicdns_fallback: true". Both entails falling back to the defined nameservers, although I'm not sure what you'd do if there aren't any nameservers defined (not sure how that works with headscale/tailscale personally.)

Given the same configuration as above, with a base domain of myheadscalenetwork.com, user1, and user1's my-pc, as well as 1.1.1.1 defined as nameservers with my-minecraft-server.user1.myheadscalenetwork.com pointed to xxx.xxx.xxx.xxx:
nslookup my-pc.user1.myheadscalenetwork.com > 100.100.100.100 resolves 100.64.0.1
nslookup my-minecraft-server.user1.myheadscalenetwork.com > 100.100.100.100 NXDOMAIN > 1.1.1.1 resolves xxx.xxx.xxx.xxx
nslookup non-existent.user1.myheadscalenetwork.com > 100.100.100.100 NXDOMAIN > 1.1.1.1 NXDOMAIN
If there are conflicting records, I'd expect MagicDNS to "win" since it should follow a chain, MagicDNS first and user-defined afterwards.

Originally created by @6ixfalls on GitHub (Jul 21, 2023). <!-- We typically have a clear roadmap for what we want to improve and reserve the right to close feature requests that does not fit in the roadmap, or fit with the scope of the project, or we actually want to implement ourselves. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Why <!-- Include the reason, why you would need the feature. E.g. what problem does it solve? Or which workflow is currently frustrating and will be improved by this? --> Due to the fact that headscale's DNS server is very limited in configuration, I deployed a separate server to handle DNS for both internal and external traffic. However, when you have a record for a domain under the same base domain as headscale, requests don't end up at my separate server and terminate at headscale with NXDOMAIN. Here's an example: Your headscale network has a base domain of `myheadscalenetwork.com`. You have a user, user1, which would be `user1.myheadscalenetwork.com`. If you have a device, like my-pc, that would be `my-pc.user1.myheadscalenetwork.com`. However, let's say you want to define a custom record, maybe `my-minecraft-server.user1.myheadscalenetwork.com`. This won't work with MagicDNS enabled, leading me to believe that DNS isn't forwarded if MagicDNS doesn't pass. This works fine with MagicDNS disabled, but obviously `my-pc.user1.myheadscalenetwork.com` no longer works unless I define it manually. Personally, my use case for this is based upon the fact I have a dedicated user for "servers" on my headscale network. Using that, I have a user like `internal.myheadscalenetwork.com`, which I am able to use both for my headscale connected devices as well as my internal services accessible through tailscale as well. ## Description <!-- A clear and precise description of what new or changed feature you want. --> This can either be a "fix" or a "new feature", as the fix would be just falling back to the defined nameservers if MagicDNS fails. Alternatively, this can also be locked behind another configuration option, like "magicdns_fallback: true". Both entails falling back to the defined nameservers, although I'm not sure what you'd do if there aren't any nameservers defined (not sure how that works with headscale/tailscale personally.) Given the same configuration as above, with a base domain of `myheadscalenetwork.com`, user1, and user1's `my-pc`, as well as `1.1.1.1` defined as nameservers with `my-minecraft-server.user1.myheadscalenetwork.com` pointed to `xxx.xxx.xxx.xxx`: nslookup `my-pc.user1.myheadscalenetwork.com` > `100.100.100.100` resolves `100.64.0.1` nslookup `my-minecraft-server.user1.myheadscalenetwork.com` > `100.100.100.100` NXDOMAIN > `1.1.1.1` resolves `xxx.xxx.xxx.xxx` nslookup `non-existent.user1.myheadscalenetwork.com` > `100.100.100.100` NXDOMAIN > `1.1.1.1` NXDOMAIN If there are conflicting records, I'd expect MagicDNS to "win" since it should follow a chain, MagicDNS first and user-defined afterwards.
adam added the enhancement label 2025-12-29 02:19:36 +01:00
adam closed this issue 2025-12-29 02:19:36 +01:00
adam commented 2025-12-29 02:19:37 +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:37 +01:00
Author
Owner
Copy Link

@6ixfalls commented on GitHub (Dec 12, 2023):

/no

@6ixfalls commented on GitHub (Dec 12, 2023): /no
adam commented 2025-12-29 02:19:37 +01:00
Author
Owner
Copy Link

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

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

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

@6ixfalls commented on GitHub (Mar 13, 2024):

still needed

@6ixfalls commented on GitHub (Mar 13, 2024): still needed
adam commented 2025-12-29 02:19:37 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 12, 2024):

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

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

@6ixfalls commented on GitHub (Jun 12, 2024):

still

@6ixfalls commented on GitHub (Jun 12, 2024): still
adam commented 2025-12-29 02:19:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 5, 2024):

from version 0.23, you will no longer be allowed to use the same domain as base_domain for magic dns and server_url, which I believe will eliminate the need for this.

@kradalby commented on GitHub (Sep 5, 2024): from version 0.23, you will no longer be allowed to use the same domain as base_domain for magic dns and server_url, which I believe will eliminate the need for this.
adam commented 2025-12-29 02:19:38 +01:00
Author
Owner
Copy Link

@6ixfalls commented on GitHub (Sep 5, 2024):

@kradalby that shouldn't matter - this is for a custom nameserver which contains records for the magic dns domain (in regardless of what server url is).

@6ixfalls commented on GitHub (Sep 5, 2024): @kradalby that shouldn't matter - this is for a custom nameserver which contains records for the magic dns domain (in regardless of what server url is).
adam commented 2025-12-29 02:19:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 5, 2024):

How does Tailscale Saas behave in the case of this?

@kradalby commented on GitHub (Sep 5, 2024): How does Tailscale Saas behave in the case of this?
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
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#534
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?