Closed 6ixfalls closed 1 month ago
This issue is stale because it has been open for 90 days with no activity.
/no
This issue is stale because it has been open for 90 days with no activity.
still needed
This issue is stale because it has been open for 90 days with no activity.
still
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 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).
How does Tailscale Saas behave in the case of this?
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 beuser1.myheadscalenetwork.com
. If you have a device, like my-pc, that would bemy-pc.user1.myheadscalenetwork.com
. However, let's say you want to define a custom record, maybemy-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 obviouslymy-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 likeinternal.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'smy-pc
, as well as1.1.1.1
defined as nameservers withmy-minecraft-server.user1.myheadscalenetwork.com
pointed toxxx.xxx.xxx.xxx
: nslookupmy-pc.user1.myheadscalenetwork.com
>100.100.100.100
resolves100.64.0.1
nslookupmy-minecraft-server.user1.myheadscalenetwork.com
>100.100.100.100
NXDOMAIN >1.1.1.1
resolvesxxx.xxx.xxx.xxx
nslookupnon-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.